EBMS Tickets

After discussing with the rest of the Board managers, we've decided we would like to add the following parameters:

-FYI articles (to limit the results to articles that have been sent without any assigned reviewers)
-On Agenda, with meeting type and meeting date fields (to limit the results to articles that were given an "on agenda" state)

We do not need to add parameters for the full-text decision on hold or the Board manager action values at this time.

Questions:
In the Advanced Search section of the Search Database page there is a check box for FYI. Is that not what is wanted for limiting to FYI articles? If we need something different, what should the difference be and will it replace or supplement the existing checkbox?

The "FYI CITATION" option is used to filter the results to articles that have been Flagged for FYI. We have used this flag to designate articles that we would like our Board members to see but not be responsible for reviewing but up until now we have handled these outside of the system (sent via e-mail, etc.). Now that we have the ability to send articles without any reviewers (or we will once a bug has been fixed in this release - see OCEEBMS-257), we would like to have the ability to search for articles that have been shared as an FYI with Board members in the system. By this, I mean they were included in a packet for which no reviewers were assigned. I think we should keep the existing FYI option on the search page but perhaps change it to say "Flagged for FYI" and add a new option for "Shared as FYI" or something like that. I'm not really liking the "Shared as FYI" wording, but I will ask the Board managers to weigh in on the wording for these options in our meeting tomorrow.

I think I understand.

I presume we are only interested in active packets, or should we include ones that are inactive and could be years old?

It should include all packets - active & inactive. The search database page is meant to give us pretty broad capabilities.

I've figured out how to get the information for the new FYI filter. For everyone's information, I'm seeing the following numbers of FYI articles in the PROD database:

• 3814 articles are marked at least once as having had an FYI state

• 301 of those have ever been place in a packet. (One was in 16 packets!)

• 14 of those are in packets with currently active status.

I think those numbers are right but if they look suspicious to anyone, please let me know.

I don't think this is quite what we're after. We cannot use the Flagged for FYI state to send FYI articles in the system because we have to pass the article at the full-text state (rather than flag it for FYI) in order for it to be eligible to include in a packet. Therefore, it doesn't make sense to combine information about the FYI state (which is I think is what is meant by the "Flagged for FYI" option) and the inclusion of the article in a packet. The examples you found would have to be true for two different topics. The new filter for articles that have been shared as an FYI should look for articles that were included in a packet for which no reviewers were assigned. Chances are there are very few of these since a bug was identified soon after this capability was added and we have not used it since.

Robin and I had a long discussion of this issue. Here is my understanding of
our decisions:

FYI

The FYI search issue is related to other issues regarding how FYI should be
handled that are not assigned to Iteration 1 of the EBMS release. It
therefore seems best to suspend FYI changes to the search form until all of
the FYI issues can be addressed together.

We will not add another FYI filter to the search form at this time.

On Agenda

We will add a new filter that excludes articles from the search that have not
been on an agenda. The new filter will have three input areas, a Meeting
Category field ("Board", "Subgroup"), and a date range with our standard start
and end date fields. Date fields will be inclusive, e.g., a search for
meetings from May 1 to May 31, 2015 will include meetings on May 1 and May 31
as well as all days in between. I'll try to put all three fields on one line
but may use two if that is impractical.

The new input fields will appear on the Advanced Search section of the
Search Database page. The fields will appear after the "EDITORIAL BOARD
RESPONSE" line and before the "EDITORIAL BOARD DECISION" line. They will look
similar to what is seen on the page for Reports > Citations > Citations by
Status and sets a status = "On Agenda" on that form.

If a user fills out any one of the three fields, the search program will
filter the search to exclude articles that have never been on an agenda as
specified by the three fields. For example:

• User chooses a Meeting Category:
  If no dates are entered, the system will search for all articles that meet
  the other criteria of the search (Board, Topic, etc.), and were on an agenda
  of a meeting with the selected category, regardless of date.

• User chooses a start date.
  If no meeting catory or end date is chosen, the system will search for any
  article meeting all of the other criteria (Board, Topic, etc.), regardless
  of meeting category, from the start date to the indefinite future.

• User chooses an end date.
  Filtering is similar to start date, but from the chosen end date and back to
  the indefinite past.

In addition to all the other criteria, to be included in an On Agenda search,
the agenda must belong to any editorial board(s) that were chosen. If, for
example, an article was selected by both the Adult Treatment and Screening and
Prevention boards, and it appeared on an Adult Treatment meeting agenda, but
not on a Screening and Prevntion meeting agenda, then if Screening and
Prevention but not Adult Treatment is selected as a filter for the search, the
article will not appear in the search results.

If a user fills out one of the On Agenda fields and changes her mind, she must
clear the field before searching - as for any other search criterion.

I've modified the search form on DEV, but the changes behind it to make the On Agenda searching working are not yet installed, so don't be fooled by the appearance of the input fields into thinking On Agenda filtering is present.

For now I just made the form look like it does in the Citations by Status report, i.e., two separate lines, one for meeting type and one for dates. As a higher priority, I'm going to try to get everything working and, if there's time, I can fiddle with the form structure to get it all on one line.

