| Issue 710: | multiple project parent inheritance | |
| 9 people starred this issue and may be notified of changes. | Back to list |
I find that specifying only one project to inherit access controls from is rather limiting. It'd be nice if we could specify multiple parents and get the union of their access control lists.
Sep 6, 2010
We currently also have a need to apply rights in a matrix-wise fashion. We have several internal groups that have divided the projects among them, and then we have external vendors that want to deliver a full platform to these gits. Example: Org A owns group of gits, git group A which is sorted under one parent A Org B owns other group of gits, git group B which is sorted under other parent B Vendor C wants to deliver a platform, which is a combination of: 1. one group of gits not owned by Org A or B (easy to classify under separate parent C) 2. one subset of group A, so many but not all gits 3. one subset of group B, so many but not all gits Currently I end up setting rights on a parent C, plus scripting individual permissions to each project found under condition 2 and 3. I heard something about "tags" or "labels". If we will be able to set rights on labels, the matrix permissions will be doable. As far as I can tell, we've so far given the highest bidder the right of way, it's already a situation with rules from several stacking parents, isn't it? IIRC we've tested inheritance from parents and grand parents and came out with a highest bidder style combo. That should be repeatable? That means, if several inherited rules comes in affecting the same primary key (combo of ref_pattern, project, category_id, group_id?), the permissions stack up and grants the most generous offer. Whenever that's a problem (and in practice that's probably most likely to happen with a READ, no?) you need to grant a lower rule specifically in the git to override any inherited value(s). Maybe you can tell I havn't read the code, I may be wrong in my assumptions. My statement reflects a solution I consider possible if my assumption aren't completely off the scale. Comments on this are most welcome. :)
Apr 13, 2011
@fredrik, have you started on this change at all? @sop, you did give the go-ahead for this at gitTogether this year, correct? We've been looking into doing something similar to this without actually doing the multiple inheritance feature in Gerrit, but we're at the point now where I think the overhead would be too great without native Gerrit support.
May 19, 2011
This is going in on top of the git-store changes.
Status:
Started
May 20, 2011
Martin is working on https://review.source.android.com/22871
Owner:
mf...@codeaurora.org
Cc: -mf...@codeaurora.org Labels: Milestone-2.2.0
Feb 23, 2012
I gave up on this for a while. I am removing myself in case someone else wants to pursue it in the meantime. If you do, it is probably worth looking at my first 2 attempts, but the ACL code has changed drastically since then, that is why I have yet to finish this.
Owner:
---
May 9, 2012
(No comment was entered for this change.)
Labels:
-Milestone-2.2.0
|
|
| ► Sign in to add a comment |
Status: AwaitingInformation