Bug #4091

Option "<< no preference >>" for multichoice selectors in Event search translates to probably unintended query

Added by Radko Krkoš 11 months ago. Updated 7 months ago.

Status:ClosedStart date:05/15/2018
Priority:LowDue 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:
  1. Set up query with Severities set to '<< no preference >>'.
  2. 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

Related to Mentat - Bug #4092: Invalid option 'None' in multichoice dropdowns in Event s... Closed 05/15/2018

Associated revisions

Revision ae96bb62
Added by Jan Mach 11 months ago

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)

Revision a5835e4d
Added by Jan Mach 11 months ago

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š 11 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š 11 months ago

  • Priority changed from Normal to Low

#3 Updated by Jan Mach 11 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š 11 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š 11 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.

#6 Updated by Jan Mach 11 months ago

  • Related to Bug #4092: Invalid option 'None' in multichoice dropdowns in Event search added

#7 Updated by Jan Mach 9 months ago

  • Parent task deleted (#3734)

#8 Updated by Jan Mach 9 months ago

  • Target version changed from 2.0 to Future

#9 Updated by Radko Krkoš 9 months ago

  • 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.

#10 Updated by Pavel Kácha 7 months ago

  • Assignee changed from Jan Mach to Radko Krkoš

#11 Updated by Pavel Kácha 7 months ago

  • Status changed from Resolved to Closed

#12 Updated by Jan Mach 7 months ago

  • Target version changed from Future to 2.1

Also available in: Atom PDF