Another cause + solution for “Error when saving a concept set”
Sharing our experience from the CPRD (Clinical Practice Research Datalink https://www.cprd.com/) environment in case it helps others, especially if you run ATLAS/WebAPI behind modern cloud infrastructure.
We found a completely different root cause for the same ATLAS popup message that was not related to roles/permissions discussed earlier in the thread. This suggests there are multiple possible causes for this same ATLAS error message.
About CPRD ATLAS environment:
Database: OMOP CDM Database containing data for 50M+ patients.
Deployment: ATLAS and WebAPI are running as Container Apps
What we observed:
We started getting the same ATLAS popup:
“An error occurred while attempting to save a concept set.”
- Adding/removing a concept inside a concept set failed
- Creating a new concept set (the header) worked
- Saving or deleting items inside the concept set failed
- No helpful information in ATLAS logs
- No errors at all in WebAPI logs
Useful hint showed up in the browser console (Open Developer tools → Console in Chrome)
Access to fetch at from has been blocked by CORS policy:
Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.
PUT net::ERR_FAILED
In short, the browser was blocking the request before it ever reached WebAPI.
This explains the symptoms of no server logs and anything using PUT/DELETE HTTP Methods affected.
Since this worked fine last year, our conclusion is that Container Apps has become stricter and now requires CORS to be set explicitly.
Fix (CPRD Container Apps)
We updated the CORS settings on the WebAPI container app. After adding the needed HTTP methods, everything started working immediately. No code changes to ATLAS or WebAPI was needed, just a configuration change on the hosting side.
Allowed Methods: GET, POST, PUT, DELETE, OPTIONS
(or set Allowed Methods = * if you want to allow all methods)
Fix for VM installs (E.g. Tomcat)
If you are running WebAPI on a VM instead of container apps, the relevant settings are in
application.properties:
security.cors.enabled=true
class that controls CorsFilter:
WEB-INF/classes/org/ohdsi/webapi/shiro/filters/CorsFilter.class
Summary:
In CPRD, this turned out to be a browser side CORS block, not a roles/permissions issue.
- Explicitly allowing PUT (and other methods) fixed the issue.
- On Container Apps, update the CORS settings on the WebAPI container.
- On VM deployments, make sure security.cors.enabled is on and CorsFilter set correctly.
- After updating CORS, all concept set actions worked normally again