Access control rules are too complex as they stand right now. Look at issue 708 for just such an example. :-(
What happens when there are collisions between the rules? Especially with recent changes like commit 69796cb9b7b205ad5f55f3b1258bde4d60d3fa8c that blocks permissions by matching parts of the right? What if one parent "blocks" the other's rules? We would need a sane order to apply them.
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. :)
@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.
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.
