We updated Atlas/WebAPI to 2.15/2.15.1 from 2.14.x. Now the Atlas users role has read only access to their own conceptset, as displayed in the UI, in contrast to the admin role which has full access. So if a user creates a conceptset and adds concepts, then tries to save the set, a pop-up error appears on screen which says “An error occurred while attempting to save a concept set”, but the log shows no corresponding Java errors.
Doing a scan of differences in permissions, this INSERT statement would give the following missing permissions to Atlas users (10) that the admin user has. However, it’s not clear if this is a proper approach to solving the problem, or if the permissions below are too broad for Atlas users.
INSERT INTO ohdsi.sec_role_permission (role_id, permission_id)
SELECT 10, id
FROM ohdsi.sec_permission
WHERE value IN (
'conceptset:*:protectedtag:post',
'conceptset:*:protectedtag:*:delete',
'conceptset:*:annotation:*:delete'
)
The reason why you might not see the error in the log is that the request is pre-filtered by URL prior to reaching the save part of the code. But it’s likely (since admins can do it but regular users (role 10) that a permission has been deleted. There were bugs that led to permission corruption that I think we addressed in 2.15, however you could be seeing soemthing new.
I will pull my local permission lists for conceptset: permissions tha are attached to role 10, and you can do a compare on your local side to see if something is missing.
Ok, i queries for concept set permissions, and am including some SQL you can run on your own WebAPI instance to understand what the perms are:
-- find the atlas-user-role permissions for concept sets:
select p.* from webapi.sec_permission p
join webapi.sec_role_permission srp on p.id = srp.permission_id
and srp.role_id = 10
where value like 'conceptset:%';
-- who am I?
select * from webapi.sec_user
-- find my own permissions related to concept sets:
select distinct p.* from webapi.sec_permission p
join webapi.sec_role_permission srp on p.id = srp.permission_id
join webapi.sec_user_role sur on sur.role_id = srp.role_id
where value like 'conceptset:%'
and sur.user_id = 1000 -- 1000 is my local user ID
order by p.id; -- ones < 1000 will be default permissions from WebAPI versions, > 1000 will be new ones for new assets
The first one will just show you what concept set perms exist on the general user role.
the second query will help you find out your own user_id from your login name. You’ll need that for the third query.
The third query will show you all permissions related to concept sets, and it comes from the atlas-user-role + any user-specific permissions. user specific perms come from creating concept sets, and you’ll see exampels like conceptset:39:get which means ‘you can fetch the concpet set with id 39’.
The attached documents are CSVs, but were renamed to txt for upload purposes.
When you try to save the concept set in your local environment and you get the ‘failed to save’ message, you should see an error in your browser console (ctrl-shift-i to open it, but you may need to open it before you request the save so you can see the failed request). You should see something like one of the reqeusts like /conceptset/{your conceptset ID} resulting in a red number like 403 or 500, and that will tell you which URL is being requested and which one you don’t have permissions to.
Please let me know if your environment seems to be missing certain permissions, and I can help you restore them.
