| Info | ||
|---|---|---|
| ||
|
It's mandatory to provide this user with edit permissions on the issues where the Approval is applied Auto populate user picker field based on expression screen
Navigate the Approvals administration screen and Add an Approval Configuration by inserting an Approval Name checking the Type Single Property option.
The Approval Configuration screen displays the available properties to setup an Approval
.
Here you can choose an user picker custom field that can be populated basing on an expression.
On selecting an user picker All, distinct approbations will be requested to each user that will be inserted in the User Picker field.
On selecting an user picker Any, any user inserted in the User Picker custom field may provide the approval response on behalf of all users.
When selecting an user picker All or an user picker Any , you are able
Specify the expression identifying the users to insert in the user picker custom field
You cannot specify the users to
insert into to the user picker field (Can Approve or Reject).
You are able to insert the allowed tags on the text areas
g. <u)
Notice that, in order to avoid performance issue there is a limit on the max number of users that will be returned by the two statements.
Case of the Can Approve or Reject or the Excluded statements returns more then 100 users, only the first 100 will be considered.
You are able to select the values to insert inside the property tags just starting to type a text.
Test the expression
You are able to test an expression in order to check if the list of users returned for an issue, on evaluating the Can Approve or Reject and Excluded, matches the expectations.
In order to test your expressions, you can specify an issue key, click on Run Test and review the list of users that are returned below.
Expected syntax
Graphic Syntax Diagram
A valid expression requires that you respect the expected syntax.
The following diagram illustrates the expected syntax for valid expressions that you can specify in the Can Approve or Reject and the Excluded text areas:
Property tags
The syntax that allows to specify the property's values expects a start end tag identifying the property:
- <users>...</users>
- <groups>....</groups>
- <roles>....</roles>
- group-pickers>
- <component-leads>..</component-leads>.
Property Values
The admissible property's values depends by the selected Property:
- <users>
- Username, any username
- Reporter, key word to include in the list the issues's reporter
- Assignee, key word to include in the list the issues's assignee
- ProjectLead, key word to include in the list the concerned project lead
- Component Leads, key word to include in the list all the concerned Component Leads
- <groups>
- Group, any Jira Group name
- <roles>
- Project Role, any Project Role Name
- <user-pickers>
- User Picker custom-field, any user picker custom field identifier (Example: customfield_10125)
- <tempo-teams>
- Any Team created via the Tempo Timesheets app for Jira
- <group-pickers>
- Group Picker custom-field, any group picker custom field identifier (Example: customfield_10188)
- <component-leads>
- Project Component, any Component Name
This setting maintain the Component Name and not the Component Id in order to allow reusing the Approval across Approval mapping for different Projects.
You are able to specify one or more Property's values.
Property's values are concatenated via the ','.
Example: <users>Tom Black , Nancy Green , Jack Red , Katy White</users>
Condition Tags
The syntax that allows to specify a condition enabling a set of properties expect one of the following start end tag:
- <conditional-rule name="Conditional Rule Name">...</conditional-rule>
- <conditional-rule name="Conditional Rule Name " is-false>...</conditional-rule>
The admissible names include all Conditional Rule names that you have created via the Conditional Rules administration screen.
An expression can include zero, ore, more conditions enabling one or more properties.
Example: <conditional-rule name="Priority High"><groups>Managers</groups> </conditional-rule> <conditional-rule name="Priority High" is-false><users>Tom Black</users></conditional-rule>
How it works
Requirement
It is necessary to require the distinct approbation users that meet the following conditions:
- Case of issue priority is High
- All users that belong to the Project Rules Tempo Project Managers and Service Desk Team;
- Case issue priority is not High
- All users that belong to the group jira-administrators
- Case of the Issue has been
- categorized against the Data Center Services component
- The Data Center Services Component lead
- Case of the issue require supervisor approval (Require Supervisor use picker is not empty)
- The users dynamically selected on the Require Supervisor use picker field
- Reporter and Assignee cannot approve
Configuring Auto populate user picker field based on expression
Requested Approvals on the issue
Assuming to expect the configured Approval on an issue.
The Approval Web panel displays the users that satisfy the expression,
Example of Customer scenarios
In this section
| Table of Contents |
|---|
Related Documentation
Here you can find some links to our customer documentation relating some topics addressed in this page:
Still need help?
We would love to help.