Project

General

Profile

Actions

Bug #4091

closed

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

Added by Radko Krkoš over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Development - GUI
Target version:
Start date:
05/15/2018
Due date:
% Done:

100%

Estimated time:
To be discussed:

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 searchClosedRadko Krkoš05/15/2018

Actions
Actions #1

Updated by Radko Krkoš over 4 years 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
Actions #2

Updated by Radko Krkoš over 4 years ago

  • Priority changed from Normal to Low
Actions #3

Updated by Jan Mach over 4 years 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).

Actions #4

Updated by Radko Krkoš over 4 years 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.

Actions #5

Updated by Radko Krkoš over 4 years 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.

Actions #6

Updated by Jan Mach over 4 years ago

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

Updated by Jan Mach about 4 years ago

  • Parent task deleted (#3734)
Actions #8

Updated by Jan Mach about 4 years ago

  • Target version changed from 2.0 to Backlog
Actions #9

Updated by Radko Krkoš about 4 years 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.

Actions #10

Updated by Pavel Kácha about 4 years ago

  • Assignee changed from Jan Mach to Radko Krkoš
Actions #11

Updated by Pavel Kácha about 4 years ago

  • Status changed from Resolved to Closed
Actions #12

Updated by Jan Mach about 4 years ago

  • Target version changed from Backlog to 2.1
Actions

Also available in: Atom PDF