Setting configuration properties
Automation for Jira includes a number of configuration properties that let you check or change the default values related to various actions, conditions, and other items.
You need to be a Jira administrator to view or change the configuration properties.
Checking the current value
To check the property’s current value:
curl -u <user>:<password> http://<JIRA_BASE_URL>/rest/cb-automation/1/configuration/property/<PROPERTY_KEY>Changing the value
To change the value:
curl -u <user>:<password> -X PUT -H 'Content-type: application/json' --data '{"key":"<PROPERTY_KEY>","value":"<VALUE>"}' http://<JIRA_BASE_URL>/rest/cb-automation/1/configuration/property/For example:
curl -u admin:admin -X PUT -H 'Content-type: application/json' --data '{"key":"outgoing.webhook.timeout.ms","value":"50000"}' http://jira.atlassian.com:8080/jira/rest/cb-automation/1/configuration/property/For Jira running on Windows server, you can use Invoke-webrequest. The script below was tested on Windows Server 2016:
$user = 'YOUR_USER_ADMIN'
$pass = 'PASSWORD'
$pair = "$($user):$($pass)"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$Headers = @{
Authorization = $basicAuthValue
}
$Uri = 'http://YOURJIRABASEURL/rest/cb-automation/1/configuration/property/bulk'
$Form = @{
"ms.teams.notification.action.url.prefix"="https://"
}
Invoke-WebRequest -Uri $Uri -Method Put -Body ($Form|ConvertTo-Json) -ContentType "application/json" -Headers $HeadersList of properties
Here’s a list of properties that you might find useful. We’ll keep updating it.
| Category | Property key | Data type | Default value | Description |
|---|---|---|---|---|
Project Admin permissions |
| Boolean | true | Specifies whether project admins can manage automation rules. |
| String | null | Lets you limit project admins who can manage automation rules to specific groups only. The value contains a CSV list of groups. | |
Service limits |
| Long | 1000 | Limits the number of issues returned by the JQL search. |
| Long | 3600 | Specifies how long the same rule is allowed to run per day. The value is in seconds. | |
| Long | 2 | Specifies how many times the same rule can be executed during a 5-second time window. | |
| Long | 5000 | Specifies the maximum number of times the same rule can be executed per hour. | |
| Long | 25000 | Specifies the maximum number of executions that can be queued for the same rule. | |
| Long | 100000 | Specifies the maximum number of items in the automation queue. | |
| Long | 30000 | Specifies the maximum rule execution time. After this time, the rule is reported as causing timeouts. The value is in milliseconds. | |
| Long | 1000 | Limits the number of issues returned by the JQL search in the scheduled trigger. | |
| Long | 10 | Specifies the maximum number of branch executions with immediate priority. | |
| Long | 90 | Specifies how long audit log entries are kept for a rule. The value is in days. | |
Action and condition specific |
| Long | 30000 | HTTP timeout for outgoing webhooks. The value is in milliseconds. |
| Integer | 50 | Specifies the maximum number of users that can be retrieved from a single role in the User condition. | |
Performance rule insights |
| Long | 1 | Denotes the frequency of running the job to populate performance rule insights for rollup type |
| Long | 5 | Denotes the frequency of running the job to populate performance rule insights for rollup type | |
| Long | 5 | Denotes the frequency of running the job to populate performance rule insights for rollup type | |
Stale entries |
| Long | 2880 mins (48h) | Denotes the maximum duration for looking up stale entries. |
| Long | 720 mins (12h) | Denotes the minimum duration for an entry to be considered stale. | |
| String | 0 0 0 1/1 * ? * (Once every 24 hours) | Denotes how often the stale entry update job will run. |