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

ContactMethod field does not populate inside the NotificationRule on a User #250

Closed
stefprez opened this issue Nov 18, 2020 · 4 comments
Closed
Labels

Comments

@stefprez
Copy link

When fetching a user, the NotificationRules get populated for that user, but the ContactMethod field on each NotificationRule in the []NotificationRules always seems to be empty.

@theckman
Copy link
Collaborator

@stefprez can you give me an idea of how you're calling GetUser? Are you telling it to include the notification_rules?

@theckman theckman added the open question there is an open question on the issue / PR label Feb 20, 2021
@theckman
Copy link
Collaborator

theckman commented Feb 20, 2021

@stefprez oh sorry, I misread your question originally. That is the expected behavior in terms of how PagerDuty documents their API, and the fact you expected it to be present might indicate a deficiency in our library. Please refer to this API documentation page.

You'll notice that under the schema for the response, the notification_rules array contains an object that has the following fields: id, summary, type, self, and html_url which is the same structure as the APIObject type in this package. It does not contain a contact_method field.

The PagerDuty REST API often returns references to the real object instead of returning the whole object in the response. This is to keep response sizes down.

I don't believe we should try to make the extra requests on behalf of the consumer to populate that data, so I think this bug should be marked as wontfix.

That said, for v2.0.0 I'll open an issue to track research on updating these references to use APIObject instead to avoid this kind of confusion.

@theckman
Copy link
Collaborator

I've opened that issue and will now close this one in favor of #279

@stefprez
Copy link
Author

Excellent. Thanks for the additional context!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants