EBMS Tickets

We will flesh out the requirements for this.

Skipping over this ticket until the requirements have been nailed down.

Story points based on the following assumptions:

• Clarifying requirements

• Approaches:
  1) letting it still appear on the list but has an indicator flag
  2) actually not show on the list and way to find the hidden content.

Since this is marked as critical, I'm gathering information and making notes to myself so that I'll understand how the machinery works and what some of the options are.

I won't do any design or programming until we have, as Bob put it, "nailed down" the requirements.

I've done a little thinking about this now but the main options I can think of are the two that Erika listed above - with variations on how to implement them.

I also did some tests to see how hard it would be to filter the list of packets by testing whether all of the referenced articles in a packet have been archived, or at least one has not. I could be wrong depending on the specifics of what we need, but it looks quite practical to do both from the point of view of level of effort and from that of speed of filtering.

I'll save my notes and do something else until we can discuss the issue.

Here's my summary of the requirements we decided upon in today's meeting (I starred** two new things which I'd be happy to discuss):

VIEW/EDIT PACKETS PAGE
1. Please change "Delete" to "Archive".
2. **Please change the text in the pop-up box that appears after hitting "delete" (current term) to the following: "Archiving this packet will remove it from the queues of any reviewers who have not responded." with the option to cancel or hit OK to perform the action.
3. Please add filtering options to the top of the page to support the following:
a. search by topic name
b. search by date the packet was created
c. free-text search (with wildcards) to search packet name
d. checkboxes to display archived packets (default is just to show active packets) and legacy packets (default is to exclude legacy packets from search results)

REVIEWED PACKETS PAGE
1. Please add an option to archive a packet at the top of the page for an individual packet. Please have the button state "Archive Packet" and be on the same line as the packet name so that it is clear that this is different from archiving an article.

2. **Would it be possible to provide a pop-up box here with the same wording as suggested above for the view/edit packets page?

3. Please un-archive any article that was previously archived upon receipt of a new response.

Thank you!

Here are some questions about item 3 of the comment above on filtering
options for the VIEW / EDIT PACKETS page:


                             Filter Fields
                             -------------

We have some choices to make when invoking filtering.  Here are the
fields we have specified:

    Topic name:

        Should that be a drop down list of topics for the particular
        board, or an input field in which we enter text?

    Date packet created:

        Specifying a single day is probably not helpful.  Alternatives
        might be:

            Specify a month + year - perhaps defaulting to the current
            month and year.

            Specify a review cycle from a drop down list.  Use the start
            and end date of the cycle as limits for the packet creation
            date.

            Specify a date range:

                Starting year, month, day
                Ending year, month, day

        The last one (start + end dates) seems to me the most flexible.
        Blank fields would mean there are no date limits.  If one field
        is blank then there is no limit on that one field.

    Free text search with wild cards:

        Have a single input text field.  Use wild cards to get
        individual words in the order specified, e.g.:

            "psychosocial aspects"
                Gets no hits because no wild card at end.

            "psychosocial aspects%"
                Gets hits.

            "genetics%psychosocial"
                No hits, order is wrong.

            "psychosocial%genetics%"
                Gets hits

        Alternatively we could have several input fields and assume wild
        cards around each one, e.g.:

            Free text _____________
            Free text _____________
            Free text _____________

    Status checkboxes:

        The most flexible approach is to have three independent
        checkboxes:

            [x] Active packets

            [ ] Non-legacy archived packets

            [ ] Legacy archived packets

        The first would be checked by default but could be unchecked.
        Any combination of 1 to 3 would be fine.


                           Invoking Filtering
                           ------------------

The form for filtering packets will have 3-6 input fields (as above)
plus a group of three checkboxes.

Here is one way to present it:

    Build the VIEW / EDIT PACKET form exactly as now, populating it with
    packets using the same criteria we have now, but add a single link
    or button to the form that has a value like "Filter", or "Filter
    Packets".

    If the user clicks the link or button, we bring up a form for
    entering filter criteria, the form replaces what was on the screen

    The user enters the desired criteria and clicks "Submit".

    We rebuild the original page using the new selection criteria.

    If the user clicks the "Filter" link again, we bring up the form
    again.  The user can keep changing the filter criteria as often as
    desired.  Each time we bring up the filter form it will have the
    default values, not the values from the last time (or the other way
    if that's a better way to do it.)

    We might need a representation of what the criteria were if the
    filter form is separate, or maybe not.

An advantage of this approach is that the form can be as complex as we
like without complicating the main VIEW / EDIT page, or adding things to
it that may just appear to be noise if they aren't used very often.

Another approach is:

    Make the filter form a fixed part of the VIEW / EDIT page, probably
    above the list of packets.
    
    If the user clicks a "Filter" button, we execute the search and
    repaint the page with the new list of packets.

Possible advantages are that the form is always present, and always
shows what filter criteria produced the packet list below.


More ideas and questions may be coming.

For the topic name, assuming we use a drop down list (which I'm assuming for the moment), we need to decide whether a user should be able to select multiple topics from the list or be limited to one at a time.

Sorry for the delay in responding to you. I've given some thought to each of your questions and here are my answers:

FILTERS

1. Topic Name.
I agree that we should use a drop-down list for the topics. It would be preferable to be able to select more than one topic at a time, but we could live with selecting one at a time if this is significantly more work.

2. Date Packet Created.
I think the date should be entered using a range for the greatest flexibility. Is it possible to use pop-up calendar boxes here?

3. Free-text Search.
I think we should have a single input field and use % signs as wildcards. This is consistent with the search form, I believe, and it will take up less real estate than multiple input fields.

4. Status Check Boxes.
Three separate check boxes is fine with me.

INVOKING FILTERING

I think we should make the filter criteria a fixed part of the view/edit packets page for the reasons you mention above. I think we'll use this filtering capability a lot (like we do on our queue page).

Thank you!

Upping the story points from 8 to 40. This story requires much more effort than initially anticipated. Development will continue into Iteration 2.

Since this issue involves several changes to the view/edit packets page, I thought I would post another task related to that page here. Let me know if it should go into a separate issue.

We would like to add a link to view pages or view all packets to the TOP of the list of packets on the view/edit packets page. (It currently only exists at the bottom of the page. Other pages have this in both places.)

For the topic select list I originally thought I'd figure out what
topics pertain to existing packets and only include those in the list of
packets to select from. However that doesn't work if a user can check
the boxes that say to include inactive and/or legacy packets because
every topic will have packets somewhere in the database.

So I plan to allow selections from all topics from the user's board(s).

I'm planning to make a Real Simple topic selection field in the form.
Later, we can make a complex expandable/collapsible dropdown with
checkboxes if everything more important is working.

I have installed the changes on Dev and in svn. I think everything works as desired.

I won't install on QA unless and until we decide this should go there.

Install instructions: Install review.inc and review.css from subversion.

Bob warned me, but did I listen?

I tested the changes on a Linux system that had Firefox and Chrome but not Internet Explorer. The displays look identical on Firefox and Chrome but IE 10 renders the date fields differently. The Firefox/Chrome look is more attractive I think.

I'm going to continue working on another task for now and worry about this one after users have looked at it. I don't know if it will be hard to fix or not, and I only have IE 10 on my system so I'll have to figure out how to test with the versions in use by users (maybe IE 9 predominates.)

I fixed the discrepancies between IE and the other browsers.

• R12231 ebms.nci.nih.gov/modules/custom/ebms/review.inc

• R12231 ebms.nci.nih.gov/themes/ebmstheme/css/review.css

Promoted to QA.

Bob and I just reviewed a few literature packets together on QA and we noticed that checking the "archived" box on the Board manager's reviewed packet page is causing the article to be removed from the packets of Board members who have yet to complete their review of that article. Bob is going to change this such that the archived box is treated as a flag for that page only; when checked, Board members will still see the article on their assigned packet page as long as the article has not been dropped from the packet. A new review for an article that had been archived by the Board manager on the reviewed packet page will become un-archived such that the Board manager can see the review.

Would I be right in assuming that you'd want a packet to drop off your REVIEWED PACKETS page if all the articles which have been reviewed are marked as "archived"? That's not what's happening now, and unless you can think of a reason I shouldn't, I'm going to fix that.

No, I don't think that should happen. We wouldn't want to archive the packet (which would remove the articles from Board member's queues) when we archive the last article unless we were sure we were done with the whole packet. A separate requirement (discussed above) should give us the ability to see new reviews that come in after we've archived an article. There should also be a button to archive the packet on the reviewed packets page on the same line as the packet name. I've copied a portion of a comment from Oct 29 that speaks to both of these points below.

---------

REVIEWED PACKETS PAGE
1. Please add an option to archive a packet at the top of the page for an individual packet. Please have the button state "Archive Packet" and be on the same line as the packet name so that it is clear that this is different from archiving an article.

2. **Would it be possible to provide a pop-up box here with the same wording as suggested above for the view/edit packets page?

3. Please un-archive any article that was previously archived upon receipt of a new response.

Never mind, I thought of a reason not to change that behavior myself. Since you can toggle between showing and hiding "archived" articles, you need to be able to get to the packet in order to use the toggle.

I have fixed the other problem, reported in yesterday's comment for this ticket. Ready for review on DEV.

We wouldn't want to archive the packet (which would remove the articles from Board member's queues) when we archive the last article....

It wouldn't have any effect on the board members' queues, but we still don't want to block your own access to the toggle which lets you see "archived" reviews.

Ok, I've verified that archiving an article on the Board manager's reviewed packet page no longer removes that article from the Board member's assigned packets page. I've also verified that, once an article is archived, a new review will bring it back to the reviewed packets page.

However, I think the following changes still need to be made:

REVIEWED PACKETS PAGE
1. Please add an option to archive a packet at the top of the page for an individual packet. Please have the button state "Archive Packet" and be on the same line as the packet name so that it is clear that this is different from archiving an article.
2. **Would it be possible to provide a pop-up box here with the same wording as suggested above for the view/edit packets page?

As discussed, there seems to be a bug in the "legacy" button on the view/edit packets page since, when checked, I am seeing both legacy + archived (inactive) packets.

We would like to keep these three checkboxes and have the ability to select any of them or use them in any combination.

Additionally, please make the following wording changes on this page:

Please change "Inactive" to "Archived".
Please change "PKT TITLE" to "PACKET NAME" for consistency with other occurrences in the system.

Lastly, please add hover text to the START DATE and END DATE fields as follows:

"Packet creation date (defaults to no start date)"
"Packet creation date (defaults to no end date)"

I think I've completed all the work on the requests from the previous two comments (DEV and QA). Please test.

We're still testing this, but I noticed something related to this issue that I think we should put into the next release. When you click on the View-->Reviewed option at the top of the list of Packets on the View/Edit Packets page, it brings you to ALL reviewed packets, rather than only those reviewed packets that were in the set of filtered content already on the page.

Another possibility (to add to the previous comment) is to add another checkbox to the filter to see reviewed packets only. I'll come back and collect these comments for a new issue in our next release.

Verified on QA.

Verified on production.