More advanced incident/event filtering needed

[hmpf]

Tag values might need type-specific filtering:

• integer
  • more than: priority > 2
  • less than: linknumber < 24
• string
  • globbing: uninav., .uninett.no

Filter on (boolean) states

• stateful: true, false
• acked: true, false
• open: true, false

Filter on source type: similar to filtering on source

Filter on duration of an incident: has lasted more than/less than x minutes (#175)

Filter the incident list on the main page and not just for notifications (#170):

• main page: exclusive filter, exclude incidents/events
• notifications: inclusive filter, include incidents/events

[katsel]

Blocked by #70. Modelling of severity values is needed.

[katsel]

Quoting @hmpf (#255)

---

• [ ] SourceType. Like Source, a list of primary keys. No keys or missing, not filtering on source.
• [ ] Whether open/closed. True/False/None, true/false/nil in JavaScript. If None/nil or missing, not filtering on open/closed
• [ ] Whether stateless/stateful. True/False/None, true/false/nil in JavaScript. If None/nil or missing, not filtering on stateless/stateful
• [ ] Whether acked. True/False/None, true/false/nil in JavaScript. If None/nil or missing, not filtering on ackedness

Related question: should we change the field-names in the JSON-blob to python-style in anticipation of getting rid of the JSON-blob altogether in the backend, or should we wait?

When the new "level"-field is in, we should be able to filter on that as well, but that belongs in a separate issue.

A new, complete JSON-blob, with JavaScript-style key-names, would look like this:

{
  "sourceSystemIds": [1,2,5],
  "sourceSystemTypeIds": [3],
  "tags": ["foo=bar"],
  "open": true,
  "acked": nil,
  "stateful": nil,
}

---

Priority 1: Updating the API/schema

Priority 2: Make the notification filter obey the new filters

---

Another question: If the list of sources and source types are incompatible (source type says "nav" while source says "this zabbix host", what happens? If they are independent, then currently they will be ANDed together and the resulting list of incidents will be empty.

[hmpf]

Blocked by #70. Modelling of severity values is needed.

We don't need to wait on severity to add support for openness/ackedness. We can do things in small, incremental steps.

[hmpf]

Notes from design day:

• Store tags in a json blob on incident
• Still have an endpoint of tags, for typeahead in frontend
• get rid of "filter string in backend, store directly on the table
• tags as jsonblob on filter
• aim for search-box where filters look like "source:foo host:bar", no mention of tags, see frontend https://github.com/Uninett/Argus-frontend/issues/230
• think of a query language maybe, to support fancy filtering

[hmpf]

Plan:

• [ ] implement open, ack, stateful as fields on the Filter-model
• [ ] implement source type as field on the Filter-model
• [ ] implement severity as field on the Filter-model
• [ ] research jsonb in order to store tags in it
• [ ] research simplified querylanguages for UX (humio? but not pipes)

[katsel]

As Django 3.1 will introduce changes in the usage and handling of JSONField, it seems sensible to complete #257 before tackling this.

Marking blocked until #257 is done.

[katsel]

Please also mind #136, which proposes API changes to the format of the tags submitted with an incident.