Custom permissions overview

[MegaKeegMan]

Child issues

380 A contributor can easily control access rights to an individual node

372 Group owners and managers can administer a group

meeting notes:

We would like a permission system where as soon as something is published, it is easy to know who has access.

• if someone gets added to a group after a group has been give permission, the new member should also have access
• if someone is removed from the group, they should no longer have permission, unless they were given permission as an individual
• Don't want any artifact inheriting permissions from anything above it.
• see https://pece-project.github.io/drupal-pece/permissions/ for reference
• viewing and editing permissions are managed separately

questions:

• does this only apply for artifacts, or other types of content too

Plan (to be broken out between issues 372 and 380)

As mentioned below, there will be 4 fields on a node for managing access:

• users with view
• users with edit
• groups with view
• groups with edit (this will be implemented later)

Groups will have members and managers.

• when a group is given view or edit access, any member of that group gains access
• managers also gain access the same way
• Possible that managers should have edit access to a group term
• for the most part though, the difference between a member and a manager is that a manager can administer group members and managers

To give someone group membership, the group term needs to be added to the "Groups joined" field on their account. We will want a different UI for adding members to a group, but important to note that with the access_policy module, groups are taxonomy terms on the back end.

To make someone a manager, the group term needs to be added to a "Groups managed" field on their account.

One recommended approach to this is to implement a views bulk update plugin for managing groups (terms) For clarity, a group as a whole would be given view or edit access.

[MegaKeegMan]

Worth experimenting with https://www.drupal.org/project/tac_lite

[MegaKeegMan]

https://www.drupal.org/project/access_by_ref

[MegaKeegMan]

I tested the access by ref module and it looks like it meets our needs quite well. Going this route would involve keeping the group content type, and adding 2 user reference fields to the group content type:

• users with edit access
• users with view access You could name them group managers and group members, but I would intend to re-use these fields on artifacts. Once these fields are set up, add access by ref (abr) config for each of these fields (for group node) and configure access accordingly.

We can add these fields to each artifact content type as well (maybe a good argument for slimming down to a single artifact content type Ref #368 , and then the abr config needs to be added for each field/content type combination.

Lastly we can add a field to reference group nodes, and then add abr config to give users with access to that group node access to artifacts where the group has been referenced by this field.

This would mean 4 fields on artifact:

• groups with edit access
• groups with view access
• users with edit access
• users with view access

I attempted experimenting with allowing the anonymous user to be referenced, and that did not work. We would need to enable that functionality another way, which is not such a big deal. Maybe we wanted to keep a checkbox for public/private access anyway.

[MegaKeegMan]

An issue on preventing anonymous users from access: https://www.drupal.org/project/access_by_ref/issues/3352192

[MegaKeegMan]

https://www.drupal.org/project/access_policy is currently my top candidate, which can be configured to provide a similar editing experience to access_by_ref, but the module is much more configurable. My current approach involves only one access policy, which is not exposed to anyone besides a site admin, and is the default policy. Will show a picture to demonstrate the node editing experience in #380