Workbench Access per Page

[danahertzberg]

Motivation

I want to give users access to a page not in the menu

Is your feature request related to a problem? Please describe.

I cannot restrict editing to a particular page if it is not in the menu.

Proposed Resolution

Add a taxonomy vocabulary called “Users” and add that vocabulary to all content types

Describe the solution you'd like

1. In the taxonomy vocabulary, add new terms that are the same name as the user NetID
   • Can this be done automatically? Make the list of these terms match the list of users?
2. Add a field to all content types that references this new vocabulary
3. Add configuration to workbench access or documentation on how to use
   1. Add taxonomy term (user NetID) to desired content
   2. Configure workbench access to deny access to unassigned content
      • /admin/config/workflow/workbench_access/settings
   3. Add access scheme for desired person
      1. /admin/config/workflow/workbench_access
      2. Make label match the NetID
         1. Allow by taxonomy term
         2. Check vocabulary called “Users”
         3. Select all entity types
   4. Save
   5. Select matching taxonomy term to allow access by editor

Describe alternatives you've considered

• Alternate modules ()
• Putting the pages in a hidden menu

Roles and Permissions considerations

A clear and concise description of how each of the following roles would be impacted by this change:

• ~Anonymous user: No change~
• ~Authenticated user: No change~
• Content editor: Can be restricted to edit certain pages
• ~Content administrator: No change~
• ~Administrator: No change~
• User administrator: Can modify access settings

Additional context

• Drupal contrib module - Automatic Taxonomy Terms
• ServiceNow ticket
• CWS Slack thread

[akslay]

You can restrict pages not in the menu if you use a taxonomy scheme instead of a menu scheme.

We also encountered issues where Workbench Access only works if you add the page to the menu using the "include menu link" checkbox from the node edit page, rather than through Structure > Menu. So instead of making editors manually change that for every page on the site, we opted for the taxonomy approach on our site too. Especially since taxonomy can be bulk applied from the Content overview page.

We did not automate creation of taxonomy terms based on NetID, though, so this might not even be relevant to what you're requesting; but, in general, it is possible to restrict pages not in the menu.

However, I think automatically creating taxonomy terms based on editors' NetIDs could potentially be a security and/or PII concern? Taxonomy pages are public by default, so it could potentially expose login usernames if visitors land on a taxonomy term page (/taxonomy-list/taxonomy-term). And on the PII side of things, it might need to be an opt-in selection on a per-user basis; otherwise we'd also potentially be exposing editors to unsolicited contact/requests/etc., since their NetID also ties in to their email address (especially since that info is also no longer "public" on directory.arizona.edu either, and requires a login to view).

I can't remember if those taxonomy pages are set to not be crawled/indexed by Google or not, but unless the site has disabled those views or walled them off to editors only, they are reachable by anonymous users. Worst case, though, someone would have to get through CAS even if they were able to obtain a username via the taxonomy page.

Using something like Rabbit Hole to wall off a specific taxonomy list and its terms to editors/admins only might get you around both of these concerns, though?

[danahertzberg]

Make taxonomy vocabulary "team" scoped rather than netID scoped

[danahertzberg]

Thanks Ashley! This is in line with some feedback I just received. The better intention on this is to create an "Editing Teams" taxonomy vocabulary so netIDs are not in any public format.

[danahertzberg]

See arizona.edu for example