EBMS Tickets

I think I have fixed this problem. In the first screen shot you can see Koutsilieri S: Optimizing thiopurine dosing based on TPMT and NUDT15 genotypes: It takes two to tango. with checkboxes for Adult Leukemia and for Genetics of Hematologic Cancers. In the second screen shot I have checked the Approve box for the Adult Leukemia topic. The third screen shot shows the article still in the queue after clicking the Submit button, with the boxes removed for Adult Leukemia but still available for the second topic. Please test at least one more article.

this seems to be working sporadically. It worked for some citations and not for others. See attached examples of two citations - one that worked and one that did not.medlibque_issue_not_resolved.docx

Strange.

Have you seen any of my messages about clearing the JavaScript cache?

667597, 668660, 668701, 670415, 670419 didn't work aka left queue with unreviewed sumtops

670022 worked aka stayed in queue with unreviewed sumtops

This is strange. It is not working more than it is working and I am not sure why. I do not see any meaningful difference between the citations.

Yes, this testing is after clearing the cache. Just cleared it again and am still seeing it not work more than work.

Here is one more example of it working: 668714

My latest screen shot showed that your "failed" example didn't remove it from the queue, by which I mean when I brought up the queue the article was still in it, with the checkboxes still available for the topic you hadn't yet reviewed. So the problem seems to be that although the queue itself is as it should be (in the sense that the unreviewed topic really is still unreviewed, and shows up in subsequent displays of the queue), the display of the queue as presented to you immediately after your submission of the decisions for the other topics is flawed, as it doesn't include the article. I went back and looked at all of the sorting options to see if any of them alter the order of the articles based on dates associated with the unreviewed topics (or something similarly arcane) but as far as I can tell all of the sorting options are completely independent of topic-specific values, and the only thing which could possibly cause an article to change its position in the queue would be if somehow the XML for the article were refreshed between the time you first brought up the queue and when you submitted your decisions, causing the values used for sorting the articles (title, author, journal, whatever) to have changed. I think we can rule that out as such an extremely unlikely scenario that it's not what what's going on here.

So I think the next step would be to see if we get the same behavior on QA, where we have not applied any of the updates we're testing on DEV. Can you do that?

I just found 1 citation(772140) in QA that left the queue prematurely. But the majority are working correctly so I am thinking this was an issue before that we never noticed and my not have tested for because Minaxi and I always review all the topics at once. And even if we did test for it we may not have even noticed because in QA the majority work fine with just one so far that didn't. The reason I thought to test this in DEV today was because Jeff is reviewing only a limited number of topics and does leave topics unchecked so it was on my mind to test. However, I think this patch has made this issue worse because in DEV I am seeing it happen with most citations.

Just found one more that left the queue prematurely 723407. 

As an estimate of frequency - In QA, I have to go through about 8-10 that work fine before I find one that prematurely leaves the queue. And it is the reverse in DEV.

You're seeing the article suppressed from the queue display when the page is drawn in response to your submission of decisions for some of the article's topics. What we need to determine next is whether the article appears in the queue when you bring up the page directly from the menu (as it does for me). If so, we will have confirmed that we're not facing the problem we originally feared, namely that we'll have articles which never have a chance to be fully reviewed. Can you check to see if the articles which disappeared (we hope temporarily) reappear when you load the queue afresh?

I see 723407 in the queue on QA.

When I logged into QA for the first time today I was able to see 723407 and 772140 in the queue. 

I filtered the queue to pull out 24 peds late effects citations. One left the queue prematurely leaving 23. I have reset the queue, reopened it after doing a search or report, I even logged out and logged back in and I still only get 23 in the queue for peds late effects.

I am not sure what you mean by "bring up the page directly from the menu"

What's the ID for the missing 24th article?

OK, yes that's what I have been using to reopen the queue.

770945

Ok I found it in the queue when I called up all the peds citations. The reason this one left the quque was because the summary topic I selected was late effects and that was the filter criteria. so my bad. this is not an example. 

This is tricky to test. Let me take another look and see if I can recreate the issue again in QA.

Ah, if you're filtering your queue you'll want to take careful notes on what the filtering criteria are as you're reporting the observed behavior. Is it possible that you were confused by the fact that if ANY of the unreviewed topics match your filtering criteria, then ALL of the topics are displayed, which might result in your forgetting that the filtering had only caused the article to show up initially because a topic for which you just submitted a decision matched your filtering choices?

Yes I think that was what was happening. The queue in DEV has 1500+ citations so I was trying to filter it to make a more manageable set of citations. So after realizing this and watching for it, I am not seeing citations leave the queue prematurely (DEV and QA) unless they are excluded by the filter's criteria. 

I want to take a step back from this and then come back to it with fresh eyes and test again just to make sure but I am thinking this may not be an issue.

I am unable to recreate this in dev. I do not think this is an issue.

That's excellent news, thanks! 👍