Attempting to access the 'name' field of a user object

This warning will be logged by post-functions that refer to the name property (field) of a user object in a Nunjucks template. For example:

• Returning the value of a user-type field:

{{ issue.fields.reporter.name }}

• Returning the current user:

{{ currentUser.name }}

• Checking the assignee against a specific user:

{{ issue.fields.assignee.name == "admin" }}

How to fix

The reference to the name property must be replaced with a reference to the accountId property. For example:

• Returning the value of a user-type field:

{{ issue.fields.reporter.accountId }}

• Returning the current user:

{{ currentUser.accountId }}

Note that fields that expect a reference to a user as their value (fields that used to expect a username or a comma-separated list of usernames, such as the Assignee field or Multi-user picker custom fields) now expect an accountId or a comma-separated list of accountIds, but they will temporarily continue to accept usernames (until phase 3).

• Checking the assignee against a specific user:

{{ issue.fields.assignee.accountId == "accountId:aaaaa-bbbbb-ccccc-ddddd" }}

Note that you can use the "User lookup" button of the Nunjucks editor toolbar to look up the account ID of a specific user and insert it in your template.

In some cases, you might want to replace the reference to the name property with a reference to the displayName property, for example, when used inside a Nunjucks template returning text, such as in the Text or Html Body options of an Email Issue post-function:

This issue was created by {{ issue.fields.reporter.displayName }}.

When to fix

These warnings need to be fixed at the latest before:

• Returning the value of a user-type field, or the current user: phase 3
• Comparing the value of a user-type field with a specific user: phase 2

Attempting to access the 'key' field of a user object

This warning will be logged by post-functions that refer to the key property (field) of a user object in a Nunjucks template. For example:

• Checking the assignee against a specific user:

{{ issue.fields.assignee.key == "admin" }}

How to fix

The reference to the key property must be replaced with a reference to the accountId property. For example:

• Checking the assignee against a specific user:

{{ issue.fields.assignee.accountId == "accountId:aaaaa-bbbbb-ccccc-ddddd" }}

Note that you can use the "User lookup" button of the Nunjucks editor toolbar to look up the account ID of a specific user and insert it in your template.

When to fix

These warnings need to be fixed at the latest before phase 2.

This post-function still uses a username as the runAs user

This warning will be logged by post-functions that were configured with the "Run as this user" option before JMWE for Jira Cloud 1.1.11 was released.

How to fix

The post-function simply needs to be edited and saved. No change is necessary. This will simply store the "run as user" as an accountId instead of a usernameRun the "Automatic Migration" option of the GDPR Migration Tool.

When to fix

These warnings need to be fixed at the latest before phase 3.

This post-function still uses a username as the 'comment author'

This warning will be logged by the Copy Comments to Linked Issues post-function if it was configured with the "Author of copied comments" option set to "this user" before JMWE for Jira Cloud 1.1.11 was released.

How to fix

The post-function simply needs to be edited and saved. No change is necessary. This will simply store the reference to the user as an accountId instead of a usernameRun the "Automatic Migration" option of the GDPR Migration Tool.

When to fix

These warnings need to be fixed at the latest before phase 3.

This post-function still uses a username as the 'comment as' user

This warning will be logged by the Create Issue(s) post-function if it was configured with the "Add a comment to the current issue" option with the "Create comment as this user" sub-option before JMWE for Jira Cloud 1.1.11 was released.

How to fix

The post-function simply needs to be edited and saved. No change is necessary. This will simply store the reference to the user as an accountId instead of a usernameRun the "Automatic Migration" option of the GDPR Migration Tool.

When to fix

These warnings need to be fixed at the latest before phase 3.

This post-function still uses user names/keys and must be updated to use accountIds instead

This warning will be logged by any post-function that is somehow manipulating a username or user key. The most common case will be when setting a user-type field to a username, using a value such as:

• a username

admin

• a template returning a username:

  Code Block
  {{ issue.fields.assignee.name }}

  or

  Code Block
  {% if issue.fields.assignee != null %} {{ issue.fields.assignee.name }} {% else %} admin {% endif %}

  
  

Note that this warning can appear together with an "Attempting to access the 'name' field of a user object" warning. Fixing the latter will fix the former.

How to fix

The simple cases, such as setting a field to a username constant, will be automatically handled by the Automatic Migration of the GDPR Migration Tool. In most other cases, you will need to update the value (constant or Nunjucks template) to an accountIdusernames in Nunjucks Templates to accountIds. If you can't figure out why your post-function is logging this warning message, please open a support request on our Help Desk.

When to fix

These warnings need to be fixed at the latest before phase 3.