Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Looks really good. Nice message in the form. Will review properly tomorrow. |
| requireFleetAdmin(cookies) | ||
|
|
||
| const newAssignments = body.role_assignments | ||
| .filter((r) => fleetRoles.some((role) => role === r.role_name)) |
There was a problem hiding this comment.
(r) => fleetRoles.includes(r.role_name) I think?
| </NavLinkItem> | ||
| <NavLinkItem to={pb.systemAccess()}> | ||
| <Access16Icon /> System Access | ||
| </NavLinkItem> |
There was a problem hiding this comment.
System Update
System Access
doesn't feel right to me, though in both cases the qualifier is useful. On the other hand we are in the system section. Could we just call them Update and Access? @benjaminleonard @askfongjojo curious what you think.
What about Fleet Access. Slightly uglier but more literal is often better. System Update + Fleet Access might feel less repetitive.
Note the other ones are called Silo Access and Project Access because otherwise they would be incomprehensible. So I think we probably do need a qualifier.
There was a problem hiding this comment.
Fleet Access works for me. Agree that the stacked System felt a bit off.
There was a problem hiding this comment.
Yeah, let's go with that for now. It's kind of a problem for us because fleet and system are synonymous, but I'm ok with using the term that we use in the access subsystem.
| summary="Roles determine who can view, edit, or administer this fleet." | ||
| links={[docLinks.keyConceptsIam, docLinks.access]} | ||
| /> | ||
| </PageHeader> |
There was a problem hiding this comment.
Users can get fleet roles implicitly from a silo role if the fleet role mapping is set. I wonder if it's worth putting in some kind of info message on this page saying that the explicitly assigned roles don't necessarily exist exhaust the set of users who have permissions on the fleet, and you need to look at mapped fleet roles in the silos to be sure.
I guess ideally we'd actually be able to list those mappings on this page, but it's kind of gnarly because I think any silo could contribute? We could do something really cute and let the user pop a modal where we fetch all the silos and their mapping and list the ones that have mappings defined. Kind of elaborate but not really very hard. The only place it would be a problem is the colo rack, which has a million silos.
| <EmptyMessage | ||
| icon={<Access24Icon />} | ||
| title="No authorized users" | ||
| body="Give permission to view, edit, or administer this fleet" |
There was a problem hiding this comment.
Might also be worth mentioning here the fleet role mapping thing — that this list being empty doesn't necessarily mean nobody can see fleet stuff. Necessarily so 😁 because anyone who can see this page has to be a fleet viewer.
2 participants
This adds a system-level access page, with a form for setting fleet-level permissions.
One enhancement we might consider: It looks like there are a few booleans —
silo_adminandfleet_viewer— on the CurrentUser object coming from Omicron, but there is not afleet_adminattribute. If we add that in Omicron, we could disable the "Add User or Group" button and other controls on the System Access page for people without a fleet_admin role.Closes #2916