Incidents reassigned to HUBOT_PAGERDUTY_FROM_EMAIL

[xofer]

I may be confused about how this should work.

When I am on call, new incidents are assigned to me, naturally. But when I misty pager ack, they are reassigned to the user with HUBOT_PAGERDUTY_FROM_EMAIL. See below (our hubot is called misty):

According to the v1 to v2 migration docs, requester should be specified in the From header. It seems to me that this should be set to the user who's issuing the command (i.e. whatever I set with misty pager me as ...).

However, it's always set to the same value (HUBOT_PAGERDUTY_FROM_EMAIL). This poor guy gets reassigned every ticket.

https://github.com/hubot-scripts/hubot-pager-me/blob/414608b3e198b5dacaf5046ae1a9d25692646b57/src/pagerduty.coffee#L15-L19

Am I missing something here?

[stephenyeargin]

@biggless did the work in #111 to bring this over, so there may have been some trade-offs. I don't personally have an account anymore to test with. But I would expect as a user that the From header simply says who opened the incident, not who it should be auto-assigned to. Perhaps there may be a rule/schedule on the service that is doing that?

[xofer]

Based on experience and what's in the docs (linked above and quoted below), PD API v2 will reassign incidents to the user specified in the From header.

In API v1, several endpoints provided a requester_id parameter, used to indicate what user the API client was acting on behalf of. This enabled an API client to acknowledge an incident on behalf of a user, invite a user on another user's behalf, etc.

In API v2, this functionality is available using the HTTP From: header. Set this header with the email address of the user to act on behalf of.

[steve-stonehouse]

I too am having this issue after upgrading to the v2 API. Reading the docs, the From header needs to be the user interacting with the incident not a static one. It's a pretty big problem and we are unable to use this until it is resolved.

[biggless]

There is possible problem when Slack email doesn't match PagerDuty email. Is it ok in such cases to fallback to static email from config?

[steve-stonehouse]

IMO it would be better for a message to be returned to the user saying that the email doesn't match. The API returns a 400 with a body of {"error":{"message":"Requester User Not Found","code":1008}} so should be possible.

[stephenyeargin]

@xofer @steve-stonehouse @biggless So is there a chance that #130 might address this?

[nobert]

I can confirm that #130 fixed this problem for us. (I forked this repo and merged a duplicate of #130 to my fork, then included my branch in package.json. I believe including goodeggs/hubot-pager-me#fix-trigger-escalation-policy will do the same.

Note that we had two separate problems: one was an incorrectly set HUBOT_PAGERDUTY_FROM_EMAIL, and the second was fixed by #130. They both resulted in the same error from PagerDuty (1008).

[stephenyeargin]

Fix released in v3.1.3