Skip to content

Update incident escalation policy if user sets alert incident status

Sarah Yasonik requested to merge sy-look-at-sidebar-updates into master

What does this MR do and why?

Minor non-blocking UX improvement for &5716. (A little context: #345769 (comment 913312037))

When an incident was created prior to the enablement of the :incident_escalations feature flag, the incident has no corresponding IncidentManagement::IssuableEscalationStatus record. IE) The Status field on the incident says None. For an incident created from an AlertManagement::Alert, setting the status for the first time via the UI can also set the escalation policy for the incident - if the project has a policy under Monitor > Escalation Policies. This MR makes it so the incident sidebar updates the policy field without a page refresh in that scenario.

Screenshots or screen recordings

How to set up and validate locally

  1. Create an escalation policy
    1. Nav to Monitor > Escalation Policies
    2. Create a new one & route on-call pages directly to a user (so you can skip setup for an on-call schedule)
  2. Create an alert
    1. In a project with maintainer+ permissions, nav to Settings > Monitor > Alerts
    2. Create a new alert integration (name it, set it to active, skip everything else, click save)
    3. Create a new test alert with a payload like { "title": "This is my test alert" }
  3. Create an incident from the alert (Create incident button on alert detail page from Monitor > Alerts)
    • Option 1: Create incident w/ feature flag disabled OR
      Feature.disable(:incident_escalations)
    • Option 2: Delete escalation status record in rails console after incident creation
      Issue.incident.last.escalation_status.destroy!
  4. Open the incident
  5. Set the Status field to any value other than None
  6. The Escalation policy field should have a value w/o refreshing the page

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Sarah Yasonik

Merge request reports