Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle stateless incidents #166

Closed
hmpf opened this issue Nov 4, 2020 · 2 comments
Closed

How to handle stateless incidents #166

hmpf opened this issue Nov 4, 2020 · 2 comments
Labels
backend Needs/has companion issue in backend discussion Requires developer feedback/discussion before implementation
Milestone

Comments

@hmpf
Copy link
Contributor

hmpf commented Nov 4, 2020

Stateless incidents (end_time == null) look too much like stateful incidents (end_time != null). There's no controls for showing/hiding stateless incidents. They are visible in the incident-list if "Both" is on for both acked and openness. In the detail-box, they lack duration, but there's nothing else that marks it as stateless. They currently have a start event, this is probably not a good idea.

A stateless incident logically doesn't really have a start time or end time, just a timestamp. We just reuse the start_time-field to hold the value.

See also Uninett/Argus#206.

@hmpf hmpf added backend Needs/has companion issue in backend discussion Requires developer feedback/discussion before implementation labels Nov 4, 2020
@hmpf
Copy link
Contributor Author

hmpf commented Nov 4, 2020

Copied from Uninett/Argus#206 (comment):

@lunkwill42 said:

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 hmpf added this to the Blue sky milestone Nov 4, 2020
@hmpf
Copy link
Contributor Author

hmpf commented Aug 5, 2021

.. maybe they should have a "stateless"-event instead of a start-event..

@Uninett Uninett locked and limited conversation to collaborators Jun 17, 2022
@hmpf hmpf converted this issue into discussion #386 Jun 17, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
backend Needs/has companion issue in backend discussion Requires developer feedback/discussion before implementation
Projects
None yet
Development

No branches or pull requests

1 participant