Skip to content
This repository has been archived by the owner on Jan 6, 2023. It is now read-only.

Feature request: Let user be in multiple permission groups #900

Closed
mantir opened this issue Apr 19, 2019 · 12 comments
Closed

Feature request: Let user be in multiple permission groups #900

mantir opened this issue Apr 19, 2019 · 12 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@mantir
Copy link

mantir commented Apr 19, 2019

It was already requested years ago in #1704 in an earlier version. I don't know if it's just not implemented in the directus admin app, because I can't select multiple roles for a user.

If a user could be in multiple permission groups he could create/read/update/delete items from collections with permissions "own role" from several roles.
I think this is essential for a good permission management. Otherwise I don't know how to implement a forum where some subforums are only visible to a small group of "meta"-users without bypassing the directus permissions.

The directus admin app would also need some changes then.
I would even try to implement this and make a pull request:
Where in the code I would probably have to make changes?

@benhaynes
Copy link
Member

benhaynes commented Apr 19, 2019

A few things to kick this off:

We have a role permission setting already

It works similar to what you're described — let me know what differences your project requires.

We have already implemented an architecture to support this

We refactored the architecture of the API user/role relationship to be a many-to-many in preparation for this. The "only" thing we need to do is write the code to merge permissions from the user's different roles (assuming the highest level of access prevails).

@rijkvanzanten would know best, but I think we would want to start with the ability to merge permissions and then we can update the App to support adding the users to multiple roles.

@benhaynes benhaynes transferred this issue from directus/directus Apr 19, 2019
@benhaynes benhaynes added enhancement New feature or request help wanted Extra attention is needed labels Apr 19, 2019
@rijkvanzanten
Copy link
Member

Yep! Like @benhaynes said, the main thing that's missing before we can "enable" this in the application is the fact that the API needs to combine all the permissions of all the groups that a single user is in, and make sure the highest permission applies. After that, the application update itself is a matter of switching out the dropdown for roles in directus_user for a one to many interface.

@benhaynes
Copy link
Member

To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.

This issue being closed does not mean it's not being considered.

@olionescu
Copy link

olionescu commented Sep 16, 2019

Hi, what is the "internal" status of this request? I am also interested to use the feature and willing to support implementing - if the road is short and clear enough for me to go. Links to relevant code are welcome.

@benhaynes
Copy link
Member

Hey @olionescu — the database M2M structure is there already, the main task remaining is to merge all permissions from the chosen groups. Obviously that's pretty broad, but @rijkvanzanten and @BJGajjar could add more details...

The first thing we'd want to do is draft up a document that describes exactly how we'll accomplish this. For example, that we'd use the SUM of all permissions, and how we merge other role features.

@rijkvanzanten
Copy link
Member

Generally speaking, I think "the highest permission counts" should be the way to calculate the combined permissions

@olionescu
Copy link

We checked our requirements and its now in question to use roles for modelling what we need: We want items in collections to be editable by not only one user. We may create a role per user and then it's about being in multiple permission groups.

But more direct would be to have a list of users we directly give the right to read/update/delete an item. Currently, directus creates and uses the »created_by« field in a collection to assign ownership. We may introduce a CSV field instead - or a M2M relationship to »directus_users« using a »Checkboxes Relational« interface. But, permission checking would involve custom endpoints or working on the core.

I did not find existing approaches to that kind of modelling, eventually for reason, as it interferes with the role based model. Is there interest in having user-based permissions? Where to continue discussing, for this solution seems off-topic right here? Thanks.

@rijkvanzanten
Copy link
Member

You can also add a status field to the collection and base the permissions off of that. It sounds like that would fit your usecase

@olionescu
Copy link

You think of having a role per user and a status value per item ID? Each Item may have "his" ID as status value too, thus access may be granted to each item per editing the users role access to that item ID's status line?

@rijkvanzanten
Copy link
Member

But more direct would be to have a list of users we directly give the right to read/update/delete an item

What I mean is: Create 1 role, add multiple users in there. Give this role the permission to update items with a particular status.

@benhaynes
Copy link
Member

This feature would add a lot of complexity, and doesn't seem to pass our 80/20 rule. It might make more sense to simplify this to a single role per user (M2O) and focus instead on Dynamic Permissions: #511

@rijkvanzanten @BJGajjar — should we set this to won't add and remove the M2M?

@benhaynes
Copy link
Member

Just to add a few other points, most permissions could be merged to the "highest" permission, but this will likely not be performant... and we need to efficiently fetch role permissions (and probably shouldn't cache them). Also, some things like nav_override can not be merged.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants