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
For Atlas/WebAPI deployments using the 'read restricted configuration' (see description in the Atlas set up guide and more details on the WebAPI wiki, users with the 'Read restricted Atlas users' role should be able to use the Atlas Search feature and other functionality that requires access to a given source
Actual behavior
With the 2.14 release, the default source access was dependent on a specific string ('basic_cdm'). However, organizations can name their sources anything. So, most deployments would find that their users could not access the Search feature out of the box.
Steps to reproduce behavior
Deploy 2.14 fresh following the instructions in the wiki referenced above but have the source(s) named differently.
Discussion / actions needed
An attempt to fix this issue was implemented and pull request created (#2342). However, the pull request actually tried to address two issues: 1) adding read permissions for the 'atlas read restricted' role to existing sources, and 2) addressing some missing permissions in the WebAPI permissions templates needed for read permissions to work properly. Moreover, the consensus is that having a flyway script to add source READ permissions is not a good idea b.c it will give a false sense of security to users that the user will have read access any new sources added after the WebAPI update. At today's call (09/17), the idea was proposed to move any management of source 'read' access to the options provided in the Admin section of Atlas.
This issue is meant to:
call out the parts of pull request that should be retained (after testing) because they add desired permissions to the permission template. Based on the pull request, the following seem relevant and need to be test:
src/main/java/org/ohdsi/webapi/security/model/CohortDefinitionPermissionSchema.java: ("cohortdefinition:%s:version:get", "Get list of cohort versions"), ("cohortdefinition:%s:version:*:get", "Get cohort version"), ("cohortdefinition:%s:copy:get", "Copy the specified cohort definition")
src/main/java/org/ohdsi/webapi/security/model/ConceptSetPermissionSchema.java: ("conceptset:%s:expression::get", "expression::get permission, specific to this conceptset with id %s"), ("conceptset:%s:version:get", "version:get permission, specific to this conceptset with id %s"), ("conceptset:%s:copy-name:get", "copy-name:get permission, specific to this conceptset with id %s")
discuss the requirements to move any management of source 'read' access to the options provided in the Admin section.
The text was updated successfully, but these errors were encountered:
Expected behavior
For Atlas/WebAPI deployments using the 'read restricted configuration' (see description in the Atlas set up guide and more details on the WebAPI wiki, users with the 'Read restricted Atlas users' role should be able to use the Atlas Search feature and other functionality that requires access to a given source
Actual behavior
With the 2.14 release, the default source access was dependent on a specific string ('basic_cdm'). However, organizations can name their sources anything. So, most deployments would find that their users could not access the Search feature out of the box.
Steps to reproduce behavior
Deploy 2.14 fresh following the instructions in the wiki referenced above but have the source(s) named differently.
Discussion / actions needed
An attempt to fix this issue was implemented and pull request created (#2342). However, the pull request actually tried to address two issues: 1) adding read permissions for the 'atlas read restricted' role to existing sources, and 2) addressing some missing permissions in the WebAPI permissions templates needed for read permissions to work properly. Moreover, the consensus is that having a flyway script to add source READ permissions is not a good idea b.c it will give a false sense of security to users that the user will have read access any new sources added after the WebAPI update. At today's call (09/17), the idea was proposed to move any management of source 'read' access to the options provided in the Admin section of Atlas.
This issue is meant to:
The text was updated successfully, but these errors were encountered: