Assign to role member (Deprecated)

This post-function has been deprecated and replaced by Assign Issue. It could be removed at any time. You can still use it, but it is highly recommended that you update any workflows that use this post-function.

A workflow post-function that assigns the current issue to the default member of a selected project role.

When you add this post-function to a transition and trigger the transition, the add-on checks for the default member of the selected Project Role. If such member is found, it assigns the issue to the fetched user. If not, the issue is assigned to a random member of the selected Project Role. If there are multiple default members, a random member is picked among them.

The easiest is to have only one user in the selected Project Role for each applicable project.

To add the 'Assign to role member' post-function to a transition:

Click Edit for the workflow that has the transition you wish to configure the post-function on.
In the Workflow Designer, select the transition.
Click on Post Functions in the properties panel.
Click on Add post function.
Select Assign to role member from the list of post-functions.
Click on Add to configure the post-function on the transition.
Select the project role from the Project Role drop-down.
Select the options provided to add required parameters.
Click on Add to add the post-function to the transition.

Note that you need to publish the workflow for the new post-function to take effect.

If the selected Project Role can contain more than one user, you should specify how the post-function will identify the default member to use.

Since Jira does not support the notion of a default member for project roles, the Assign to role member function identifies the default member of a project role for a project by going through all the members of the project role looking for a User Property with the following two characteristics:

Property key: defaultAssignee
Property value: contains a comma-separated list of entries in the form ProjectKey -> *RoleName. *For example:

TST -> Developers, JMWE -> Testers

For backward compatibility, the following two forms are also supported:

Property Key: {ProjectName}x{RoleName} (for example: CoolProjectxQAMembers)
Property value: "default" (without the quotes)

Or: (since 1.5.3)

Property Key: defaultAssignee{n} (where n is a number from 1 up, for example: defaultAssignee1)
Property value: {ProjectName}x{RoleName} (for example: CoolProjectxQAMembers)

Action

To customize the assignment select any of the following options:

Force assignment (default) - Forcibly assigns the issue to the default member of the selected Project Role. In this case, user selected in the Assignee field on the Transition screen (if any) is ignored.
Only if "Automatic" - Assigns the issue to the default member of the selected Project Role only if the user selects Automatic in the Assignee field on the Transition screen. If not, the Assignee field will not be modified.
Use selected assignee only if member of required role - Assigns the issue to the user selected on the Transition screen, only if the user belongs to the selected Project Role. If not, the Assignee field is not modified.
Use selected assignee if changed on the transition screen - Assigns the issue to the default role member of the selected Project Role only if the assignee is not changed (or set to Automatic) on the Transition screen.

Conditional execution

It is possible to configure the post-function to execute (or not execute) only in specific circumstances. The Condition executional option sets this behavior.

Only if condition is true - Check this option to execute the post-function based on the result of a Groovy expression. See Conditional execution/validation using a Groovy expression for more information.
- Condition - Enter a Groovy expression that evaluates to true or false (or truthiness/falseness).

Error Handling

Make transition fail when an error occurs in this post-function - Select this option to make the transition fail when an error occurs while running the post-function. An error message is displayed to the user showing the transition failure.

By default Error handling is turned off. When it is turned off, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file. However, they will not be reported to the user and will not prevent the transition from completing.

When designing new workflows or troubleshooting them, it may more convenient to be notified immediately of any such error during the execution of the transition. For example, on production Jira instances you might want to show errors only for the post-function(s) being created or updated, in order to avoid disrupting other workflows. To make errors raised by the current post-function prevent the transition from completing and show the error in the browser, select Make transition fail when an error occurs in this post-function.

When the Error handling option is selected on a specific extension, it overrides the configuration on the JMWE configuration page.

If you want to show all errors - to either All Administrators or All Users - configure the option globally on the JMWE configuration page. For example, on development and staging instances, you can activate error reporting for all JMWE post-functions so as to display all the errors (it is recommended to do so); on production instances you may want to activate error reporting only for administrators so that they can be made aware of configuration errors.

You are viewing the documentation for Jira Server / Data Center.

Cloud Migration Resources

Assign to role member (Deprecated)

Action

Conditional execution

Error Handling