Permissions
Understand which permissions you need to configure ScriptRunner, and which permissions your scripts run with.
Configuring any ScriptRunner feature requires the Administer Jira permission, one of Jira's global permissions. For background on how permissions work, see Atlassian's permissions overview.
Two 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.
- Jira users: Everyone else. They see the results of scripts, such as a scripted field on a work item, but cannot configure ScriptRunner.
Warning: Space administrators cannot configure ScriptRunner. ScriptRunner's workflow rules are available in company-managed workflows only, and editing a company-managed workflow requires the Administer Jira global permission. The Administer spaces permission is not sufficient, even for selecting an existing script on a transition. Team-managed spaces, where space administrators do edit their own workflows, are not currently supported.
Configuration and runtime permissions by feature
Every feature is configured by a Jira administrator. What differs between features is the permissions a script runs with, which you set per script with Run as.
| Feature | Runs as (default) | Notes |
|---|---|---|
| Script console | As current user | Can be changed to the app, or to a specific user. |
| Event listeners | As 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 | As current user | Can be changed to the app, or to a specific user. |
| Work item pickers | As current user | Can be changed to the app, or to a specific user. |
| Workflow actions (scripted) | As 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) | As 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 | As app | Can be changed to run as a specific user. |
| Field behaviours | As 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 | As current user | Can be changed to the app, or to a specific user. |
| Automation integrations | As current user | Can be changed to the app, or to a specific user. |
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:
- As 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.
- As 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.
- As a specific user: the script always uses that user's permissions, whoever triggered it.
Warning: Running as the app bypasses space permissions. Anyone who can trigger the script, including through a work item transition or an HTTP endpoint, causes it to act with those permissions. Prefer running as the current user unless you specifically need to bypass permissions.