To make a hack/workaround, you would have to filter out the response from /api/user and only show the user, which has the id from the response /api/user/current. Not sure what happens if you just block /api/user or make it return an empty JSON.
You could probably do everything exactly like you want if you modify the source, but that would probably be a huge task and then you would have to maintain it every time there’s an upgrade.
You can do a lot of things with a reverse proxy. So if you place a reverse proxy in front of Metabase, you (the user) are actually talking to the proxy. You can replace responses or modify then (i.e. with Nginx, you would use sub_filter to modify).
I’ve created a feature request issue for this as we would like to limit which users to display based on the user group of the current user. Feel free to give it a
I have the same request and to me it’s a security risk.
I set different user logins for different customers, each one set with permission to only access a specific table(s). However, when it comes to creating pulses or even alerts, the email field automatically populates with all users in the system.
I would expect the correct behavior to be that only users with the same access rights are displayed on the list.