Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce new permisson that allows a user to interact with any organisation in the same way a superuser can. #3443

Closed
underdarknl opened this issue Sep 3, 2024 · 6 comments · Fixed by #3532
Assignees
Labels
rocky Issues related to Rocky

Comments

@underdarknl
Copy link
Contributor

About this feature

There is a need for a new permission that allows us to grant users the right to interact with 'any' organization regardless of a the presence of an OrganizationMember record.

Detailed description

The check can be added to the same location where we currently allow SuperUsers to interact with any organization.
By adding a new permission we can allow our stakeholders to create users to do Organization Management without granting superuser Rights.

Feature benefit/User story

As a stakeholder I want to create users that can access (a subset of permissions) on all organizations without adding them to all organizations so that organization management can be done easily without relying on a superuser.

@underdarknl underdarknl added the rocky Issues related to Rocky label Sep 3, 2024
@dekkers
Copy link
Contributor

dekkers commented Sep 3, 2024

The question is which clearance level should the user get? For the superuser we just set it to 4, but that isn't appropiate for a non-superuser that has access to all organizations. The options I see:

  • Implement clearance level using django permissions. Clearance levels are permissions to enable certain boefjes so using django permissions wouldn't be that strange The different levels can be different permissions and if you set level 3 you would get permissions for level 1, 2 and 3. That way we can already use You can already set the permissions globally or for a specific organization. While I think this would be an elegant solution, refactoring this might take too much time we don't have at the moment.

  • Add a global clearance level field to the user model. A user can then enable a boefje if the user has either the global clearance level or organization specific clearance level to do this.

  • Add a default clearance level to the user model and use that clearance level when creating an OrganizationMember object. This would make it difficult to change the clearance level later for all organizations, so I think a global clearance level would be better.

@noamblitz
Copy link
Contributor

Would it be possible for this semi-super-user to have different clearance levels per organization? That would make it even more complicated.

@underdarknl
Copy link
Contributor Author

A global default (stored in the user record) sound logical. We could even use that for other types of users to avoid needing them to acknowledge 'per orga'.
The optional global can then be overwritten per orga if need be.

  • a set global, and no specific orga rights means we use the global.
  • a set global, and set (and achknowledged) specific orga rights means we use the specific orga rights, even when they are lower than the global. The user chooses to accept a lower right, and as such we should follow those preferences I think
  • no set global, and set (and achknowledged) specific orga rights means we use the specific orga rights.
  • No set global and no or not acknowledged orga rights means no rights.

@dekkers
Copy link
Contributor

dekkers commented Sep 16, 2024

I think the more common scenario that this might happen is that the user had an organization specific lower level and the situation changes and the user gets a higher global level. This then works except for those organizations that the user already had a clearance level which might be confusing, especially if for example the installation has hunderds of organizations and there are only a few with specific lower clearance level.

We also need to make the code that checks clearance level and returns error messages slightly more complex because we need to deal with the situation that the organization specific level is lower than the global level. And what if the user did not accept the organization specific lower level? Then it isn't a preference as you write, but we would still use the lower level that was set by the admin. At least that is the way we do with organization clearance level at the moment, because it would be strange if the admin can't take away a clearance level if the user doesn't acknowledge it.

I think usually these kind of things are implemented that the given permission is the maximum of the global and specific one. I think that is also the least surprising way for it to work and also how the other global/organization specific permissions work. So I have a slight preference for making organization specific clearance level not overrule the global level, but I'm also ok with changing it if others think it would be better. All the logic that checks the clearance level has been refactored to use the OrganizationMember model method/property so it should not be hard to change.

@underdarknl
Copy link
Contributor Author

In my opinion a global can always be overwritten by a more specific right, which can be move permissive or less permissive.
The same goes for accepting permissions (which this is), and I'd expect the user to have the power to accept a lower (but not higher) level if they choose to do so. Choosing a lower level on for example "prod" or other more delicate organizations compared to what the admin decided to give you seems like a reasonable thing to do?

@dekkers
Copy link
Contributor

dekkers commented Sep 18, 2024

In the discussion meet we decided that the specific level should override the global level.

Some of the concerns will in the future be addressed and are added in #3554

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rocky Issues related to Rocky
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants