Bug #13202

Regression: Custom groups with Create and Publish permissions cannot access the Add menu or publish descriptions

Added by Dan Gillean 10 months ago. Updated 9 months ago.

Status:VerifiedStart date:10/11/2019
Priority:MediumDue date:
Assignee:Dan Gillean% Done:

0%

Category:Access Control
Target version:Release 2.5.3
Google Code Legacy ID: Tested version:2.5, 2.6
Sponsored:No Requires documentation:Yes

Description

Reported in 2.5; reproduced in qa/2.6.x

This regression seems to be caused by the changes made in #11075. Specifically, I think it's this part:

There is no provision in here for, if a custom group has Create permissions, for them to access the Add menu - only the specified groups (Creator, Editor, Administrator) can access it.

This issue is affecting portal sites where custom groups have been added to limit edit permissions on other descriptions. An example set of description permissions for a custom group, which worked in 2.4 and earlier but broke after upgrading, is attached.

The same appears to be happening with the Publish descriptions permissions, though I can't see exactly where in the PR that is implemented.

Consequently, there is no way for users to create custom groups and still be able to add descriptions. This affects any multi-repository users trying to provide varying levels of access using groups.

To reproduce - Test 1

  • Log in as an admin and create a custom group - grant all permissions
  • Create a new user and add them to the group
  • Log out and log in as the new user

Resulting error

  • No Add menu available

Expected result

  • Because the user has permissions to create archival descriptions, at the very least the Add menu should show with the Archival description option.
  • Users upgrading with custom permissions should not be losing access to the Add menu as a result of #11075

Test 2

  • Same as above, but first, give the authenticated group Create permissions
  • Outcome: same as above

Test 3

  • Give the authenticated group ALL permissions first
  • Outcome: same as above

Test 4

  • As an admin, modify the default Editor group to deny all description permissions
  • Grant all permissions to the custom group
  • Add the test user to both the Editor and the Custom group

Outcome:

  • User gets the add menu
  • User can create descriptions, but as soon as they click save, they are given a permission denied message for viewing the record - despite the fact that the custom group has View draft, Update, Read, Create, and Publish permissions

Notes

This issue was a result of the changes made in #11075, which attempted to solve multiple issues at once - namely:

  1. authenticated users who were part of no group could access restricted modules, such as accessions, rightsholders, donors, physical storage, etc.
  2. authenticated users who were part of no group could access the Add menu, even if clicking through to the links generally led to a Permission denied message.

The attempted solution was to add Security YAML configuration files for these modules, which control access based on default group permission. The side affect of this was that any custom groups lost basic add permissions, and access to the add menu.

This ticket will resolve the first issue (with custom groups not being able to access add menu options regardless of permissions settings). However, the tradeoff is that the second issue (hiding the Add menu from authenticated users) is not currently possible without a larger overhaul.

I've confirmed that none of the Add menu links will work for authenticated users, unless the permissions have been customized. Below is an updated summary of the new default permissions, and what is configurable or not.

Permission defaults

  • All authenticated users will see the Add menu. By default, authenticated users cannot click through any of the options.
  • Only users with custom Create permissions (via the permissions module) will be able click through on the Archival description, Authority record, Term, and Repository nodes in the Add menu
  • Only Contributors, Editors, and Admins will see the Functions option in the Add menu, and can create functions
  • Authenticated users and custom group users will only see Jobs in the Manage menu by default.

The following permissions are controlled by YAML-based security configuration files. Users can customize these files as needed, even adding custom group names (PHP-FPM should be restarted after making changes and all caches cleared):

  • Only Administrators, Contributors, Editors, and Translators can view physical storage records (via link or direct URL)
  • Only Administrators, Editors, and Translators can browse and edit physical storage records
  • Only Administrators and Editors can delete physical storage records
  • Only Administrators should be able to browse and delete rights holders
  • Only Administrators should be able to browse the search/descriptionUpdates page
  • Only Editors and administrators should be able to browse, and view detail pages for, taxonomies
  • Only Translators, editors, and administrators should be able to browse all taxonomies
  • Only Contributors, editors, and administrators should be able to browse accessions
  • Only Translators, editors, and administrators should be able to edit accessions
  • Only Contributors, editors, and administrators should be able to browse donors
  • Only Translators, editors, and administrators should be able to edit functions
  • Only Translators, editors, and administrators should be able to edit repositories

example-custom-group-io-permissions.png (77.3 KB) Dan Gillean, 10/11/2019 05:14 PM


Related issues

Related to Access to Memory (AtoM) - Bug #11075: Authenticated users can access browse pages and functiona... Verified 04/13/2017
Related to Access to Memory (AtoM) - Bug #13205: Adding multiple ACL group taxonomy rules - only last one ... New 10/24/2019

History

#1 Updated by Dan Gillean 10 months ago

  • Related to Bug #11075: Authenticated users can access browse pages and functionality that should be restricted to groups added

#2 Updated by Dan Gillean 10 months ago

  • Description updated (diff)
  • Target version set to Release 2.5.3
  • Requires documentation set to Yes

I've updated the ticket description with the results of the changes made in this ticket, as well as in #13169

#3 Updated by Steve Breker 10 months ago

  • Status changed from New to Code Review

Merged MikeC's work into this PR: https://github.com/artefactual/atom/pull/987

Ready for CR.

#4 Updated by Mike Cantelon 10 months ago

  • Status changed from Code Review to Feedback
  • Assignee set to Steve Breker

Looks good to me!

#5 Updated by Steve Breker 10 months ago

  • Status changed from Feedback to QA/Review

Merged to qa/2.6.x

#6 Updated by Dan Gillean 9 months ago

  • Related to Bug #13205: Adding multiple ACL group taxonomy rules - only last one added applies added

#7 Updated by Steve Breker 9 months ago

  • Assignee changed from Steve Breker to Dan Gillean

Picked to stable/2.5.x.

#8 Updated by Corinne Rogers 9 months ago

  • Status changed from QA/Review to Verified

Also available in: Atom PDF