EBMS Tickets

While I was doing some work on proof-of-concept prototyping in anticipation of the upcoming project to rewrite the EBMS using Drupal 9, I noticed a bug in the search logic. It affects searches for which at least one topic was selected, and the default logic was switched from "OR" to "AND" to request that every selected topic must appear in the search results. The effect of the bug is to cause the results set to be empty. I think it is more likely that I introduced the bug in recent years myself, rather than present in Alan's original implementation of the search class. In any case, there have only been 41 searches in the entire history of the EBMS when the default "OR" logic was overridden and any topics were present, and in most of those cases only one topic had been selected, so it seems likely that there was confusion about what that option does, since it's only meaningful for searches in which more than one topic has been selected. So the bug only affected approximately 0.01% of all searches run in the EBMS.

For those who may be curious, here's a breakdown of the options used for the searches since the EBMS went into production. Note that the report shows three of the options as "exclude-unpublished," "exclude-rejected," and "exclude-not-listed" even though the interface labels the checkboxes as "INCLUDE UNPUBLISHED," "INCLUDE REJECTED," and "INCLUDE NOT LISTED." That's because by default those three checkboxes are checked (though I don't believe that has always been the case).

analyzing 145599 search requests
    6 ( 0.00%) cycle-range-end
    6 ( 0.00%) cycle-range-start
    8 ( 0.01%) board-manager-comment
   10 ( 0.01%) use-input-date-range
   12 ( 0.01%) meeting-end
   17 ( 0.01%) meeting-start
   17 ( 0.01%) use-tag-date-range
   19 ( 0.01%) meeting-category
   19 ( 0.01%) summary-topics-added
   20 ( 0.01%) and-topics
   20 ( 0.01%) fyi-citation
   27 ( 0.02%) use-comment-date-range
   34 ( 0.02%) reviewer
   37 ( 0.03%) use-mod-date-range
   38 ( 0.03%) publication-month
   40 ( 0.03%) response
   53 ( 0.04%) only-unpublished
   62 ( 0.04%) core-journals
   83 ( 0.06%) comment-added-end
  102 ( 0.07%) comment-added-start
  102 ( 0.07%) modified-end
  124 ( 0.09%) modified-start
  136 ( 0.09%) comments
  149 ( 0.10%) decision
  176 ( 0.12%) input-end
  177 ( 0.12%) only-rejected
  190 ( 0.13%) input-start
  228 ( 0.16%) only-not-listed
  380 ( 0.26%) committee-decision
  410 ( 0.28%) journal
  675 ( 0.46%) tag-added-end
  678 ( 0.47%) tag-added-start
  699 ( 0.48%) full-text-retrieved
  759 ( 0.52%) tag
 1118 ( 0.77%) topics
 1361 ( 0.93%) cms-id
 1438 ( 0.99%) publication-year
 1775 ( 1.22%) nci-reviewer-decision
 2255 ( 1.55%) title
 3491 ( 2.40%) author
 3507 ( 2.41%) review-cycle
 6500 ( 4.46%) boards
 6915 ( 4.75%) exclude-unpublished
 7173 ( 4.93%) exclude-rejected
 7252 ( 4.98%) exclude-not-listed
62195 (42.72%) pmid

Because this bug affects such a tiny percentage of the searches, it's unlikely that we'll end up fixing it before the Drupal 9 rewrite. Just in case, though, here's the patch.

diff --git a/ebms.nci.nih.gov/modules/custom/ebms/EbmsSearch.inc b/ebms.nci.nih.gov/modules/custom/ebms/EbmsSearch.inc
index 43b69e3..dcc5b9a 100644
--- a/ebms.nci.nih.gov/modules/custom/ebms/EbmsSearch.inc
+++ b/ebms.nci.nih.gov/modules/custom/ebms/EbmsSearch.inc
@@ -347,7 +347,7 @@ class EbmsSearch {
             else {
                 foreach ($this->topics as $topicId) {
                     $alias = $this->addStateJoin($states, $state_filter);
-                    $this->qry->condition("$alias.topic_id", $this->topicId);
+                    $this->qry->condition("$alias.topic_id", $topicId);
                 }
             }
         }