@Fuat thanks for the update, appreciated. There was no communication on this ticket therefore your comment sheds some light on the case.

Just to clarify, if MongoDB teams are actively working on it, why do you ask for votes to get further updates on this? Should you not provide updates by default now that the teams are working on this case?

Just to bring some clarity with a public comment: The status of this ticket was updated to Started on Jul 20, 2022 that means the work to address the request started and MongoDB teams are actively working on it. Please vote for this request to get further updates.

Was about to vote for this, but then realised the issue was raised 3 years ago(!) with virtually no progress despite hundreds of upvotes. My conclusion is that this feedback platform does not seem to serve any purpose.

Each member of an organization with "Organization Member" role is able to read the billing details of the organization. This should be restricted. We facing problems with our governance, because each member is able to get details about billing in MongoDB Atlas.

The use-case is to share a dashboard with no ability to read billing informations.

I voted for this but I came to a point where I have to say: it would be much more useful for an organization like ours (regulated) to have policies on an organization level that prevent unwanted settings espacially in App Services (like creating endpoints or allow anonymous authentication or just creating ip access lists .... there are tons of such settings) ... so if I have to decide between having fine grained permissions or policies to prevent unwanted/mistakenly made settings I would go with the second. By the way it seems that Atlas has to do some heavy lifting with the fine grained permissions compared to the time this is an open and whished feature ... ;-)

Ditto what has been said about being able to get granular enough to control app services like Realm.

Our use case: give manager permissions to create and invite new users to projects. For that project owner role is needed. With that role, the manager will have access to all data and this is not least privilege principle

Please include permissions for App Services (realm). Right now if you want to edit/test a function in the realm UI, you have to have owner level permissions. That is not a permission level that should be given to most resources on the project

I would like to be able to assign the roles at the cluster level within the project, so that right team members can access to the right cluster in the project instead of getting access to every cluster in the project. Creating multiple projects to resolve this issue causes the burden on network that organization have to dedicate big subnets for getting just 2/3 clusters per project, which ends up in wasting the remaining IPs in those subnets.

That would be helpful to be able to restrict user access to particular nodes/node types.
Real world example:

I want my data analyst to only have access to isolated ANALYTICS node, to not be ably to run heavy queries in operational nodes set and not affect application performance / customers experience.

Also, i need more granular privilege for a user in order to add trigger role.

I'd like to be able to independently set user/team access to support tickets without giving them access to read information within databases.

For our Level 2 operations personnel it would be great to be able to assign a user role that allows for managing alerts, but does not need to be Project Owner role :-)

We also have a need for more granular permissions. To centrally monitor all configurations of our clusters, we want to use the API. We use the api to check whether audit is enabled and how audit is configured.
To check this, the api key must have project_owner or organization_owner permissions. This is very worrying from a security point of view, because it gives very powerful permissions. In this case it would be helpful to create a role with extended read permissions (>Organization Read Only).
I think that in the long run there is no way around the fact that users must be able to create their own roles.

As per Stanislav : We would like to see Access Control Management as a separate role.

I want to allow users to add their own IP address for 6 hours, with a comment specifying what username added that IP permission. Our users have dynamic IP addresses working remote and it is a constant effort trying to grant network access.

Allow API keys to have much more granular permissions (i.e: only the functions one may need to do a certain task).

Also, add a security category in the form to report possible improvements for Atlas.
And a UI/UX one.

The permissions should also put into consideration the view access rights for different member including access to billing informations among others.

The aspect of this feature I would find very useful is to allow certain non-project users to be authors on a data source. At the moment I can give a user author access to a chart but they have very limited editing ability and cannot see the fields of a data source to which they only have viewer access.

If I am reading the request correctly, it would help us fine-tune access including creating triggers without opening up the project-level access.