Bug #4091
Option "<< no preference >>" for multichoice selectors in Event search translates to probably unintended query
Status: | Closed | Start date: | 05/15/2018 | |
---|---|---|---|---|
Priority: | Low | Due date: | ||
Assignee: | Radko Krkoš | % Done: | 100% | |
Category: | Development - GUI | |||
Target version: | 2.1 |
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.
Related issues
Associated revisions
Improvements in eventservice library (DBAL for events).
The SQL query builder in events DBAL was improved to support '__EMPTY__’, '__ANY__’ and negation search parameters for following keywords: categories, classess, severities, protocols, detectors and detector_types. These improvements enable using queries like: * all events without specified severity * all events with any class
(Redmine issue: #4091)
Improvements in event search form.
The event search form was enhanced to support new 'empty’ and 'any’ search options, that were introduced by previous ae96bb6. This also fixes the issue #4091 with the 'no preference’ option, that was broken. Additionally, the bootstrap select widgets now try to enforce the policy, that 'empty’ and 'any’ options are mutually exclusive with everything else. There is stil room for improvement, because 'any’ option is not capable of disabling the 'empty’ option. (Redmine issue: #4091)
History
#1 Updated by Radko Krkoš 9 months ago
- 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
#2 Updated by Radko Krkoš 9 months ago
- Priority changed from Normal to Low
#3 Updated by Jan Mach 9 months ago
- 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).
#4 Updated by Radko Krkoš 9 months ago
- 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.
#5 Updated by Radko Krkoš 9 months ago
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.
#9 Updated by Radko Krkoš 7 months ago
- Status changed from Feedback to Resolved
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).
<< without value >> AND << any value >>
is logically equivalent to empty filter (no SQL condition) but results inCOALESCE(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.
#10 Updated by Pavel Kácha 5 months ago
- Assignee changed from Jan Mach to Radko Krkoš
#11 Updated by Pavel Kácha 5 months ago
- Status changed from Resolved to Closed