I think I am successfully retrieving only articles that are on agendas, but I'm getting too many of them.

I may be close, but it's too late at night for me to figure this out. I'll have to fix it later.

Is the partial work checked in? If not, we can just defer this task to the next iteration. If it is checked in, can you give me a checklist of what I would need to do to wrap it up for this iteration?

Hi, Alan. I reviewed the subversion logs and I can see that you checked in the work you've done so far on this ticket. Since today is the last day for development on iteration 1 (at least on the calendar), there are a number of possibilities:

1. I figure out today how to finish up the task

2. We have to wait for tester bandwidth anyway, giving us more time to finish this ticket when you're back

3. I create a patch to back out what you've checked in for the partially completed task (as well as a patch to restore it when we're ready to start iteration 2) and we move the ticket to the next iteration

4. We leave the incomplete work in the build for iteration 1, and just tell the testers and users to work around the unfinished functionality

5. We work on this during QA/UAT for the iteration and sneak it in some time next week

I think we can live with any of these possibilities. Obviously #1 would be the best, so I'll dig in and see what I can do. Any tips you can give on what's not working properly ("getting too many of them"?) would be helpful.

Any thoughts, ~henryec?

I'm okay if you take till the 11th to finish the work and include it as part of the QA deployment right before UAT starts on the 13th. Hopefully that would be enough time?

~Alan: I can't find any evidence that the search is returning too many hits. If you have such evidence, please share. I tested with the following set of searches for articles for articles on agendas:

1. on agendas for board meetings taking place July 23 (110 hits)

2. on agendas for subgroup meetings taking place July 23 (0 hits)

3. on agendas for any type of meetings taking place July 23 (110 hits)

As far as I can tell, the Peds board meeting on the 23rd had 110 articles on the agenda. It is true that there are only 27 articles cited in the agenda document attached to the event node, but there are indeed 110 articles with an OnAgenda state linked to that meeting. We might want to ask the users what their business practices are here.

If you modify your query to ensure that the state rows have an active_status value of 'A' you knock the count down to 109, but I seriously doubt that's what you were worried about when you said you thought you were getting back too many articles.

I've checked in the work that was in your sandbox from last night. Do an svn revert and then svn update to sync up the sandbox. We may want to go ahead and include this in the QA build (we don't have much choice, now that it's in SVN) and if there are bugs outstanding, we'll just fix them.

I'm going to do some more testing tonight and tomorrow.

I have found some probable errors as follows:

A search for Adult Treatment, meeting category=Board, period including June 2015, will include the EBMS ID 392443. That article was indeed selected by the Adult Treatment Board. It was also on an agenda, but the agenda it was on was for the Pediatric Board.

It is possible that this is caused by an overly optimized search technique that I'm using. I think I should be able to fix this problem by looking at the board ID in the ebms_article_state table for the row with the OnAgenda state type and matching it against what's in the ebms_agenda_meeting table.

Another problem I found was a date problem with the EBMS ID = 394499. It is retrieved on a search for Adult Treatment, meeting category=Board, dates = 6-1-2015 to later (I used 12-31-2015. When I look at the Full Citation page, I see that it's on an agenda for May, not June.

After looking into it further, this may not be a bug in searching, but possibly in the Full Citation display page. It looks like the article was put on a May meeting agenda, then moved to a June meeting agenda. I think it was actually discussed in June but still shows up in May in the Full Citation page.

I think we're very close to getting this right, but I think we can tighten it up further, at least for the two board confusion problem. The other problem may be deeper in the complexities of the system.

I'll see if I can fix the two board problem tomorrow. I have a good repro test case now that will show whether it's working or not. As for the other problem, it causes too many articles to be retrieved, but not too few, which would be more serious. If it's rare, maybe we should go into production with it anyway on the theory that the new capability is better with this small issue than it would be without the capability at all.

The information needed to search for articles that were on an agenda is pretty complicated. After spending some hours testing, looking at failures, and researching to figure out the causes, I conclude the following:

On Agenda searching works for all meeting agendas created in the new EBMS.

The articles can have been imported into the old CMS or the new one, but the software can only find articles that were on agendas of meetings held on or after 2013-03-15.

I think the limitation is not easily fixable. We do have information to say that old records were put on agendas, but we don't have the meeting content nodes in the system with meeting category and date range fields necessary to support full searching.

The changes are currently only on DEV.

I should have moved the changes to QA after our last week's status meeting when we discussed the problem of agendas for old meetings, but I forgot. They are on there now.

Thanks, Alan. I'm not comfortable signing off on this one today without having gone over it and tested it with the group, so I think it would be best to move it to a later iteration.

Moved the OnAgenda changes to Iteration 2.

We probably want to split out FYI to a separate issue to be dependent on resolution of other FYI changes that are in preparation. Perhaps we can discuss that at the status meeting today.

Verified on QA.

(The FYI changes are no longer needed because of how we plan to implement OCEEBMS-232.)

Verified on PROD.