After upgrading the 3.4, Tomcat insisted on creating the directory /usr/share/tomcat7/openclinica.config for whatever reason. I don't think this is a good path to store webapp-specific runtime files. Is it configurable to some other location?
I am testing your code for getting an item value from a different event/crf. It works when I am logged in as a Study-level user (i.e., any role that has access to the whole study), but when accessing the eCRF using a Site-level Coordinator role, I get the following error (in the console):
I am wondering if you or anyone else ran into this problem and if there is a resolution to this?
EDIT: One workaround that works currently in 3.10.1 is to give the site user who already has a coordinator role an additional data entry role for the whole study, but then to remove that study-level assignment right away (keeping only the site-level coordinator role). After that, the site user is able to successfully use the REST call.
Great to have both the token for the StudySubjectOID and the option to use the StudySubjectID in REST. Now we can access data from CRFs in other Events, with the code below. A more detailed example can be found at
Comments
Thanks very much for looking in to query speed. The results sound
promising, and might be the final reason for us to move off 3.1.4.1
I suppose what would be ideal is if there was some way to hook the REST
query to the CRF response so the data gets pulled with everything else.
Best regards,
Lindsay
Is it configurable to some other location?
I am testing your code for getting an item value from a different event/crf. It works when I am logged in as a Study-level user (i.e., any role that has access to the whole study), but when accessing the eCRF using a Site-level Coordinator role, I get the following error (in the console):
GET https://example.com/OpenClinica/rest/clinicaldata/xml/view/S_TESTSTUDY/SS_TEST0002/SE_SCREENING/* 403 (Forbidden)
I am wondering if you or anyone else ran into this problem and if there is a resolution to this?
EDIT: One workaround that works currently in 3.10.1 is to give the site user who already has a coordinator role an additional data entry role for the whole study, but then to remove that study-level assignment right away (keeping only the site-level coordinator role). After that, the site user is able to successfully use the REST call.
Thank you,
Stan
Correct, on site-level this is a problem. And thank you for sharing the work-around!
Kind regards,
Gerben Rienk