This article gives a brief explanation of the Exalate user types, how they interact with the app and your task management systems, and how to configure them.
There are 2 main types of users in Exalate: a Proxy user, and an Exalate Administrator. Check out detailed information about the main user types for your task management system.
Exalate Proxy User
A proxy user is a work management system user, who will be used by Exalate to make changes, such as:
- Creating entities
- Updating data
The proxy user impersonates external instances. All changes on local issues are performed on behalf of this user. You can use an existing user account or create a new one, specifically dedicated to Exalate.
Check out detailed information on Proxy User configuration.
Exalate Administrator
The Exalate administrator is the user that has access to the "Exalate Console". With the Exalate Console, it is possible to configure and manage connections and the overall synchronization operation.
There are 3 types of Exalate administrators:
The Local Exalate Admin
Local Exalate Admin access is required to configure and maintain all connections in all configuration modes from the local side. Such admin access is required due to the distributed architecture of Exalate. Since each side is autonomous, a local admin will ensure all connections and configurations are working as intended on the respective task management systems.
Admin on both Systems
This admin access is required to configure a connection using the Visual configuration mode. It means that the user has administrative rights on both systems. As a first step in the configuration of the Visual connection, a verification process is started to ensure that the user has the correct access to both systems.
The Project Level Admin
(Available currently since Sep 2021, only on Jira Cloud - version 5.2.0 and higher)
As a project administrator, it is possible to set up Basic connections without having system administrator rights.
The Basic configuration is fixed, and initiating/accepting such a connection is the only allowed configuration. Given this restriction, the configuration can be set up by a non-system administrator as well.
Delegated Admin Access for Non-System Admins
Note: This feature is only available for connectors that have the embedded exalate console.
In some situations, you may need to grant non-system admins access to the Exalate Admin Console without giving away system-wide admin permissions. This would allow you to delegate admin maintenance tasks, such as adding, editing, and deleting Exalate configurations, create connections for all projects in Jira Cloud, as well as view and manage Errors, Sync Queue, Triggers, Clean-up, and Bulk Connect.
The delegated admin user must fulfill the following requirements:
- be a member of the exalate_console_admin group
- be a project admin
IMPORTANT: The system tracker admin must create the exalate_console_admin group.
LIMITATION: A project admin who is also a member of the exalate_console_admin. group cannot accept Public Basic and Visual connections which have been initiated from the remote side.
Why are Administrator-level Permissions required?
The Visual and Scripted configuration mode provides the possibility for deep integration with the underlying task management system through Groovy scripting. This flexibility also has the consequence that any data can be retrieved and modified. Users able to configure Exalate will have the capability to retrieve and/or modify any data. Access to the Exalate Console must be handled in the same way as access to the administration modules of the tracker itself. It is therefore necessary that the authentication to the platform is handled by the platform, and Exalate has no internal user directory.