My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
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
Status:  New
Owner:  ----


Sign in to add a comment
 
Project Member Reported by ziv...@gmail.com, Nov 22, 2011
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
Cool, I agree.  To make this work, I think that the new group names should probably be in a separate namesspace so that it is clear that they are "generated" by gerrit.  One simple way would be to prefix the ACL they mimick with something like ACL- or GERRIT-, so for example all the people with submit permission on a ref could be expressed as ACL-Submit.

Additionaly, we would probably need a way to express sub ranges for ACLs with ranges.  So for example, some groups which I may need to be able to express are: 
* all the reviewers for a ref:  ACL-Label_Code_Review:-2¦-1¦1¦2
* all the reviewers but not the approvers for a ref:  ACL-Label_Code_Review:-1¦1 (or stricter -1&1)
* all the approvers for a ref: ACL-Label_Code_Review:-2&2
Dec 2, 2011
Project Member #2 ziv...@gmail.com
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
Project Member #3 edwin.ke...@gmail.com
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
Project Member #4 ziv...@gmail.com
yes, I agree, "role" is a better name than the "abstract group".
Let's name it role.
Sign in to add a comment

Powered by Google Project Hosting