Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add "Restricted" view rather than requiring read permissions to each visible subview #2714

Open
grantfitzsimmons opened this issue Dec 29, 2022 · 1 comment · May be fixed by #4893
Open

Add "Restricted" view rather than requiring read permissions to each visible subview #2714

grantfitzsimmons opened this issue Dec 29, 2022 · 1 comment · May be fixed by #4893
Assignees
@melton-jason
Labels
1 - Request Improvements or extensions to existing behavior 2 - Security & Accounts Issues that are related to the permission system and user accounts
Projects
Users & Permissions

Comments

@grantfitzsimmons
Copy link
Member

image

image

In this instance, my user has permissions to read and create CO records along with read permission to a few other tables but I am unable to view a CO record since I don't have read permission to the Collection Object Attribute table.

Specify 6 had a more "elegant" solution compared to a complete block.

(If you catch this issue in time, the user is DemoUser (pw: testuser) on the sp7demofish site)
@grantfitzsimmons grantfitzsimmons added 1 - Request Improvements or extensions to existing behavior pri:unknown labels Dec 29, 2022
@maxpatiiuk maxpatiiuk mentioned this issue Dec 29, 2022
Merged
@maxpatiiuk
Copy link
Member

This is a limitation of the permission system at the moment:

If user has read permission to a table, the user must also have read permissions to all the dependent relationships as they are included together in the API response.

A workaround would be to display a different form for such users that doesn't include the subviews you wish to hide (or just give people the read permission to the related table - you don't have to give them edit permissions)

We could have the back-end mask out the dependent relationships before sending them to the front-end, but like Ben mentioned at the time that could have potentially catastrophic consequences:
Once front-end edited a resource with dependent relationships cut out, and sends that to the back-end, a back-end bug may delete the dependent resources, rather than correctly detect that the user doesn't have permission to update those resources and ignore the changes.

@maxpatiiuk maxpatiiuk added this to Unsorted in Users & Permissions via automation Jan 6, 2023
@grantfitzsimmons grantfitzsimmons added the 2 - Security & Accounts Issues that are related to the permission system and user accounts label Aug 8, 2023
@maxpatiiuk maxpatiiuk mentioned this issue Oct 7, 2023
Open
@melton-jason melton-jason self-assigned this Oct 15, 2023
melton-jason added a commit that referenced this issue May 7, 2024
@melton-jason
Assign read permissions to dependent tables
9a35992 
Fixes #2714
@melton-jason melton-jason linked a pull request May 7, 2024 that will close this issue
Draft
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@melton-jason melton-jason

Labels
1 - Request Improvements or extensions to existing behavior 2 - Security & Accounts Issues that are related to the permission system and user accounts
Projects
Back-End Backlog
Status: 📋 Backlog
Users & Permissions
  
Unsorted
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Give read permissions to dependent tables specify/specify7
3 participants
@grantfitzsimmons @maxpatiiuk @melton-jason