This is a proposal for handling project hierarchy in effective access level computation.
The original reason why I would like to implement inherited access levels is that I have a use case where access is restricted by default and there is a lot of private projects, sub-projects and sub-sub-projects, for which some users should have the same access level all over, and I don't want to have to add them as members for every single project, and I cannot give them public access; also, some users might have to get restricted access to part of the project tree, and again, I don't want to have to add this in every project in the sub-tree.
I did read some previous discussions on access level inheritance, notably https://github.com/mantisbt/mantisbt/pull/1260 where the issue of multiple parents is raised.
Currently, the effective access level of a user U in a project P is either the project access level of U in P if U is a member of P, or else the user access level of U if P is public, or else none.
Under the proposed change, the effective access level of U in P would be either the project access level of U in P if U is a member of P, or the inherited access level of U in P if it is greater than none, or the user access level of U if P is public, or else none.
The inherited access level of a user U in a project P would be computed from U's memberships in direct and indirect ancestors of P.
A simple example is
- A user U with default access level "guest"
- A project P1 where U is a member with "developer" level
- A project P2 where U is a member with "reporter" level
- A project C which has P1 and P2 as parents
The computation of the inherited access level L(U,P) of user U in project P would be as follows:
- If U is a member of P then L(U,P) equals the project access level of U in P
- Else if P has parents P1..Pn then L(U,P) equals the least of all L(U,Pi) where L(U,Pi) is greater than none
- Else L(U,P) equals none
- If a project defines an access level for a user, then the project parent's access levels for this user are irrelevant
- If a project does not define an access level for a user but has parents, then the inherited access level is the most restrictive of the parent's access levels, possibly themselves inherited.
- If a project does not define an access level for a user and has no parents, then the usual public/private rules apply and the access level is either the user's default one or none
Public vs private projects:
In this proposal, the public/private status of a project's ancestors is involved in computing the effective access level, but not the inherited access level. This is deliberate, to keep the semantics of public vs private unchanged: a private project does not take a user's default access level into account at all, and a public project takes it into account only if it cannot determine a project-specific level.
Semantics of access levels
MantisBT operates on the general assumption that a higher access level means more access rights, with many thresholds and comparisons throughout the code base. While this assumption holds as long as there are only three access levels including "none" (no rights) and "administrator" (all rights), it does not hold for customized intermediate access levels; customized access rights may lead to the impossibility to order access levels by increasing rights, which in turn might complicate user access level management.
This proposal does not change the access level semantics and therefore does not solve level management issues; it aims to solve only user management issues.