Since this has come up many times across various platforms, this question is worth addressing directly.
I 100% empathize that this feels like a frustrating limitation, especially since it seems like it should be easy to resolve (just hide the manage access modal for read-only users!). Unfortunately, there are some security considerations that are very important for us to get right before we can hide that screen.
The fundamental issue is that the collaborator list is required for several product features to work (even for read-only users). For example, if you have a grid in an interface with a dropdown user filter, we need to be able to populate the dropdown list with user information. If we populate the list with all users, the server would essentially be sending the web browser the same information as is displayed in the manage-access dialog (and any sophisticated user could view the entire list just by opening the Network tab in their browser developer tools). We take security very seriously, and want to avoid putting builders in a position where their data can be seen in ways they don't expect (e.g. you have competing vendors with access to the same interface and you don't want them to know about each other). Showing the manage access dialog helps communicate more visibly to builders that the interface user list is available to all collaborators.
Ideally, we would only send to every user a filtered list of other users, but we'd need to figure out what the criteria for this is. Some criteria we've considered:
- Always redacting emails/pictures (which doesn't fully solve the problem, and makes it hard to distinguish between users with the same name)
- Limiting to users in the same domain (which doesn't work for public email providers, and would affect vendors that do need to work together)
- Somehow figuring out in realtime which other users every user can see based on data permissions (e.g. collaborator fields etc), and only limiting to that set (so computationally expensive that it could slow down the base).
One option is that we could just degrade things like the dropdown selector for read-only users.. but we also have very real editor use cases where hiding the user list is equally important (e.g. competing vendors needing edit access)! In these scenarios, the criteria for filtering becomes even harder to reason about (what if you actually want vendors to be able to assign tasks to each other?).
All of this is to communicate that we are very aware this is a painful limitation and that there are real technical problems that we need to work through. I don't have any timelines to share at the moment, but please know that we are thinking through how to solve this holistically. I will also note that any solution we come up with will likely have meaningful UX/workflow tradeoffs.
