Mentat

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

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.

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.