Proposal for access level inheritance

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
aaribaud-fgs
Posts: 4
Joined: 28 Feb 2019, 15:59

Proposal for access level inheritance

Post by aaribaud-fgs »

SUMMARY

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.

DESCRIPTION

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
Under current rules, the effective access level of U in C would be "guest"; under proposed rules, it would be "reporter", which is the least of P1's "developer" and P2's "reporter".

DETAIL

The computation of the inherited access level L(U,P) of user U in project P would be as follows:
  1. If U is a member of P then L(U,P) equals the project access level of U in P
  2. 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
  3. Else L(U,P) equals none
The intended semantics of this computations are:
  • 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
NOTES

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.

Comments welcome.
atrol
Site Admin
Posts: 8366
Joined: 26 Mar 2008, 21:37
Location: Germany

Re: Proposal for access level inheritance

Post by atrol »

aaribaud-fgs wrote: 01 Mar 2019, 09:10 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.
No true, maybe you got confused by the word "threshold".
I assume you understand what I mean if you goto page Manage > Manage Configuration > Workflow Thresholds
Please use Search before posting and read the Manual
aaribaud-fgs
Posts: 4
Joined: 28 Feb 2019, 15:59

Re: Proposal for access level inheritance

Post by aaribaud-fgs »

Hi Atrol,

You are right that user level is not the only access rights mechanism in Mantis, and that notably, workflow thresholds are not controlled by user level, and espacially not by level ordering, but through a configurable matrix which maps sets of unordered user levels to permissions.

It remains true, though, that in many other parts of Mantis, user levels are processed exclusively as control threshold mechanisms, for instance through global configuration variables such as g_notify_new_user_created_threshold_min, g_show_user_email_threshold, g_show_user_realname_threshold, g_show_version_dates_threshold, which are clearly named as user level thresholds and commented accordingly. These controls have no associated permission matrix.

It is also true that right now, as far as access control goes, each user gets given a level, not a permission set, in contrast to, say, MySQL, where users do not have levels at all, only permissions. Users have a global access level, and an per-project level, not permission sets.

Are there plans for Mantis to generally replace these acces-level-based checks with permission-based checks along with new entries in the permission matrix? If so, I am all for going along and replacing the recursive access level computation in my proposal with a recursive permission set computation, based on the same approach, i.e., the inherited permission set would be the intersection of the parent's (possibly inherited) permission sets.

If there are no such plans, though, then I think my proposal provides, under the current code limits, a useful mechanism for simplifying day-to-day user permission management in a many-projects use case such as mine.

This would not preclude Mantis from later switching to a permissions-only mode, of course, and when this happens, since I need the user permissions inheritance mechanism, I will gladly contribute to the switch by porting the feature over to such a permission-only mode.

Thanks for your feedback.
atrol
Site Admin
Posts: 8366
Joined: 26 Mar 2008, 21:37
Location: Germany

Re: Proposal for access level inheritance

Post by atrol »

I can invest hardly any time for Mantis at the moment.

A better place to discuss such topics where more developers are listing is https://gitter.im/mantisbt/mantisbt
Please use Search before posting and read the Manual
cproensa
Posts: 8
Joined: 24 Aug 2015, 11:37

Re: Proposal for access level inheritance

Post by cproensa »

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
Why the least? That's an arbitrary assumption.

It remains true, though, that in many other parts of Mantis, user levels are processed exclusively as control threshold mechanisms, for instance through global configuration variables such as g_notify_new_user_created_threshold_min, g_show_user_email_threshold, g_show_user_realname_threshold, g_show_version_dates_threshold, which are clearly named as user level thresholds and commented accordingly. These controls have no associated permission matrix.
No. Any threshold can be either an integer value or an array of values. What you see in the default config file is a simple approach. Any of those thresholds can be set as an array, in a custom file, or in the database, and the code will interpret them fine.

Are there plans for Mantis to generally replace these acces-level-based checks with permission-based checks along with new entries in the permission matrix? If so, I am all for going along and replacing the recursive access level computation in my proposal with a recursive permission set computation, based on the same approach, i.e., the inherited permission set would be the intersection of the parent's (possibly inherited) permission sets.
I don't expect it. I'm not sure if that (big) change would lead to a simpler scenario anyways.

