-
Notifications
You must be signed in to change notification settings - Fork 169
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.
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
Filter cohorts and concepts by permission (#2245) #2301
Conversation
* This is the first working filtration of the conceptset lists so that a user only sees what their role has permission to read. This initial commit has a big issue in that a person who authors a conceptset cannot see the concept set unless a new permission is added. To be fixed. * changed the name, data type, and location for the configuration option used to tell the WebAPI to do filtering based on READ permissions. The new property is called security.defaultGlobalReadPermissions * Fixed the default value of defaultGlobalReadPermissions to be true in pom.xm and to be camel case formatted throughout the code
Handle read-only filtering for Pageable. Remove redundant code using conditional filtering. Maintain backwards comparability in PermissionService.
@rkboyce : please pull this branch and test on your local environment. |
All of the following tests passed: Configuration 1:
Test 1: expected behavior - filtering of listed entities based on READ permissions by WebAPI User logs in and can view all of the entities that the user has READ permissions to (concept sets, cohort definitions, characterizations, cohort pathways, incidence rates, estimation, prediction) - Passed Test 2: ability to add READ/WRITE permissions to any entity that the user has WRITE permissions to User creates an entity or opens an existing entity that they have WRITE permissions for and can add READ/WRITE permissions to that entity for another user. The other user will be able to view (if given READ permissions) and edit (if given WRITE permissions) - Passed Test 3: ability to remove READ/WRITE permissions to any entity that the user has WRITE permissions to User opens an existing entity that they have WRITE permissions for and can remove the READ/WRITE permissions to that entity for another user. The other user will not be able to view (if READ permissions are removed) nor edit (if WRITE permissions are removed) that entity - Passed |
return definitions.stream() | ||
.filter(!defaultGlobalReadPermissions ? entity -> permissionService.hasReadAccess(entity) : entity -> true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrisknoll @rkboyce I just came across this change and was wondering why the permissionService
is only checked here. Should it not also be used in getCohortDefinitionRaw
(https://github.com/OHDSI/WebAPI/pull/2301/files#diff-f0d513a6643cd34ac8cee922ef4e560fe9cbc270929d9054520ccc7055fbad10R478-R487) for example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, the purpose of this filter is to remove non-permissioned entities (like cohort definitions) from the calls to get the list of cohort definitions (or concept sets) from the server. The getCohortDefinitionRaw (and other method) fetches a single cohort definition from the service, which would already be 'permission denied' by the security layer...so we don't need to filter in this method as this method will be rejected if you don't have permissions.
Enable WebAPI to do filtering based on READ permissions. The new property is called security.defaultGlobalReadPermissions.