In our app descriptor we specify a few custom issue entity properties that store user keys as strings. We make those entity properties available for use in the JQL queries through issue property aliases. There isn’t a way to tell Jira that the string is a user reference.
To meet GDPR requirements, we need to update the value we store to be the accountId. During the migration period we can store both the userkey and the accountId because arrays are supported in entity properties.
When Atlassian updates everyone’s JQL Functions that they have saved as Filters in Jira Cloud to use accountIds instead of userkeys, are they only going to replace userkeys in clauses in the JQL that Atlassian know are referencing a user field?
Or, is it more of a naive Find and Replace effort, where any string that is a valid userkey will be replaced by the matching accountId, regardless of where in the JQL query that userkey exists (e.g. if I’m storing userkeys inside a text custom field or the description of the issue instead of inside a user custom field).
The reason I ask is because we have no way of telling Atlassian that we want them to replace JQL clauses that reference our issue entity aliases with the accountId and they have no way of knowing that the text we store is a userkey…