You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases R/DataSHIELD users would like to share their saved R workspace. Currently it is not possible because a R/DS workspace is accessible only by its creator, so that data are not leaked between users. An improvement could be that given Opal knows the origin of the data that were assigned in the R session, Opal also knows which are the expected permissions that would apply to the R workspace (the union of all the assign permissions). Then any user satisfying these derived permissions could access to the workspace.
Example:
user1 : DS assign tableA and resourceB and makes some computation with the data to build an aggregated summary.
user1 : saves the DS workspace with name "workspaceAB"
user2 : has access to tableA and resourceB as well and then can initiate a DS session with "workspaceAB" data
user3 : has access to tableA only and then cannot initiate a DS session with "workspaceAB"
user2, user3 : when listing workspaces all the accessible workspaces are listed (not just the ones created like currently)
The text was updated successfully, but these errors were encountered:
@StuartWheater@davraam
Would you be interested in this feature?
Do you think that one would NOT like to have its workspace shared (even if accessible by others)?
I think Opal's support for workspaces is a generally under used feature at the moment.
I was wondering it tracking the dependencies could get difficult, for example, user2 uses "workspaceAB" and "tableC", any saved workspace would be derived from tableA, tableC and resourceB.
If the access was permitted by the group a user was in, could that workspace be associated with that group of users?
Right, the permissions are the union of the assign operations + the permissions associated to the restored workspace.
In practice it is not possible to know whether a permission was granted to the user or was inherited from a group (or both), and it is not necessary to know that, the associated access control list approach is simpler.
In some cases R/DataSHIELD users would like to share their saved R workspace. Currently it is not possible because a R/DS workspace is accessible only by its creator, so that data are not leaked between users. An improvement could be that given Opal knows the origin of the data that were assigned in the R session, Opal also knows which are the expected permissions that would apply to the R workspace (the union of all the assign permissions). Then any user satisfying these derived permissions could access to the workspace.
Example:
The text was updated successfully, but these errors were encountered: