dataall
dataall copied to clipboard
Read permissions in data.all for share Requesters - define lifecycle of permissions
Is your idea related to a problem? Please describe.
At the moment when a share request for tables or folders is approved, the requester group gets data.all application permissions to GET_TABLE
, PREVIEW_TABLE
AND GET_FOLDER
respectively. These permissions allow the requester group to get the tables and folder details in the data.all UI.
The challenge is that there are cases in which those permissions are not deleted. We need to decide what is the complete lifecycle of permissions in relation to the share object/item lifecycle.
This issue is related to https://github.com/data-dot-all/dataall/pull/1163
Describe the solution you'd like A bulletproof implementation in which no additional or orphan permissions are granted to any group.
P.S. Don't attach files. Please, prefer add code snippets directly in the message body.
Missing items added: #1237
DATASET_TABLE_READ = [GET_DATASET_TABLE, PREVIEW_DATASET_TABLE]
Checks
- [x] check
DATASET_TABLE_READ
against the table when we execute theget_table
service function - [x] check
PREVIEW_DATASET_TABLE
against the table when we execute thepreview
service function
Give permissions
- [x] attach
DATASET_TABLE_READ
permission to the dataset owner and stewards when the table is created - [x] attach
DATASET_TABLE_READ
permission to the new stewards when the table is transferred to new stewards - [x] attach
DATASET_TABLE_READ
permissions to the share requester group when the table is shared
Remove permissions
- [x] remove all existing resource policies for the table permissions when the table is deleted
- [x] remove
DATASET_TABLE_READ
permissions to old stewards when the table is transferred to new stewards - [x] remove
DATASET_TABLE_READ
permissions to the share requester group when the table is revoked
Database chages
- [x] Migration script that creates the new permission type and creates records backfilling the existing datasets and shares corresponding permissions.
@SofiaSazonova can we close this issue ?
Yes, we can. @anmolsgandhi
Implemented by #1237