User with update permissions for only one repository can update other repositories' records
|Google Code Legacy ID:||atom-1710||Tested version:|
To reproduce this error:
1)Create a user and modify permissions similar to the attached screenshot
2)Log in as the user
3)Navigate to an information object belonging to a repository that is not the repository for which the user has update permission
User can update information objects belonging to repositories other than the one s/he has permission for
User should be able to update information objects belonging only to the specified repository
[g] Legacy categories: Access control
#1 Updated by Evelyn McLellan over 11 years ago
- Subject set to User with view draft/update permissions for only one repository can view drafts of and update other repositories' records
- Priority changed from High to Critical
Also, user with view draft permissions for one repository only can view drafts of descriptions belonging to other repositories. Am changing title to reflect this and upgrading the issue to critical.
[g] Labels added: Priority-Critical
[g] Labels removed: Priority-High
#2 Updated by David Juhasz over 11 years ago
- Subject set to User with update permissions for only one repository can update other repositories' records
- Priority changed from Critical to High
- Target version changed from Release 1.1 to Release 1.2
- File acl2.png added
This is two separate issues. I've created /p/qubit-toolkit/issues/detail?id=1821 to address the "view drafts" problem.
I'm bumping this issue (Related to editing descriptions in other repositories) because you can avoid the problem by using the permissions shown in the attached screenshot "acl2.png", and solving for the original ACL case is complex.
[g] Labels added: Priority-High, Milestone-Release-1.2
[g] Labels removed: Priority-Critical, Milestone-Release-1.1
#3 Updated by Tim Hutchinson about 11 years ago
See also /p/qubit-toolkit/issues/detail?id=1311. Since I didn't initially clue into the details of the screenshot above, I will just add that the key is to add permissions to the authenticated group, rather than assigning the user to an editor/contributor group and then denying roles for all information objects and adding back roles for a single institution (as documented in the user manual).
#6 Updated by Anonymous over 10 years ago
- Priority changed from Low to High
The user manual has been changed to reflect the new "workaround" for restricting a user permissions to a single repository; however, the question has been raised as to how this will impact Memory BC migration.
[g] Labels added: Priority-High
[g] Labels removed: Priority-Low