JIRAAuthProvider no longer finds AccountID

We are unable to link new or refresh existing JIRA accounts to Phabricator accounts.

The JIRA user API appears to have recently stopped returning key in its returned data. This appears to have been replaced by accountId (as per https://developer.atlassian.com/cloud/jira/platform/api-changes-for-user-privacy-announcement/)

The PhutilJIRAAuthAdapter reads this old value (https://github.com/phacility/phabricator/blob/master/src/applications/auth/adapter/PhutilJIRAAuthAdapter.php#L30)

Reproduction Instructions
Go to user settings - external accounts.
Attempt to link to a JIRA account or click the “refresh” button.
See this error message:

Phabricator/Arcanist Version

46fcd135ae681bb90a1282114fb2147ab21e4f34 (Mon, Feb 3) (branched from ccf28a81121ea21d72b342cfb8ab2eee4e56bf86 on phacility)

729100955129851a52588cdfd9b425197cf05815 (Thu, Jan 30) (branched from 21a1828ea06cf031e93082db8664d73efc88290a on phacility)

034cf7cc39940b935e83923dbb1bacbcfe645a85 (Thu, Jan 30) (branched from cc2a3dbf590389400da55563cb6993f321ec6d73 on phacility)

oh boy

This looks like it’s a gigantic mess?

key was a human-readable value like alice@company.com. accountId is a random identifier.

As far as I can tell, there does not appear to be any way to look up the key for an existing user account with the new API. That is, if we have the key alice@company.com, we can not use the API to find the accountId for that user. Likewise, if we have the accountId for a user (like a1b2c3d4) we can not use the API to find the old key for that user.

The migration guide suggests using the /rest/api/2/user/ endpoint to perform updates (https://developer.atlassian.com/cloud/jira/platform/connect-app-migration-guide/). However:

So this migration strategy seems like it can not work for installs that skip from a key version of JIRA to an accountId version of JIRA.

One “fix” is to swap to accountId, then just issue guidance about unlinking and relinking accounts. This will work, but anyone linked to JIRA needs to get all of their users to successfully go through a multi-step workflow.

I’ll spend a little more time on this but I’m not terribly hopeful and this doesn’t seem like a use case JIRA anticipates from the documentation.

I filed this upstream as https://secure.phabricator.com/T13493.

There’s a likely pathway forward in the upstream task, now. If anyone is feeling ambitious enough to give it a shot, it would be reassuring to know it works in environments outside of my local test environment before I pull the trigger and break every install with a JIRA link.

The pathway is pretty messy, but JIRA hasn’t given third-party applications like Phabricator much of a way to survive this cleanly, at least as far as I can tell.

I’m not likely to land such an aggressive fix, but if things are broken for you right now it’s an alternative to waiting until I can produce a more gentle upgrade flow.

Also note that master is in turmoil right now (see https://secure.phabricator.com/T13488 and related tasks) so staying on stable is likely wise until that settles.

Thank you for looking into this! We’re in the lucky position that we can easily order everyone to relink their accounts, so that’ll be fine and I think we can avoid a manual migration step.

We’re also set on the stable branch, but have our own extension of Phabricator we can port this to and see how it works.