I'm looking at the search problems that were reported in the
Sharepoint Technical Incident Report (TIR) in OCE Works.  The
numbered items below correspond to individual problem reports in
the TIR.

1. Include Rejected Articles.

   In my paper on how searching works I wrote the following:

   INCLUDE REJECTED ARTICLES:

     Currently unimplemented and ignored.  We need to discuss
     what this should do.

   None of us got free enough to actually discuss what it should
   do.  My basic question is, What should be excluded when the
   box is not checked?

    a. All articles with any of the reject states?

       That includes board manager and reviewer rejections as
       well as initial reviewer and not list rejections.

    b. All articles rejected before publication?

       This would include articles rejected in initial review and
       articles rejected by NOT listing.

    c. All articles that have not (yet) passed initial review.

       This would include everything in b. plus anything that has
       not yet been initially reviewed.

    d. Something else?

   Depending on how we do it there could be performance
   implications.  But let's first get the exact requirement and
   try it out and then decide if we need optimization.

2. Reset or clear button.

   This is a user interface issue I'll refer to Bob or Dan.

3. Review cycle.

   This one actually works, but has limitations.  In the
   searching paper I wrote:

   REVIEW CYCLE:

     Selects articles imported during the specified review cycle.
     The software for this search uses the new data structures
     created in the new import software.  It cannot find review
     cycles for the legacy data.  Unless we change that, a user
     should use the input date or publication year month searches
     for legacy data.

   So in the future this will work for all new data.  I'm having
   problems talking to the QA server at this time but I tested
   again on the DEV server and it works for the November 2012
   cycle, which has a couple of newly imported test records.

4. Input date and date range.

   The underlying software supports the required features, i.e.,
   it is possible to process a year without months, a month
   without days, and date ranges.

   It used to work.  Honest :)

   I'll figure this out and fix it - though I may not get to it
   for a week or two.

5. 500 Max.

   Sorry.  I left the max in for testing but forgot to take it
   out for QA.  I'll put the fix in version control so it will be
   picked up on the next QA build.

   If the performance is bad, which it might be for searches with
   huge result sets (partly related to sorting them), then we
   might consider another field on the search form where a user
   could specify the max number of hits to look for.  We could
   set a default of 500, or whatever, and let a user clear the
   field if she wants everything, or set some other max.

6. Publication date pull down should show most recent dates
   first.

   Good idea.  I'll leave that as an enhancement for the user
   interface guys.

7. Jump ahead multiple pages.

   Another user interface enhancement for Bob or Dan.

8. Display option to view queue.

   I _think_ this is handled by a different function that pulls
   up the initial reviewer queue, not the search interface.  Dan
   would probably know but he's gone for the evening.

9. Sort PMID and CMS ID in reverse order.

   Ah, an easy one.  I fixed it and will put in version control
   The fix should be in the next QA release.  Does this lower the
   priority of 7?

10. Finding 'No' decisions as well as 'Yes' decisions.

   This is something that got lost during a period of scrambling
   to get stuff out the door faster (we're still in that period,
   but eventually we'll get out.)

   Laura's original requirements and Ashleigh's original design
   specified separate YES and NO checkboxes or radio buttons for
   the advanced search options but, in the scramble, only YES got
   implemented.

   If and when the user interface is changed back to the YES/NO
   pairs instead of just one box each, I can implement it in the
   searching back end.

   I don't think it will be hard to handle this but there's an
   issue of priorities, which someone above me will have to
   decide.