[Observability] [Alert detail pages] Add refresh functionality

[benakansara]

Add refresh functionality to all Observability alert detail pages.

Use cases

• When alert is recovered, but the status is not updated on page.
• When some time has passed since user opened alert details page, but the page still displays old data.
• When we change rule parameters such that it will change the behavior of alert details page (e.g. modifying rule interval, group by fields, filters, threshold, etc.), it's not reflected in alert details page without refresh.
• When adding alert to cases, the "Cases" on Overview/Metadata is not updated with new cases info without refresh.
• When untracking the alert, the "untracked" status was not reflected on page without refresh. We solved this using alertStatus state, however, it can lead to UI inconsistency when switching between Overview and Metadata tabs. In Metadata tab, the status will be still active. We can again solve it with alertStatus, but once we have refresh, we can consider removing alertStatus logic.

Acceptance Criteria

• Add "Refresh" button
• Clicking on "Refresh" button should fetch latest alert info and update the page
• After using Actions menu (Add to case, Mark as untracked), in case of success, refresh the page automatically

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[jasonrhodes]

@benakansara let's chat about this and add some more detail to this, re: which places need this

[maryam-saeidi]

I would vote for refresh instead of auto-refresh.

After implementing this logic, we can remove saving alertStatus in a state on the alert details page, and we can use the refresh logic instead. @benakansara shall we add this as an acceptance criteria for this ticket?

[benakansara]

@jasonrhodes Below are some use cases for "Refresh" functionality:

1. When alert is recovered, but the status is not updated on page.
2. When some time has passed since user opened alert details page, but the page still displays old data.
3. [Not sure how useful it is in real-life use case] When we change rule parameters such that it will change the behavior of alert details page (e.g. modifying rule interval, group by fields, filters, threshold, etc.), it's not reflected in alert details page without refresh.

For 1 and 2, auto-refresh would be useful.

If we go with manual refresh, I would imagine, by default we hide "Refresh" button and show it only

• after user has modified rule parameters and saved rule
• or when user marked alert as untracked

This will help to draw user attention that something has updated on the page, so they need to refresh.

[benakansara]

I would vote for refresh instead of auto-refresh.

After implementing this logic, we can remove saving alertStatus in a state on the alert details page, and we can use the refresh logic instead. @benakansara shall we add this as an acceptance criteria for this ticket?

The issue with "Mark as untracked" is we have "Active" status very visibly displayed on the page. So user might think that something went wrong and alert is not untracked.

If we go with manual refresh, I would propose to have "Refresh" button appear only after user clicked on "Mark as untracked". If we show the "Refresh" button by default, this may not be clear for user that they need to refresh page after marking alert as untracked.

[benakansara]

alternatively, in case of manual refresh, we can keep alertStatus in state as it helps to reflect the "untracked" status immediately.

[maryam-saeidi]

The issue with "Mark as untracked" is we have "Active" status very visibly displayed on the page. So user might think that something went wrong and alert is not untracked.

If we go with manual refresh, I would propose to have "Refresh" button appear only after user clicked on "Mark as untracked". If we show the "Refresh" button by default, this may not be clear for user that they need to refresh page after marking alert as untracked.

Sorry, it was not clear in my comment, I didn't mean we don't change the status unless the user clicks refresh, I meant using the refresh logic behind the scene to refresh the whole page instead of saving only alertStatus in the component's state and updating it manually. The reason for it is to not have specific logic for different parts of the page and make sure the whole information on the page is up to date, but I don't have a strong opinion about it, it seemed like a nice opportunity to simplify this logic.

If we go with manual refresh, I would imagine, by default we hide "Refresh" button and show it only

• after user has modified rule parameters and saved rule
• or when user marked alert as untracked

I wouldn't hide the refresh because behind the scenes, by every rule execution the information in AAD will change, so the user might not interact with the page but some information can get out of date due to rule execution.

In general, I am curious to know what @maciejforcone thinks about it, I remember there was an auto-refresh on the SLO list page but eventually, they changed to manual refresh if I am not mistaken. Now they have a search bar there instead. :D

[benakansara]

Do you mean refresh the page (independent of whether "Refresh" button is there or not) when rule params are changed, mark as untracked, etc.?

If so, that's also a good option. We need to keep in mind that this will result in reloading or flickering of page without user input.

So we have 3 options: 1) refresh automatically (no UI) 2) add "refresh" button in UI 3) add "auto-refresh" button in UI

[maryam-saeidi]

Do you mean refresh the page (independent of whether "Refresh" button is there or not) when rule params are changed, mark as untracked, etc.?

If so, that's also a good option. We need to keep in mind that this will result in reloading or flickering of page without user input.

So we have 3 options:

1. refresh automatically (no UI)
2. add "refresh" button in UI
3. add "auto-refresh" button in UI

I mean adding a refresh button in the UI and implementing the logic for that. Then using the same logic behind the scene when someone untracks an alert.

[jasonrhodes]

I'm on board with what you both are suggesting here -- feel free to update the ticket description to reflect the direction you all agree on here. We can talk about priority next week, I'll schedule something since it seems like a lot of what's been planned for 8.15 is almost done (great work as usual, everyone!)

[benakansara]

I have updated the ticket description.