If an Indicator Source query uses an "Uber" OR command, meaning that either of the two different sets of conditions can be true to generate the data set, and if the Indicator contains additional conditions to further filter the resulting data set, the additional conditions are applied only to the first set of conditions as defined in the Indicator Source.
Steps to Reproduce
Create an Indicator Source query for the "incident" table with the conditions "active=true" uber OR "active=false"
Create an indicator based on the new Indicator Source.
Add a "priority=1-Critical" condition to the indicator.
Save and view the records tab of the indicator
Note that records with a priority different than 1 appear in the result set.
Company A applied and started using the Incident Resolution Fields plugin on all incidents opened on or after November 1, 2014. Prior to that time, there was no Resolved field. The only way to tell that an incident was no longer open is if the Closed field had a date filled in. In order to account for the change in fields, the following Indicator Source could be used:
Note the “Uber OR” in the conditions, indicating that a different set of conditions should be used for Incidents opened before November 1, 2014.
A new indicator is then defined that takes the above source, and adds additional conditions, shown below:
This indicator would come up with the correct score when applied to non-real time widgets. However, if the same indicator were applied to a real-time widget, the additional conditions from the Indicator would only be applied to the first set of conditions in the Indicator Source. The conditions following the Uber OR statement would be applied without the additional conditions from the indicator also applied.
When displaying a real-time score on a widget, define the entire set of conditions in an Indicator Source so that no additional conditions are needed in the corresponding indicator.
Related Problem: PRB714156