Weekly GDPR API status development update - April 12

@epehrson,

Can the GDPR team do something extra to encourage admins to update?

Normally no, but if you have special circumstances, you could describe them in a DEVHELP issue, and we can take it from there.

We have a similar situation with an old app version and not migrated customers. I have raised AMKTHELP-16356.
Please let me know if you can help anyhow or if you prefer DEVHELP over AMKTHELP.

Thank you,
Jack

Similarly ACJIRA-1710 is now closed but there is no way to make it return the JQLs with accountIds. Is the related ACJIRA-1768 ticket going to fix it and is it going to be delivered on time?

Yeah, new AP.jira.showJQLEditor() API is of no use in current state :frowning:

I see couple of obstacles to implement user friendly lozenges instead of plain accountID in jql by vendors now:

  1. no regular expression for accountId (Regular expression for the new atlaasian account ID - #2 by david2)
  2. Let say we are able to extract accountIds from jql → there is no bulk API to get display names for accountId yet ( [ACJIRA-1624] - Ecosystem Jira in progress)

One more thing: it seams, it is not possible to prevent users from using user keys instead of accountIds. Suggestion REST API returns accountIds but it is possible to pass user key by typing and validation passes (rest/api/2/search?jql=assignee+%3D+admin GET 200, even with apiMigration=true). So whole migration of jqls seems to be pointless unless after each edit vendors uses /rest/api/3/jql/pdcleaner, which furthermore has others drawbacks

We just noticed an undocumented change when using the x-atlassian-force-acciunt-id:
The onBehalfOf- parameter when creating JSD requests don’t accepts emails anymore: [JSDECO-92] - Ecosystem Jira

Is this by design (would be weird) or just collateral damage?

Thanks