SHS-5907: Implementation: Editors can easily set "view" access for Private Pages

[codechefmarc]

READY FOR REVIEW

Summary

• Adds a new contrib module content_access_simple that adds a simpler interface for settings view permissions per node.

Need Review By (Date)

2024-11-06

Urgency

low

Steps to Test

1. Login to the site as an admin
2. Create a Private Page
3. Title it
4. Verify there is a new area below all of the fields called "Access and Permissions"

6. Open it up and verify that there is a list of roles under "Visibility" but there is not "Developer", "Anonymous", or "Authenticated".
7. Choose a role, like "Site Manager" and enable view access
8. Save the node
9. Visit the "Access control" tab for this node
10. Verify that under "View any hs_private_page content", the "Site Manager" is checked in addition to "Developer" and "Authenticated user" (which were the defaults originally but they are hidden as per config)
11. Uncheck "Authenticated user" under view any here, and save
12. Attempt to view the page on a logged in user who is not "Site Manager" role and verify that you cannot access it
13. Attempt to view the page on a logged in user who is "Site Manager" and verify that you can access it
14. Edit the node and verify that under "Access and Permissions" you get a "complex" warning and no roles are listed

16. To fix, visit the content type permissions at /admin/structure/types/manage/hs_private_page/access and also uncheck "Authenticated user" and save
17. Edit the node again and this time, and this time, mark the node as unpublished and save
18. Edit the node and verify that under "Access and Permissions" you get a "unpublished" warning but the roles are still listed

20. Visit /admin/structure/types/manage/hs_private_page/form-display and drag the "Content Access Simple" "field" to another place in the form and save
21. Edit the node and verify that the Access and Permissions has moved.

PR Checklist

• PR Checklist
• Humsci Basic PR Checklist

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208890594589119

[dalin-]

Phewph, that's a lot to review.

First up, the the code in the other repo:

---

https://github.com/codechefmarc/content_access_simple/blob/9b9135ad1b89dcaebe908673c102fa7063fd7deb/content_access_simple.info.yml#L5
We might be able to get a jump and call it 11 compatible?

---

https://github.com/codechefmarc/content_access_simple/blob/9b9135ad1b89dcaebe908673c102fa7063fd7deb/content_access_simple.module#L46
We also need to check if the extra field has actually been enabled. Something like

$fieldIsEnabled = $display->getComponent('content_access_simple');

---

https://github.com/codechefmarc/content_access_simple/blob/9b9135ad1b89dcaebe908673c102fa7063fd7deb/src/AccessManager.php#L72

I'm not sure it's a good idea to include "own access" here. In the spec it talks about mostly ignoring the whole concept (i.e. if you're doing stuff with "own access", then it's no longer "simple").

---

https://github.com/codechefmarc/content_access_simple/blob/9b9135ad1b89dcaebe908673c102fa7063fd7deb/content_access_simple.module#L92

How does Content Access work without our custom module installed? If you create a new node, then change the defaults for that bundle, does the node use the old defaults, or the new defaults? I suspect the former (and our new module will do the same), but if it's the latter, then we'll need to update our code to match.

---

And then from functional testing:

• Need to rename "Authenticated" as "All logged in users" (just on this form, not globally)
• Need help text "Only the chosen roles will be able to view this content..." this needs to be configurable.
• Unpublished message doesn't match the spec', and needs to be configurable.
• I'm not sure that your plan for not disabling checkboxes will work. Site Manager needs to be visible but disabled.

[codechefmarc]

@dalin- Updated the code and here are my comments on yours:

