Another issue with `--me` -- failing

[notjames]

The following commands:

pd incident:list --me -s resolved -s closed -s acknowledged -s triggered -s open        <<== --me does not work                                                                                                                                                                
pd incident:list -m -s resolved -s closed -s acknowledged -s triggered -s open            <<== --me does not work 

errorred with the following errors:

✦ at 09:34:16 ❯ pd incident:list -m -s resolved -s closed -s acknowledged -s triggered -s open
    TypeError: Cannot read property 'user' of null

✦ at 09:34:21 ❯ pd incident:list --me -s resolved -s closed -s acknowledged -s triggered -s open
    TypeError: Cannot read property 'user' of null

For grins and giggles, I tried adding user: <user.name> in the $HOME/.pagerduty/credentials file but that didn't fix anything.

[martindstone]

Hi @notjames , thanks for this one. Are you using PD CLI with a "Legacy" API token, that is, one that comes from the PD web UI under API access? Legacy API tokens aren't associated with any specific user, so the endpoint that we use to see who we are won't work... but that said I don't think that's a particularly friendly error message and I should probably remedy that. I have considered adding a "default user" section to the configuration as you tried :) but I think at the time I wanted to discourage usage of systemwide legacy API tokens. I will revisit this, as I am thinking to revamp a lot of the auth stuff in there anyway...

Thanks!

[notjames]

I'll check into that and see about updating my token and then test. I'll let you know how that goes.

[notjames]

I generated a new API token from the API section of the pagerduty site. I placed the token in my $HOME/.pagerduty/credentials file. Perhaps I'm generated the wrong API token. However, when testing I get:

at 14:58:09 ❯ pd incident:list --me
    TypeError: Cannot read property 'user' of null

[martindstone]

Yes... Sorry for not mentioning... that kind of token is a legacy domain wide token that does not have a user associated with it... to use OAuth, you can do pd login which will make the cli open up the browser to authenticate you, or if you're using the cli on a remote system you can get a token from my token-giver and then give it to the cli using pd auth:set

Also the error message in this situation should be way more helpful, I will add that as soon as I can...

[notjames]

Yes... Sorry for not mentioning... that kind of token is a legacy domain wide token that does not have a user associated with it... to use OAuth, you can do pd login which will make the cli open up the browser to authenticate you, or if you're using the cli on a remote system you can get a token from my token-giver and then give it to the cli using pd auth:set

Also the error message in this situation should be way more helpful, I will add that as soon as I can...

I authenticated using pd login on two different systems (one mac and one Linux). Both successfully authed. However, when attempting to use --me after authenticating. This time I don't get an error, so that's cool. Before I ran pd login I mv'ed my $HOME/.pagerduty/credentials file assuming a new one would be created. That's not the case, so I'm assuming that the oauth token is stored in my default browser's db store or something and pd uses that...or perhaps there's a different location where the oauth token is stored...I'm not sure.

At any rate, I tested and this time I didn't get the user error. However, --me still failed to find any tickets owned by me. It turns out this might be a pagerduty issue maybe. Maybe you could verify. It seems that for tickets which get resolved, the assigned to field gets nil'ed. Taking a look at pd incident:log -j shows that the user object, which I assume is the object pd uses to extract the assigned user, is set in most entries for an unresolved incident, while the same doesn't seem to be the case for all other incidents. At least this is just what three minutes of poking around does. You may not use this at all in the code and I haven't gone code diving either.

At any rate, curious what you find.

[martindstone]

Hey @notjames I sort of mentioned this in #13 as well, but the way PD works is that resolved incidents will never have an assignee, because they aren't considered to be assigned to anyone -- and "currently assigned to" is what the -e and --me flags are looking for. If you want to know who was assigned to an incident before it was resolved, you have to go into the incident timeline (pd incident:log)... You can pipe CLI commands together to achieve some of this, there's an example in my comment on #13... the alternative is you can wrap CLI in a Python script (or similar) to do the needful... sadly it is more API calls but there's currently not any way around that...

[notjames]

Hey @notjames I sort of mentioned this in #13 as well, but the way PD works is that resolved incidents will never have an assignee, because they aren't considered to be assigned to anyone -- and "currently assigned to" is what the -e and --me flags are looking for. If you want to know who was assigned to an incident before it was resolved, you have to go into the incident timeline (pd incident:log)... You can pipe CLI commands together to achieve some of this, there's an example in my comment on #13... the alternative is you can wrap CLI in a Python script (or similar) to do the needful... sadly it is more API calls but there's currently not any way around that...

Ah! That's right! I apologize that I didn't follow that thread as closely.

So it's kind of a pain but I know now so that's fine. Seems confusing why pd did that...

At any rate, thank you!

[martindstone]

Thanks @notjames ! I am going to go ahead and close this one and the other one, because I can't think of anything else we can do... Please do reopen if there's anything else...