Add full User and Groups lists to Access page#3211
Conversation
…nks to direct paths
…ilo, and group names
Initially I think #3211 had users and groups at both the silo and project level and then pared it back to only have it at the silo level, but kept the abstractions used to make it work in both spots. This undoes the abstraction. Redone from #3298 because I made that one a stack, and it turns out that prevents you from merging it into the underlying one.
|
This works, but it might be nice to have a more specific icon to indicate that the role comes from a group. 
We do have a group icon, though it's 16 instead of 12. Kind of interesting. 
|
|
That remove is disabled makes sense, but it's a little confusing that you can still use the change role button. I understand what's happening — you can assign the user a role directly in addition to their assignment from the group, but "change user role" doesn't get that across. 
You can see the behavior here: setting a user role 2026-07-23-user-group-role.mp4 |
|
One possibility on the roles is that we use the +N badge and modal again. Downside is that we're leaning on that tool an awful lot in this one UI, but it could give us the option of showing all roles, in descending order of strength, like we do in the user sidebar of the Project Access view. Some examples: EDIT: We experimented with this, but it ended up being noisy (having both the |
| const inUsersGroups = [pb.siloUsers(), pb.siloGroups()].some( | ||
| (p) => pathname === p || pathname.startsWith(`${p}/`) | ||
| ) | ||
|
|
There was a problem hiding this comment.
Kind of a smell about the IA maybe? But I can't think of a good top level route that we could stick /users and /groups under.
2 participants
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