Feature/global sharing

[rkboyce]

This pull request adds OPTIONAL functionality to Atlas/WebAPI where folks have chosen to implement optional enhancement that allows read permission to be restricted so that only users with read access to a given artifact can view them (see description in the Atlas set up guide and more details on the WebAPI wiki.

The feature makes it possible for users of an Atlas instance that is restricting read access to share an artifact they own publicly. Example:

1. User 1 creates a concept or cohort definition and wants to make it public so that it is visible in the list of artifacts returned when another user goes to the respective listing
2. User 1 clicks on the lock icon which pops up a modal to configure permissions. The user scrolls to the bottom and selects the button and selects "Granted" under where it says "Status of global READ access"
3. The effect of this is to add permission mappings in the sec_role_permission table so that the public role has read access to the artifact.

This operation can be reversed:

1. User 1 decides to remove the artifact from public shared status. The user clicks on the lock icon which pops up a modal to configure permissions. The user scrolls to the bottom and selects the button and selects "Not Granted" under where it says "Status of global READ access"
2. The effect of this is to remove permission mappings in the sec_role_permission table so that the public role no longer has read access to the artifact.

One additional feature is that artifact sharing can be restricted to only certain users. This pull request adds the enablePermissionManagement config option to config-local.js. If is set to true then, only users a specific permission ('artifact:global:share:put'), are able to share. This is useful for data commons or other collaboratives where there are many users and a small group of admins or moderators would like to filter the items shared publicly.

If this pull request is accepted, the documentation above should be copied into the the Atlas set up guide](https://github.com/OHDSI/Atlas/wiki/Atlas-Setup-Guide) and referenced from the WebAPI wiki](https://github.com/OHDSI/WebAPI/wiki/Read-restricted-Configuration).

[chrisknoll]

Hi, I planned on working on merging this in but I'm now confused as to if there is an outstanding issue that needs to be resolved from https://github.com/OHDSI/WebAPI/pull/2342? The atlas side looks like it adds the 'global read access' option to the security (lock) screen, and that would just put this artifact permission into role 15 (where all users have the read access permissions for global assets stored).

So can anyone please clarify what this PR depends on in order to be merged? My understanding is:

Role 15 (read access role) is already set up on WebAPI, and this PR just puts assets into it from the UI. Is there anything more needed from that perspective?

[chrisknoll]

Ok, not sure if this is working as intended:

I created a new one and want to grant perms as global read:

I click the granted button (note: this UI is not clear what the status is if it is granted or not granted, I would make the selected option green and the non selected red or something to distinguish it better.

The 'public' role was added but I was expecting role id 15 (read restricted atlas users) to be the permission granted to this asset.

[pieterlukasse]

@chrisknoll thanks for testing it. The "public" role behavior is correct and matches the description Rich shared above:

The feature makes it possible for users of an Atlas instance that is restricting read access to share an artifact they own publicly.

Regarding role 15: I think Role 15 is meant for restricted access features in general (i.e. it is perhaps best seen as an alternative to role 10 which gives access to all artifacts by default), and therefore the name "read restricted" might be a bit confusing, as it makes it sound like it is a role that would be given to someone that needs read only access. This could be part of the confusion. Anyway, to address your concerns: this current PR only makes sense in the context of the restricted access feature, and it probably only makes sense to merge this if the restricted access feature is fully working first. So yes, solving https://github.com/OHDSI/WebAPI/pull/2342 first makes sense to me.

[chrisknoll]

Ok, cool thank you. So the main ask is that if the global access button should be a little more clear about if it is globally shared or not.

[chrisknoll]

Per some review on the 2/11 call, it seems that the EntityPermissionSchema code changes in the PR were bugfixes that shoudl be included, but I don't think we need a migrations script to populate Role 15 (the read restricted role) because people add/remove that permission through the UI and there are no defaults.

@pieterlukasse , can you confirm this, and if this makes sense let's clean up that PR to just make the PermissionSchema class changes.

[pieterlukasse]

@chrisknoll yes, we can cleanup the webapi PR and this PR to strictly just what is needed for this feature and push the other items to separate tickets for example. Having said that, adding a "global sharing" feature without solving the security/access issues in webapi (i.e. artifacts being accessible while they shouldn't in "read restricted" mode) might be a bit misleading/confusing.

Maybe we can discuss a path forward in one of the next meetings?

[chrisknoll]

Definitely. While we're trying to close out PRs for 2.15 for this friday, if the work is mostly complete on this feature then we can fold it in.

[chrisknoll]

I was going to add some commits to clean up the button behavior, but it's on a fork which I don't have perms on, and I don't want to fork-a-fork.

So, would it be possible for someone to make the follwing update which should be quick and dirty:

For the buttons 'granted' and 'not granted', can we alter the rendering to just show one or the other. If it's granted, show the granted button. if it is not granted, show the not granted button. Clicking on the button 'toggles' the state of the read only grant (ie: clicking 'granted' will set it to not-granted, clicking 'not granted' will set it to 'granted').

In addition, looks like there are conflicts based on recent commits to mater, can you sync your upstream and resolve conflicts?

@pieterlukasse

[rkboyce]

@chrisknoll - No urgency. In fact, please ignore this for a bit. I came across this pull request from ages ago while working on some other feature and thought to try and finish it by addressing the issues that were raised. All I did was try to resolve the 1 conflict that was raised by github. I think there are other issues including some security concerns and will post again here when I have had a chance to test this and catch up with the issues raised.