How ACLI identifies and works with users
- Cristina Szilágyi (Deactivated)
The ACLI originally used the userId parameter to uniquely identify users, as supported by early Atlassian applications. At the time, this identifier served as a unique key.
However, as Atlassian applications evolved, they introduced support for renaming users and switched to using system-generated, immutable user keys. This change allowed identifiers to remain stable even when users updated their details. In response, the ACLI retained its terminology while adapting to the new application-level identifiers. These adaptations have continued through recent Cloud platform changes and GDPR-related updates.
ACLI attempts to identify users in multiple ways, depending on what the target app and hosting type support. This lookup behavior varies between Cloud and Server deployments.
The user parameter is different from other user-related identifiers. It represents the application's required unique identifier for login and user recognition.
User identification differences by hosting type
Server: The user identifier typically remains the same as when the user was first added. For example, the initial
userIdremains valid when using theaddUseraction.Cloud: The required identifier is the email address associated with the user's Atlassian account. This email address links to a globally unique account ID. Atlassian allows users to change their email address, but the account ID remains constant.
With Atlassian's GDPR changes, users can control which information is shared publicly. Only the account ID and user display name are always visible to others. Some Cloud applications also expose a nickname or "mention name" that serves as a short, informal user reference. If available, the ACLI uses this nickname in the userId field. Other information, such as the email address, can be hidden based on user preferences. Any field that is not exposed appears as blank in the ACLI output.
Many Atlassian Cloud applications no longer support user management actions such as addUser, updateUser, and removeUser.
User field reference across ACLI clients
Each ACLI client and hosting type supports different identifiers. The following table outlines how various user-related fields map across supported clients.
Field | Description | Jira CLI Server | Jira CLI Cloud | Confluence CLI Server | Confluence CLI Cloud | Bitbucket CLI |
|---|---|---|---|---|---|---|
User Key | A system-managed unique identifier that cannot be changed. In Cloud, this is known as |
|
|
|
|
|
User Id | An identifier such as a username, nickname, or mention name is usually easier to remember and may not be unique in Cloud. |
|
|
|
|
|
User Display Name | The name the user chooses to be displayed to others. |
|
|
|
|
|
User Email | The user’s email address, which might be visible or not, depending on privacy settings. |
|
|
|
|
|