Skip to content
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

User reported colo #47

Open
alexfelmeister opened this issue Nov 12, 2018 · 5 comments
Open

User reported colo #47

alexfelmeister opened this issue Nov 12, 2018 · 5 comments
Assignees

Comments

@alexfelmeister
Copy link
Collaborator

Hi Alex, Alex, and Stephanie,

One of the coordinators from our site in Seattle noticed that the buttons in the BRP weren’t changing even though he selected unverified or complete. We checked our CBTTC project and the buttons seem to be working in our database. Could one of you please look into this?

Thanks so much for your help!

Carina

@stxphcodes
Copy link
Contributor

@alexfelmeister @seg1129 @alexanderkgonzalez This might be an issue with the user's cache (perhaps ask the user if he changed the completion status for one of the forms recently through Redcap instead of the BRP?) In biorepo-portal/api/management/commands, there's a file called cache_redcap_records_table. This file was written to delete the redcap table color cache for ALL users in ALL protocols (I'm not sure that I had written the command to take arguments). The command will remove the cache key and associated value from redis ( cache_key = 'protocoldatasource{0}'.format(pds.id) + '_redcap_completion_codes' ) and will call the redcap_form_complete_caching method to generate new cache for that protocol.

However, if you don't want to recache the redcap table colors for ALL protocols and users (which I might recommend that you do not!), perhaps you could find the protocoldatasource id that the Seattle coordinator is working on, and from that delete only his cache key from redis, which again, cache key is 'protocoldatasource#_redcap_completion_codes'. Upon first open of their BRP redcap record table, they'll see that it is completely blue, but after the first open, I think the redcap_form_complete_caching method will be called and the next time they open a record, the table should be filled with colors.

Please let me know if you have any questions/need further assistance!!

@seg1129
Copy link
Collaborator

seg1129 commented Nov 15, 2018

@alexfelmeister, Carina sent me a message yesterday saying that this issue is resolved.

But I think you bring up a good point. We should consider adding re-caching of the redcap form status to the nightly job to update all of the cache in the BRP, or a separate job to perform this function. a requirement for this feature was to create a command-line job to do just this, which @szh2425 completed, I'll take a look at creating a Jenkins job to run every night.

@alexfelmeister
Copy link
Collaborator Author

👍

@alexfelmeister
Copy link
Collaborator Author

alexfelmeister commented Dec 5, 2018

@seg1129 We had another report from Seattle that after I did a change to their configuration. It seems that the colors stopped working on subjects he entered between when the colors first went live to a time I changed the config :-| @szh2425

@stxphcodes
Copy link
Contributor

stxphcodes commented Dec 5, 2018

Hey @alexfelmeister ! When you changed the configuration, did you also update the Driver Config Options under Protocol data sources in the BRP? If there was an addition or removal of a form/event, this would affect form_order, which would affect the colors in the table. If this is the case, it would be an easy fix. Form_order is Form#_Event# . Whatever it is that was added/deleted from the protocol, you can update the list to reflect those changes. If this is urgent, you can let me know how the config was changed for that protocol and I can let you know what the new driver config should be!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants