馃帹 Design: Setting inheritance in Organizations
Problem
We need to define a pattern for how we want settings to cascade in Organizations from the Organization level to groups, subgroups and projects. This includes:
- Indicating to Organization admins whether or not they can lock a setting
- Indicating to Organization users and members at what level a setting was locked in case they cannot change it for their group or project
- Defining what happens in the underlying groups and projects when a setting is locked
- Defining how settings would be managed that are available at more than one level (Organization, group, subgroup, project)
- Defining a pattern for overrides
- Defining what happens to existing versus new projects when a (parent) group setting is changed. Currently we apply some settings only to new, but not existing users, for instance here. Should we continue this practice? General feedback is that it is very difficult to understand what has been applied where. Admins essentially have to remember at what point in time they applied a setting and who was an existing versus a new users relating to that point in time. But what they want is to simply control settings for multiple projects from the group level.
Test settings to use while considering design patterns
- Restricting group and project visibility
- Prevent a project from being shared with groups
- Prevent users from requesting access to a group
Proposal
TBD
The outcome of this issue can be documented in !133675 (closed).
Related customer requests
Edited by Christina Lohr