Skip to content
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

[Actions] PagerDuty Resolve and Acknowledge payloads should contains only fields according to the API docs. #91583

Closed
YulNaumenko opened this issue Feb 16, 2021 · 3 comments · Fixed by #96363
Assignees
Labels
bug Fixes for quality problems that affect the customer experience Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@YulNaumenko
Copy link
Contributor

Currently we have a confusing UX for a PagerDuty action, when users are creating PagerDuty action to Resolve the incidents:
according to the UI and API requirements, user should enter Summary as a required field and can fill the other fields as an optional. But it won't work, because in PagerDuty API the allowed payload body should be for Resolve:

{
  "routing_key": "routingkeyhere",
  "dedup_key": "dedupkeyhere",
  "event_action": "resolve"
}

for Acknowledge:

{
  "routing_key": "routingkeyhere",
  "dedup_key": "dedupkeyhere",
  "event_action": "acknowledge"
}

If send the payload with some other fields, those won't be saved.

We should change the actions API schema body validation for a PagerDuty to support this use case and properly modify our UI to not show the rest of the fields, when Resolve or Acknowledge events was selected.

@YulNaumenko YulNaumenko added Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Feb 16, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@pmuellr
Copy link
Member

pmuellr commented Feb 23, 2021

We should keep in mind the references to the "auto-recover action" functionality. Presumably if we have that, then the we would be creating the recover action, and so won't have to disable (or not show) the fields that can't be used. I'm kinda wondering if we should allow a customer to create a PD action (or other "auto-recover-able" actions) for the recovered action group at all. If we didn't allow that, then I'm not sure there's a case where we would need to disable|hide these fields at all.

@YulNaumenko YulNaumenko added the bug Fixes for quality problems that affect the customer experience label Mar 10, 2021
@YulNaumenko YulNaumenko self-assigned this Apr 1, 2021
@YulNaumenko
Copy link
Contributor Author

We should keep in mind the references to the "auto-recover action" functionality. Presumably if we have that, then the we would be creating the recover action, and so won't have to disable (or not show) the fields that can't be used. I'm kinda wondering if we should allow a customer to create a PD action (or other "auto-recover-able" actions) for the recovered action group at all. If we didn't allow that, then I'm not sure there's a case where we would need to disable|hide these fields at all.

I still think that this issue should be addressed, because, except of the Resolved event in PagerDuty, we also have Acknowledge event, which also doesn't expect all that fields to be changed. It still will be confusing to the users that they are able to change the summary or any other field for Acknowledge, the same as for Resolved, which we probably replace in the future with "auto-recover action".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
4 participants