Yeah, I think this definitely makes sense.
There’s a little bit of a trick in that I don’t think we want to obliterate the view of an admin who might access to all servers, for which this list could be in the thousands (the admin view basically is this already), so perhaps it should only include servers where access is based on some filter?
The admin view technically can be used for this. Now that the admin page is a purely API-powered page (it used to be a templated page), its contents are governed by what the user has access to. So you can grant users access to the admin page via the admin-ui scope, but that doesn’t mean they have access to any information to populate the page. The simplest solution is to grant a user the list:users scope with the appropriate filter that matches the servers they have access to. For example, if you are granting access to some shared servers via a role:
c.JupyterHub.load_roles = [
{
"name": "access-something",
"groups": ["thegroupwithaccess"],
"scopes": [
"access:servers!group=othergroup", # the actual access, doesn't include start/stop
"admin-ui", # access the admin page, will be empty if just this
"list:users!group=othergroup", # required to populate the list on the admin page, will only include users in `othergroup`
"servers!group=othergroup", # needed for the start/stop buttons to work, if that's desired
},
]
It’s a bit of a janky temporary solution, because the UI is not designed to accommodate a user who can’t do a lot of the actions on the paged (e.g. edit/add user UI is still there, but it will fail with permission errors), and users may feel weird clicking an ‘admin’ button just to get a link to another’s server, even though they can’t actually do any admin-related activities.
A simplified version of the admin page (possibly as a new page, or an update to the home page) should be able to provide the simpler view of listing servers you have access to, and maybe even appropriately filtering whether you have just access or access and start/stop permissions.