Add full User and Groups lists to Access page#3211
Conversation
…nks to direct paths
…ilo, and group names
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
The thing that I am nervous about here is merging the concept of the list of users with the concept of role access. The nice thing (even though it's also confusing) about the current access pages is that they only show what is in the role policy response for the silo and the project (or the fleet in the case of the fleet*). In the design in this PR, we have a user list and then we annotate it with role assignments. The problem for me in practice is that you might have a list of 100 users, but let's say zero or one or two of them has a role assigned, and everything else is done through groups. Similar, you might have 20 groups, but only one of them is the one you use for role assignments. In this situation (which I think is close to typical for our customers), the current role policy page that only shows the role assignments tells you what you want to know in a much more digestible way, and if we want to list all users and groups I'd rather it be on separate tabs that are dedicated to that. Now, we might still want to combine the two approaches — keep the policy page, and then add tabs for users and groups, but those tabs also include role assignments in the big list. So I guess the short version is: what if we keep something like the current page as the * Ooh, I think we added the fleet access page since this was started. Something to think about. The concept of listing all users doesn't make sense at the fleet level, so there's necessarily a mismatch there. This is made a little easier. |

Currently, the Silo Access and Project Access page don't show all users, except when you open up the "Add user or group" form and access the dropdown:




In issue #2887, @askfongjojo requested a view where all users and groups would be displayed. This PR does that, adding a tabbed interface to show Groups / Users, and, then, on those pages, shows all groups and users.


From this tabbed view, an admin can make edits to a specific user / group's permissions, as before:

One ongoing situation that I want to mention is that we don't have a way to order / filter the responses from the API, and the default ordering from the API is by User ID. Instead of having pagination with 50 users per page, I have it selecting all-ish users (1,000) and then sorting them by name on the client. This deviates from the vanilla API response, but gives, I think, a more useful listing of users. I'm open to other approaches, if people have suggestions. I checked with Will about whether that 1,000 user cap would be a problem, and he said that in the far future it might be something to address, but that there are no current customers where that limit would be problematic, based on how they configure users/silos.
Closes #2887
Closes #1146
Closes #1359