reporter template can misinterpet expected input for an aggregate filter
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.5 |
Fix Released
|
Medium
|
Unassigned | ||
3.6 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Consider a report that has a filter with the following properties:
- operator is greater than or the like
- field transform is "count"
The generated SQL produces a HAVING clause that looks something like:
HAVING ((COUNT(
In context, the value of XXX should just be a number. However, the interface for creating a report has two problems:
- if a filter value is set in the template, that filter value is ignored
- a selection widget is constructed based on the class and field; the only appropriate filter value for a HAVING COUNT(*) is just a plain number
The expected result: such an aggregate filter should only result in a numeric input in the report editor (if no filter value is set) or use the value set in the template.
Evergreen 3.2+
Changed in evergreen: | |
assignee: | Mike Rylander (mrylander) → nobody |
Changed in evergreen: | |
milestone: | none → 3.6.1 |
Changed in evergreen: | |
milestone: | 3.6.1 → 3.6.2 |
Changed in evergreen: | |
milestone: | 3.6.2 → 3.7-beta |
Changed in evergreen: | |
status: | New → Fix Committed |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Example of a report template that exercises the bug