Permissions
Understand which permissions you need to configure ScriptRunner, and which permissions your scripts run with.
Configuring any ScriptRunner feature requires the Administer Jiraglobal permission. For background on how Jira permissions work, see Atlassian's permissions overview.
Three levels of access are relevant:
- Jira administrator: Holds the Administer Jira global permission. Can create and manage every kind of ScriptRunner content, and configure workflow rules.
- Site or organization administrator: Manages your Atlassian organization. Required only to approve the external domains your scripts can call. This is a separate role rather than a higher one: a site or organization administrator must also belong to the
jira-administratorsgroup to configure ScriptRunner. - Jira users: Everyone else. They see the results of scripts, such as a scripted field on a work item, but cannot configure ScriptRunner.
Feature permissions
Every feature is configured by a Jira administrator, with one exception: approving external domains requires a site or organization administrator. What differs between features is the permissions a script runs with, which you set per script with Run as.
Configuration and runtime permissions by feature
| Feature | Runs as (default) | Notes |
|---|---|---|
| Script console | The current user | Can be changed to the app, or to a specific user. |
| Event listeners | The app | Runs whenever its event occurs, whoever or whatever caused it: a user of any type, an automation rule, or the app. Can be changed to run as a specific user. |
| Scripted fields | The current user | Can be changed to the app, or to a specific user. |
| Work item picker fields | The current user | Can be changed to the app, or to a specific user. |
| Workflow actions (scripted) | The app | Company-managed workflows only. Can be changed to run as a specific user. |
| Workflow restrictions (Jira expression) | Not applicable | Company-managed workflows only. Jira expressions are evaluated by Jira, not run as a user. |
| Workflow validators (scripted) | The app | Company-managed workflows only. Can be changed to run as a specific user. |
| Workflow validators (Jira expression) | Not applicable | Company-managed workflows only. Jira expressions are evaluated by Jira, not run as a user. |
| Scheduled jobs | The app | Can be changed to run as a specific user. |
| Field behaviours | The current user | Cannot be changed. Runs for anyone who opens a screen it applies to, including unlicensed, anonymous, and Jira Service Management customer (portal) users. |
| HTTP endpoints | The current user | Can be changed to the app, or to a specific user. |
| Automation integrations | The current user | Can be changed to the app, or to a specific user. |
| Allowed domains | Not applicable | Approving a domain requires a site or organization administrator. A Jira administrator can add a domain to a script, but cannot approve it. |
What a script can do
Who configures a script and what that script can do are separate questions. A script does not inherit the permissions of the administrator who wrote it. It uses the permissions of whoever it runs as:
- The current user: the script can only see and change what that user could. A user who cannot browse a space gets no results from it.
- The app: the script uses ScriptRunner's own permissions, which are not limited by space permission schemes. Use this when a script must work regardless of who triggered it.
- A specific user: the script always uses that user's permissions, whoever triggered it.
Approving external domains
Scripts cannot call an external domain until it has been approved, and only a site or organization administrator can approve one. A Jira administrator can add a domain to a script, but cannot approve it.