Our new Appfire Documentation Space is now live!
Take a look here! If you have any questions please email support@appfire.com
Transition Current Issue
Are you using JMWE for Cloud and want to learn how to use this post-function? Head to our documentation here.
A workflow post-function that triggers a transition on the current issue. This can be used to move the current issue one step further in the workflow.
To add the 'Transition Current Issue' 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
Transition current issue
from the list of post-functions.Click on
Add
to add the post-function on the transition.Specify transition(s) either in the table or as a result of the calculated transitions Groovy script. See below for more information.
Click on
Add
to add the post-function to the transition.
When you add this post-function to a transition and trigger it, the add-on will trigger the first transition encountered, applicable to the current issue and specified workflow if any.
The only reason you might want to specify more than one transition is if the post-function is added to a "global auto-transition", which can lead to any status. In that case, a different transition can be triggered depending on the current status of the issue.
Transition(s)
Trigger one of the following transitions
Input the transition name(s)
or id(s)
and optionally the workflow name manually or using the Transition picker. If you do not specify the workflow name (manually) the app will not check for a specific workflow. The app triggers the first transition specified in the table that is applicable to the issue in context.
To pick a transition using the Transition picker:
Click on Transition picker
Choose a workflow from Workflow name
Select a transition from the list of transitions displayed
Finally, click on either
Use Transition Name
- recommended if you want the post-function to search for the transition to trigger by name, which is useful when targeting multiple workflows.Use Transition ID
- if you want to differentiate between transitions that bear the same name.
Click on Add.
To remove a transition: Click on the Remove
link for the specific transition
To reorder transitions: Select and move the transition in the table to reorder the list
Trigger a calculated transition
Input a Groovy script that returns transition name(s)
or id(s)
and optionally the workflow name. To specify a workflow name, write a Groovy script that returns the transition name
or ID
along with the workflow name separated by @@.
Eg: "Done@@HR workflow"
. To return multiple transitions, write a Groovy script that returns a collection of transition names
or IDs
. Eg: ["Done","44@@Employee workflow"]
Transition screen
If the triggered transition uses a transition screen you might want (or even need) to provide a value for fields(such as Resolution) present on the screen. Look below to know how to add/set/remove fields.
To add a field: Select a field from the list of fields and click on
Add.
To Remove an added field: Click on
Remove
to remove a field.To Set a field value:
Set field value to constant or Groovy template: You can set the field to a constant value that can optionally include the result of a Groovy template. For example:
To set the Fix Version/s to 2.0, you can specify
2.0
in the value box.To set the Description of the issue, you can specify
This bug has been raised by <%=issue.get("reporter").getName()%> with <%=issue.get("priority").getName()%> priority. Act accordingly.
in the value box.
Set field value from Groovy Expression: You can set the field to the result of a Groovy expression. For example: To set the Assignee to the Reporter of the issue, you can specify
issue.get("reporter")
in the value box.
Note that you cannot set fields that do not appear on the transition screen.
Likewise, you might also want to provide a comment during that transition:
Comment type: The text of the comment can either be a
Text or Groovy template: A fixed text that can include a Groovy template markup that can be used as the comment body. For example,
The issue will be resolved on or before <%= issue.duedate%> by <%issue.assignee%>.
Groovy Expression: A Groovy expression whose return value (of type String) will be used as the comment body. For example,
issue.get("description")
will add the description of the issue to the issue as a comment.
Comment text: Text that will be used as the comment body, which can either be a fixed text or the result of a Groovy expression or the result of a Groovy template.
Comment visibility
Restrict to Group: Restricts the visibility of the comment to a specified group. When you select a valid group name in the
Restrict to Group
field, the comment will be visible only to the members of the specified group. For no restriction, leave the field blank.Restrict to Project Role: Restricts the visibility of the comment to a selected project role. When you select a project role from the drop-down
Restrict to Project Role
field, the comment will be visible only to the members of the selected project role. For no restriction, leave the field blank.
Run as
Run as user: Select one of the following options to set the author of the action performed by this post-function as:
Current user: The user transitioning the issue.
Specific user: The user specified in the select-list provided. Start typing into the field to select a user from the list of auto-suggestions.
User in field: The user specified in a user picker field of the issue being transitioned. Select one of the user fields from the list of available options in the field provided.
User from script: The user returned by the Groovy script specified in
Script
. This script should return either the Username of the user or an ApplicationUser object.Examples:
"jdoe"
- Usernameissue.get("assignee")
- the current issue's Assignee
Conditional execution
To execute this post-function based on the result of a groovy expression see Conditional execution/validation using a Groovy expression.
Error Handling
By default, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file but will not be reported to the user and will not prevent the transition from completing.
However, when designing new workflows or troubleshooting them, it is more convenient to be notified immediately of any such error during the execution of the transition. On development and staging Jira instances, you can activate error reporting for all JMWE post-functions on the JMWE configuration page, and it is recommended to do so. But on production Jira instances, you might want to show errors only for the post-function(s) being worked on, 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
.