1. Drupal 11 - updated the info file and did a check with Upgrade Status module so it is ready for D11
2. Good catch on checking to see if the field is enabled in the default display. I added that feature in.
3. The "own access" here (https://github.com/codechefmarc/content_access_simple/blob/9b9135ad1b89dcaebe908673c102fa7063fd7deb/src/AccessManager.php#L72) is actually our own module permissions, not content access. However, I see your point in wanting to make this module more simple, so I removed it and there is only one permission to use this module now.
4. In content access, they do not show the "Access control" tab when you first create a node. They only show it after the fact on the edit page. The defaults come from the content type settings itself via content_access_node_access_records which is a hook that sets permissions on node save. It, in turn calls this line: return $grants[$node->id()][$op] ?? content_access_get_settings($op, $node->getType()); which essentially gets the per node setting, but if that doesn't exist, use the setting from the content type. Since we're showing our form elements on the add page, we need a way to get the defaults first. Unless you want to follow content access and not show our stuff on the add page and instead only show it on the edit page?
5. Renamed "Authenticated" to "All logged in users"
6. Help text added and is part of the config
7. For the unpublished message - I did make this dynamic and list roles who can view unpublished based on the View Unpublished module permissions which Stanford has, but, not all sites will have that module. So, I can also add a config-based unpublished message that will take precedence if set in config. I like the idea of the dynamic one, but it does sort of depend on the view unpublished module. I'm out of hours for this project this week, so I'll make that change next week.
8. Added logic and config for disabled roles. When I first read the spec, I didn't get it and was going to reach out to you, but I understand now.
9. We can certainly hide Stanford specific roles with their config, and I'll do that in this PR to test next week. As part of the module, I only hid the ones that made sense out of the gate for contrib.

[dalin-]

@codechefmarc

Since we're showing our form elements on the add page, we need a way to get the defaults first. Unless you want to follow content access and not show our stuff on the add page and instead only show it on the edit page?

Makes sense. No changes needed.

For the unpublished message... I'm out of hours for this project this week, so I'll make that change next week.

Sounds good.

As part of the module, I only hid the ones that made sense out of the gate for contrib.

Ooooh, smart.

---

On
https://hs-traditional-nibcuwfk1qrcj3cnraoyrgs4360qz81k.tugboatqa.com/
I masqueraded as "Lindsey" who is a Site Manager

When I try to edit an existing private page, our new field is not there

But maybe this is more about generic config vs our config.

---

Lastly, there's a lot of code changed in this PR that seems unrelated. Maybe it needs to merge in the source branch.

[codechefmarc]

Ahh, for "Lindsey", I know why - we have permissions for our module too and that wasn't set as part of this PR. I'll need to make that change for Site Managers in the config and do an update hook as well.

And yup, I had the base incorrect for the merge, so I changed it to the 11.5.2 release branch as the base and now there's only a handful of files changed.

However, I'd like to discuss with you how we do this deploy - if we do want this as a contrib module, once we get everything buttoned up, I'll upload to Drupal.org then change composer.json to point to that version and not my repo.

[dalin-]

@cienvaras

However, I'd like to discuss with you how we do this deploy - if we do want this as a contrib module, once we get everything buttoned up, I'll upload to Drupal.org then change composer.json to point to that version and not my repo.

You might want to bring this up in your weekly call with Albert + SWS. I'm happy to let you handle it, or let me know if you want my opinion.

[cienvaras]

@dalin-

You might want to bring this up in your weekly call with Albert + SWS. I'm happy to let you handle it, or let me know if you want my opinion.

We don't have meeting with SWS, but I can ask Joe on the chat. I'd like your opinion though, I haven't been fully involved on this ticket and there are things I might be missing.

[dalin-]

@cienvaras
I suspect that we'll need to go through a couple of rounds on this:

1. Get SWS review on the generic module.
2. Get H&S review of the UI/UX.
3. Publish it to drupal.org
4. Create a follow-up task to integrate the contrib module into our site.

[codechefmarc]

@dalin- Reverted many of the changes in composer.lock except for the content_access_simple stuff. Also, in the d.o. repo, thank you for the comments, I did change things to use the Xss filter, great idea.

[dalin-]

🚢

[cienvaras]

@ahughes3 This one is ready for you to review.

[ahughes3]

@cienvaras @codechefmarc @dalin- We are still receiving the MySQL error has gone away message when attempting to save. What steps did you all take when testing to resolve on Tugboat?

It looks like the pr with recommended fix was merged but maye this line should be added as well to the config file

- echo "max_allowed_packet=536870912" >> /etc/mysql/conf.d/tugboat.cnf

Also in the UI we noticed that this image was not the same as the image in the testing results

[ahughes3]

Tugboat has finished building the preview for this pull request!

Links:

• https://pr1679-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com
• https://hs-colorful-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com
• https://hs-traditional-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com
• https://english-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com
• https://history-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com
• https://west-zq6vphgiftb2pxvim53aktrp2y838boa.tugboatqa.com

Dashboard:

• https://dashboard.tugboatqa.com/67630b2e252c7a7b92cff1a0