How to handle stateless incidents

[hmpf]

Currently, if an incident is stateless, whether it is open or closed is irrelevant. It cannot be closed. Its end_time will forever be None/null.

When filtering on open/closed, these are hidden, because that filter only checks for end_time being set/not None. When not using an open/close filter ("both" in frontend), these are visible. There exists a filter to find/exclude stateless incidents, but this is not used or visible by the frontend.

Also, it doesn't make sense to have a "start"-event on these. Should they have their own stateless-only event, or no events? Does it make sense to ack (an event) such an incident?

Example in prod: #1102, start time 11/4/2020, 10:43:26 AM.

[lunkwill42]

1. I think there should be a separate event type for stateless incidents. Instead of creating a STA event, it should perhaps be something like MSG, which indicates this was a one-off message - i.e. an incident with no time extent. Maybe INS for "Instant"?

2. Acks are for suppressing open incidents, so I guess they make no sense for stateless incidents. But you could still use them to add some sort of comment to a stateless incident, if you so wished.

Since we do not currently have a filter to turn on/off stateless incidents, it's okay to show them when the "open/closed" filter is chosen. However, the red "Closed" badge makes no sense on these incidents - and neither does the green "Open" badge. The badge should either be entirely removed, or perhaps replaced with "Stateless" or "Instant".

[hmpf]

I just pushed an update to the command create_fake_incident to allow it to create stateless incidents. I had none in my test database.

[hmpf]

I think when we have settled on an event-type, we should retype the existing start events on stateless incidents.

[hmpf]

Since we do not currently have a filter to turn on/off stateless incidents, it's okay to show them when the "open/closed" filter is chosen.

Currently they are not, only when neither is asked for: "Both" in the frontend. Maybe we should have a four way toggle: "Open", "Closed", "Stateless", "All"?

See Uninett/Argus-frontend#356

[lunkwill42]

Currently they are not, only when neither is asked for: "Both" in the frontend. Maybe we should have a four way toggle: "Open", "Closed", "Stateless", "All"?

Yes - since stateless can neither be open nor closed...

[hmpf]

In the meantime I will see if adding "stateful=True" to the fallback filter in production will improve things.

[hmpf]

We need to figure out what the filterset does when given more than one flag: OR or AND. We want AND most of the time.

See #354