A contributor can easily control access rights to an individual node

[MegaKeegMan]

• [ ] can specify which individual users should have view access
• [ ] can specify which individual users should have edit access
• [ ] can specify which groups should have view access
• [ ] can check a box to determine that all site visitors should have view access

[MegaKeegMan]

There is also a "users with edit access" in this field set below

[MegaKeegMan]

It would probably be good to use conditional fields module to hide these view access fields when the "All users can view this content" toggle is enabled, like it is in the picture above.

So far I am only demoing this on the field note artifact content type, but will just need to add these fields to all other artifact content types, and anywhere else desired. Will do some more testing now.

[MegaKeegMan]

Testing the following on branch 373-access-policy

Acceptance criteria:

• [x] the "All users can view this content" toggle is enabled
  • [x] An anonymous user can view
• [x] A user is given view access to a node
  • [x] the listed user can view the node
  • [x] a non-listed user cannot view the node
• [x] A user is given edit access to a node
  • [x] the listed user can view the node
  • [x] the listed user can edit the node
  • [x] a non-listed user can neither view nor edit
• [x] A group is given view access to a node
  • [x] a user who has joined that group can view the node
  • [x] a user who has not joined that group cannot view the node
• [x] No users or groups are given access of any kind, and the toggle is disabled
  • [x] the node owner can view/edit the node
  • [x] another logged in user cannot view or edit the node
  • [x] an anonymous visitor cannot view the node

[MegaKeegMan]

In order to get these all to work under the access policy implementation, I had to make sure that contributor and researcher roles been given permission to edit nodes of each of the artifact types, and then of course make sure that the users that had been given access via any of the mechanisms in the previous comment had also been given this role. Everything worked properly in that case. To clarify, the point of an access policy is to place additional restrictions on who can view the content, and not to provide access to people who would not have been given it otherwise.

[MegaKeegMan]

Considering some other criteria that I don't believe have been met yet:

• [ ] contributor/researcher cannot give access to groups that they do not belong to
• [ ] cannot remove access from groups they do not belong to?
• [ ] admin can give/remove access to/from any group

Not 100% sure about these criteria, but important to consider.

[MegaKeegMan]

And then:

• [ ] a user can only be given permission to edit if they have the permission to edit nodes of the current node type
• [ ] a user can only be given permission to view if they have the permission to view published nodes of the current node type (currently everyone has permission to view all published nodes)

Considering that the most straightforward way to go about this will be using a view to define the select lists, and filtering that view by role (contributor and platform manager). A similar view like this does already exist: Users (Entity Reference Field - User)

I have considered that it would be nice to instead filter the view based on who has access to edit the current node, but this is a tad more complicated, and maybe should not be prioritized. The advantage would be that customized instances could create custom roles without breaking this feature.

[wolcen]

Attempted to test yesterday - I failed at this, the main reason being I was using the old group security model/content type - this requires using the Group taxonomy term instead.

Added fix for user roles to create content type and attach the content access policy to those content types.

Covered all the criteria in https://github.com/PECE-project/drupal-pece/issues/380#issuecomment-1874649271

[MegaKeegMan]

Substantive logic nodes are slightly different from other node types. Everyone should have view access, but only specified individuals should have write access. At the moment, since groups are not being granted edit access, the only visible permissions related field is "People with edit access". The "Everyone can view this content" field is also present, but is not displayed on the form, since a content editor should not have the option to toggle this off.