EBMS Tickets

My investigation has uncovered nothing useful, as far as I can tell. Here are the 14 decisions for the 10 articles:

article 960634, topic Genetics of Kidney Cancer: approve
article 960636, topic Genetics of Skin Cancer: reject
article 960636, topic Genetics of Ocular Melanoma: approve
article 960639, topic Genetics of Skin Cancer: reject
article 960639, topic Genetics of Ocular Melanoma: reject
article 960641, topic Genetics of Skin Cancer: reject
article 960641, topic Genetics of Ocular Melanoma: reject
article 960645, topic Genetics of Pancreatic Cancer: approve
article 960646, topic Genetics of Pancreatic Cancer: approve
article 960648, topic Genetics of Pancreatic Cancer: reject
article 960649, topic Genetics of Pancreatic Cancer: reject
article 960650, topic Genetics of Pancreatic Cancer: reject
article 960650, topic Pancreatic Cancer: reject
article 960651, topic Genetics of Pancreatic Cancer: reject

Since all of the decisions were recorded successfully when submitted in smaller batches my initial hypothesis (that there might have been something about one or more of the individual decisions which was broken, preventing the recording of the batch) appears to have been rejected. Also, I saw that the logs were flooded a little bit later by hacking attempts (which I assume were conducted by NIH itself to verify whether the EBMS is secure against attack), but those attacks didn't start until well after all 14 decisions had been successfully recorded, so we have to rule out any relationship between those (simulated) attacks and this ticket.

Good news. I have figured out how to recreate this issue on both prod and qa using Edge and Chrome. I just showed William and he suggested we demo it to you as it is not something that we can screenshot. Let us know when you would have 15 minutes to take a look.

That is indeed excellent news! I'm available now.

great, ill set up a teams meeting

As reported in last week's status meeting, I have been unable to find a documented way to control the location of the "please wait" message which appears while a review decision is being recorded. I reached out on the Drupal Slack support site but no one else is aware of any supported way to do what we need to do here.

So I dug in and reverse-engineered a way to ensure that the message is always visible and prominent. Because it's not documented, the approach is somewhat fragile, and could break at some point in the future. However, in my judgment that risk is lower than the risk of the user not noticing that her review decisions didn't get recorded, and it would be pretty likely that if this workaround failed somewhere down the line we'd notice pretty quickly and come up with a way to adjust this technique.

I tested on a private instance of the EBMS, and I think it will do what we want. I then tried to install it on EBMS DEV, but that tier is down right now (another CBIIT ticket to file). So I have installed the workaround on https://ebms.rksystems.com so you can try it out and judge for yourselves. I have temporarily added a five-second sleep which kicks in every time you click on a decision radio button on the review queue page. Without that delay, it's unlikely you would see any difference, as my own server is faster than the CBIIT servers. You can scroll the page up and down while you're waiting, to confirm that the message continues to be prominently visible, regardless of where you are on the page. We obviously won't retain that delay when we deploy.

Let me know what you think.

The message is definitely more visible and remains in the center of screen regardless of what else I do such as scroll or record/change other decisions.

I can record additional decisions while the message is displayed and it just seems to add to the total display time. So if a user reviews a set of citations quickly the message could be displayed the entire time during the review process. But this could be a timing issue with the five-second sleep you added and could be slightly different on other tiers.

Moving away from queue to add topic/tag or see full history does not result in loss of decisions. So I think this looks good so far.

The fact that you can ignore the instructions to wait and still have subsequent decisions recorded is only due to the fact that I put the sleep() call after the code to store the decision you just made in the database. I should probably have put the delay before the code puts your decision in the temporary list. That would have on reflection have been more representative of what's happening on a slow CBIIT server.

The bottom line: this solution will only work on the production system if users actually wait when they're instructed to do so. 😉

Made "please wait" message visible from anywhere on the page.

https://github.com/NCIOCPL/ebms/commit/c1cc67d

Installed on QA. Will hold off on putting in the ticket for CBIIT to apply the release to EBMS STAGE until I hear back that this has been tested. Basically, that testing involves determining that it is not possible to reproduce the behavior on QA which Cynthia reported for this ticket, provided that the reviewer waits when instructed to do so.

Yes, users need to wait. I was just trying out all possibilities to make sure the fix would not generate any errors.

This fix has made the "please wait" message highly visible to users and if the users do wait for the message to disappear decisions will be recorded and retained if users move to other pages like Add Topic/Tag or full article history view. I have tried a variety of different scenarios and have had no issues.

I think this is good to go.

Verified on PROD. Thanks!