| Issue 1197: | Generalize the concept behind the "Project Owners" system group | |
| 9 people starred this issue and may be notified of changes. | Back to list |
Having the special system group "Project Owners" makes it possible to define permission-only project and assign access permissions to the "Project Owners" where the "Project Owners" will only be associated to a concrete group at the concrete project level. This is done by assigning the "owner" privilege to a group. This concept is useful but limited to one such group only. This issue proposes a generalization of this concept where any number of such "abstract" groups could be defined and used to create convenient permission-only projects. The now existing "Project Owners" group will then be migrated to become just one special case of the new concept. An example where this feature would be useful is when a development team wants to differentiate between project admins and project committers where project admins don't have the submit permission and where project committers can't manage its own group. With the new concept a Gerrit admin could provide a convenient permission-only project to be inherited from. An "abstract" group should consist of a name (like "Project Owners" or "Project Committers") and an access-permission name (like "owner" or "committer"). The access permission will be used to associate the abstract group to a concrete group for a concrete project.
Dec 1, 2011
Project Member
#1
mf...@codeaurora.org
Dec 2, 2011
Martin, I didn't quite understand your comment. Especially I didn't see any need for groups "generated" by Gerrit or a need for a naming convention for group names. What an "abstract" group is allowed to do should be defined using the standard Gerrit access permission editor, like with any other group. Then on a concrete project an abstract group is resolved into a concrete group. Let me give an example: * gerrit administrator defines two abstract groups called Reviewers and Committers and also assigns permissions to them: label-code-review -1..1 Reviewers label-code-review -2..2 Committers label-verify -1..1 Committers submit allow Committers There is no restriction on the group name(s). It could be any name not yet used as a group name. Currently it is only possible to assign access permissions in context of a project. Here, we need to assign permissions to abstract groups outside of any project! This is also a new feature and a *difference* from my original proposal where I thought that access permissions for such abstract groups would always be defined in context of a permission-only project (like it is currently done for the Project Owners group). * Gerrit administrator creates a new project XYZ and makes use of the abstract groups to simplify the definition of access permissions: Project XYZ ----------- ... Reviewers map-to GroupA Committers map-to GroupB Committers map-to GroupC label-verify -1..1 GroupD ... * In scenario where development teams manage their own projects a development team may create a common permission-only parent project where they will inherit all their projects from. The dev.team can make use of abstract groups in their common parent project: Project CommonParent: --------------------- Reviewers map-to GroupA Committers map-to GroupB Committers map-to GroupC Project P1 Rights Inherit From: CommonParent --------------------------------- ... P1 specific permissions here... Does this sound reasonable?
Dec 2, 2011
I like this concept, but I would prefer to use 'role' as name for 'abstract group'. This would make the difference cleaner, a group has members and a role is a set of access rights that can be assigned together.
Dec 2, 2011
yes, I agree, "role" is a better name than the "abstract group". Let's name it role. |
|
| ► Sign in to add a comment |