Bug #4091
closed
Option "<< no preference >>" for multichoice selectors in Event search translates to probably unintended query
Added by Radko Krkoš over 6 years ago.
Updated about 6 years ago.
Category:
Development - GUI
Description
When selecting option "<< no preference >>" in multichoice dropdowns, probably incorect filtering condition is created
How to reproduce:
- Set up query with Severities set to '<< no preference >>'.
- This translates to query: SELECT * FROM events WHERE "cesnet_eventseverity" = ANY ORDER BY "detecttime" DESC LIMIT 100
- This matches no data as empty string is not a variant present in data.
- Behavior confirmed for other multichoices offering "<< no preference >>" option (Source types, Categories, Classes, ...)
No preference probably means any value, then the correct approach should be to omit the filter in WHERE. This is identical to selecting no options in corresponding multichoice so '<< no preference >>' is probably redundant. Selecting other options in combination with '<< no preference >>' is meaningless so '<< no preference >>' is counterintuitive.
Option '<< no preference >>' only exists for columns containing NULL values as it is the default for get() in source:lib/hawat/blueprints/events/forms.py@devel#L131.
- Subject changed from Option "<< no preference >>" for multichoice selectors translates to probably unintended query to Option "<< no preference >>" for multichoice selectors in Event search translates to probably unintended query
- Priority changed from Normal to Low
- Status changed from New to Feedback
- Assignee changed from Jan Mach to Radko Krkoš
- Target version set to 2.0
- % Done changed from 0 to 100
I think associated commits should resolve this issue. Details are in attached commit messages. There is still room for small improvement, the any option should be able to toggle/disable the empty option. However any and empty queries should now make sense.
Example of any query:
Gimme all events with any CESNET classification (all events, that have been correctly recognized and classified by our inspection module).
Example of empty query:
Gimme all events without CESNET classification (all events, that have NOT been correctly recognized and classified by our inspection module).
- Assignee changed from Radko Krkoš to Jan Mach
There is still room for small improvement, the any option should be able to toggle/disable the empty option.¶
I think exchanging the condition order (giving priority to "__ANY__") would fix this issue.
Example (hawat-common.js):
if (selected.indexOf('__ANY__') != -1) {
$(e.currentTarget).selectpicker('val', ['__ANY__']);
}
else if (selected.indexOf('__EMPTY__') != -1) {
$(e.currentTarget).selectpicker('val', ['__EMPTY__']);
}
and similar reordering changes in Python code.
"__EMPTY__" mutually exclusive with other options.¶
First thought was that this should not be the case to make the querying capability fully functional, i.e. "Gimme all events classified as low OR without classification", but I came to see there is probably no use case for this.
The proposed fix for any disabling the empty option will not work as "__ANY__" really means ANY NON-NULL. Therefore "__ANY__" and "__EMPTY__" are complementary.
- Related to Bug #4092: Invalid option 'None' in multichoice dropdowns in Event search added
- Parent task deleted (
#3734)
- Target version changed from 2.0 to Backlog
- Status changed from Feedback to Resolved
Already fixed in 2.0.0,
The aggregation options were replaced with:
<< without value >>
- which means events with no assigned value,
<< any value >>
- which means events with any assigned value (non-empty).
It is still possible to select any and all of these two and the enumerated values with these corner cases:
<< without value >> AND << any value >> is logically equivalent to empty filter (no SQL condition) but results in COALESCE(column, '') = '',<< any value >> AND some_enumerated_value is logically equivalent to << any value >> only.
These are different issues and the original bug can be closed now.
- Assignee changed from Jan Mach to Radko Krkoš
- Status changed from Resolved to Closed
- Target version changed from Backlog to 2.1
Also available in: Atom
PDF