Environment Management Rights Granularity
We are opening this ticket for a new feature request.
We tested the new parameter com.cerebro.domino.environments.canNonSysAdminsCreateEnvironments coming with 3.4.10 version and we currently cannot use it properly considering our use cases.
Limiting the environment availability is fine but we need to have the possibility to allow some users to access them and forbid it to the other. Basing on our context, a project should be owned by a project/application owner, in this project team, there should be one or different users that would be allowed to use the environment feature to create the project base environment and develop it in the time. Reducing so the workload from admin team that does not know the context for each project and don’t have time for this.
A first idea would be to add a feature flag that could be global or user specific to resolve this, but depending on your developments around the organizations and rights management, it could vary or be defined in different ways. Since setting a feature flag is perfect but time consuming with multiple projects, we wonder if there is a better way to do or combine it with something else. More granularity could be convenient on this feature also, like being able to read the environment content without having edition rights on it for example. Since some users could be environment referent user for multiple projects, we can expect that a user could be allowed to edit different environments for different projects but not all of them.To summarize below is what we are looking for
- Allowing some users to access the environment feature but not all (feature flag is a beginning but to light for specific cases)
- Environments should be readable/writable for some users and not for others, a better environment rights management is required here
- Some environments will be specifics to some projects only and can be shared between them and eventual others projects depending on rights
- The admin must be less involved on this part and give autonomy to a project team since he cannot manage all projects but should be able to intervene or have special rights in some cases.
- API for this will be useful also since it will be included in the user on-boarding process.