Is the content of existing comments going to change as a result of this? I.e. are you going to edit previously existing comments, replacing user.name with a numerical id?
Dave Meyer actually never replied to my question from June 27: how will we be able to identify add-on users (those whose name and key start with “addon_”)?
Another question: whenever the user (or administrator) needs to refer to a specific user in a reliable and immutable way, for example when configuring a post-function to set the assignee to a specific user (using JMWE or ScriptRunner), currently they specify a username or a user key. Now, the only reliable and immutable way to identify a user will be its accountId. How can a user (or administrator) identify the accountId of a user? It is displayed nowhere in the Jira Cloud UI (unlike the username which used to be displayed on user management pages and is still available on most URLs).
nirav.shah:
Would this API be accessible by Add On User ?
Docs for this method say that app scope (descriptor) required is read, and an OAuth (1.0) scope of read:jira-user. Are you getting an error when trying to call it?
@bkelley do you or anyone know if there is an open ticket for /jql/autocompletedata/suggestions which should suggest accountId instead of user key? I tried to find it but with no luck.
I’m migrating form username/userkeys to account ids.
At the moment, I cannot do permission user search between a user, issues/project and permissions. This makes the rest method incomplete. I cannot tell if a user has permission in the new way.
Re: the addition of the API endpoint for migrating stored JQL queries to use accountId:
Such a service is in our roadmap and we plan to do it as quickly as possible.
I note that the endpoint is now showing here in the REST API docs, which is fantastic. However, the docs specifically say the end point is not accessible by apps, which obviously doesn’t help our situation.
@pweinberger I’m sorry to keep bugging you about this but I’m really trying to ensure that I’m not storing any PII by the time the December 10 reporting deadline hits, and migrating stored JQL queries is currently a blocker.
I opened a ticket with ecosystem dev support (DEVHELP-1943), and they confirmed that the “Migrate personal data in JQL to use account IDs” endpoint is intentionally not available to apps. I’m really struggling to understand the rationale behind this decision. The endpoint description literally says:
If your system stores JQL and you wish to remove personal data from that JQL, you may find it useful to run your JQL through this migration resource.
Wouldn’t Marketplace apps represent a very significant chunk, if not the majority, of external systems that would store JQL queries? Why is this endpoint not available to apps?
Hey Andy, I’m not sure about this particular case, i.e. if there will be an account id in the URL instead, but you can also get this information through the provided JWT token. However, take care that the JWT user context will be removed as well and instead the sub claim will contain the account id (you can test that with the gdpr migration part in your app descriptor). Hope that helps you a bit!
Following up on my previous comments in this thread re: the “Migrate personal data in JQL to use Account IDs” REST endpoint; the dev helpdesk has opened an “Improvement” ticket at ACJIRA-1627 requesting that the endpoint be opened up to apps.
The December 10 reporting deadline is coming up very quickly, and I need to get a solution in place for migrating stored JQL queries before then – I’m positive I’m not alone in this situation.
Is there anything you can do to expedite the triage of this ticket so vendors can at least make an informed decision about developing our own solutions if the API will not be available in time?