If there are no such plans, though, then I think my proposal provides, under the current code limits, a useful mechanism for simplifying day-to-day user permission management in a many-projects use case such as mine.
Actually, a better approach to simplify all this would be to implement user groups. That's not an easy task, either, but i think that the benefits are relatable.
**since I need the user permissions inheritance mechanism**
You know, i understand your pain, since i suffer the same problems. But, what i have become to realize is that part of the problem is the fact that you (we) are using too many projects/subprojects.
This can open another extensive topic by itself, but some of the ideas are: why are you using projects? probably because user access granularity is at project level, workflow permissions are at project level, etc. If i had some of that functionality tied to categories, for example, i could probably replace one whole level of subprojects ramifications with categories that could be then tied to individual users (or groups).

I'd be more interested to hear the exact reasons you need a lot of projects, because, the solution may be to look at another angle.
aaribaud-fgs
Posts: 4
Joined: 28 Feb 2019, 15:59

Re: Proposal for access level inheritance

Post by aaribaud-fgs »

Why the least? That's an arbitrary assumption.
Indeed; since access level is implicit rather than explicit, I prefer to err on the conservative side and only grant as few privileges as possible -- knowing that if I want a user to have more rights than (s)he would inherit, then I can just add that user to the project with the required access level.
Any threshold can be either an integer value or an array of values. What you see in the default config file is a simple approach. Any of those thresholds can be set as an array, in a custom file, or in the database, and the code will interpret them fine.
An integer value is fine for me, but I suspect I could extend the proposal with arrays.
You know, i understand your pain, since i suffer the same problems. But, what i have become to realize is that part of the problem is the fact that you (we) are using too many projects/subprojects.
This can open another extensive topic by itself, but some of the ideas are: why are you using projects? probably because user access granularity is at project level, workflow permissions are at project level, etc. If i had some of that functionality tied to categories, for example, i could probably replace one whole level of subprojects ramifications with categories that could be then tied to individual users (or groups).

I'd be more interested to hear the exact reasons you need a lot of projects, because, the solution may be to look at another angle.
I have a requirement to manage a hierarchy of activities and the ability to launch activities, create issue for any of the "leaf" activities, and close activities at any time, and keep a history, and not have to manually add the same set of users to each new project -- that's the killer: lots of projects to add frequently, all with the same set of users and workflow. Workflow I can make global, so that leaves only the user set problem.

Hence my proposal: it would allow me to add users with their associated access levels only once in a common ancestor project and then any new subproject of it would immediately have the correct effective access levels.

Re categories: even if categories could be associated with users or user groups, this would not be any use for me, as each time I create a new activity, instead of having to manually add users I would still have to manually add categories.

What I might be able to work with instead of inherited user access level computation, would be the ability for a subproject to inherit its user list from its parent (I do not use multiple parents). If I can enter a user list once in a (template) parent project and have any new subproject I create automatically have the same user list, then there would be no manual addition to do and I'd be fine -- for subproject creation only. If I needed to add a new user to the parent project, I would have to go through all active subprojects manually.
brlumen
Posts: 1
Joined: 24 Jul 2018, 02:54

Re: Proposal for access level inheritance

Post by brlumen »

Hello!
I think I have what you ask.
Try my plugin:
https://github.com/brlumen/MantisServic ... ease-1.8.0

You may have problems with setting up the plugin, as it is not yet ready for public release.
In any case, if you are interested in them, let me know and I will help to adapt the code to your language.

In short, the plugin implements inheritance in projects by users.
I implemented the inheritance through tracking the process of adding a user to the parent project, and automatically adding his own (user) to all nested projects.

Also in the plug-in there are several more functions that help to use MantisBt in my script (Service Desk)
aaribaud-fgs
Posts: 4
Joined: 28 Feb 2019, 15:59

Re: Proposal for access level inheritance

Post by aaribaud-fgs »

Tanks brlumen, however the only plugins I could use would be those listed on the official MantisBT site, which yours is not (yet).
Post Reply