As of early 2020, this change works:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 24 2020
JIRA did this (changed how accounts are identified) again recently (key is now accountId), see T13493.
One minor issue with this is that there's some duplication when the commit Fixes Txxx and the associated revision already has the edge (which is very common if the commit Fixes Txxx, because the revision almost always also Fixes Txxx):
To follow up on this:
I can't find any changelog in any version of Git which mentions the introduction of %B. The %B behavior was introduced in this commit in March, 2010:
See also PHI1605 (internal), which provides some evidence that:
Feb 23 2020
I landed everything so far to master. The new behavior in master should be:
- Also remove "realName" when unlinking an account.
I stumbled across what appears to be a very mild security issue in JIRA that impacts this flow. I've reported it to Atlassian's bug bounty program here (this link may or may not be visible to anyone else):
Feb 22 2020
This change sequence is almost ready to remove readers and writers to accountID, but there's still a unique <accountType, accountDomain, accountID> key on the table. Removing accountID writers completely will mean that the second user to link an account of a particular type (say, an Asana account) will run into a unique key error (since they'll write a second "Asana" account with the same empty accountID as the first "Asana" account).
- Fix a logic bug in the OAuth2 provider.
Feb 21 2020
Feb 20 2020
In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.
These callers use accountId:
I think the patch above is a piece of the solution here, but makes behavior worse for some installs: installs with a version of JIRA which returns both key and accountId will have worse behavior under the patch than without it (since it will break all the existing account links immediately). It also doesn't smoothly migrate these installs, even though it's theoretically easy/desirable to do that.
Ah, thanks. Yeah, I think that's reasonable. I'm sure some other things can still be cleaned up -- like I changed the "Subscribers" UI a little bit recently, and it could now handle disabled users more clearly:
IMHO this could be closed as resolved these days.