Return to Previous Status

 

A workflow post-function that returns the issue to its previous status. This is useful when multiple transitions can lead to the same status (e.g. Escalated) and you want to return the issue to the previous status.

To add the 'Return to Previous Status' post-function to a transition:

1. Click Edit for the workflow that has the transition you wish to configure the post-function on.

2. In the Workflow Designer, select the transition.

3. Click on Post Functions in the properties panel.

4. Click on Add post-function

5. Select Return to Previous Status from the list of post-functions.

6. Select Use a transition if one is available option to trigger a transition if one is available to the originating status

7. Click on Add to add the post-function on the transition.

Note you need to publish the workflow

Related links :

• Use cases for this post-function

• How to write Groovy scripts in the editor

• Placing post-functions on a transition.

Open

When you add this post-function to a transition and trigger the transition, the add-on moves the issue to the immediate previous status the issue has been in. The add-on sets the status field and hence a transition to the previous status is not needed. If you wish to move the issue to the previous status through an existing transition (generally needed to validate potentially required fields ) then select the "Using a transition if one is available" option.

Example 1:

A typical use for this workflow post-function is when you can reach a certain Status from several other Statuses and want to be able to return to the originating status. Consider the following partial workflow:

Open

Consider a case where you want the ticket to be “Escalated” from different status(es) of the workflow and move back to the originating status on resolving the escalation. In general, you will need one transition each to return back to the originating status. The easiest is to have an auto-transition (to the same status) on the Escalated status which when triggered moves the issue to the originating status using the “Return to Previous Status” post-function. Note that since the issue is moved without a transition to the status, i.e by setting the “Status” field directly, it will not validate potentially required fields (such as the Resolution field). To configure this:

1. Add the “Resolve Escalation” auto transition to the “Escalated” status

2. Add the “Return to previous status” post-function to the “Resolve Escalation” transition

3. Click on “Add”

4. Save the post-function

5. Place the transition after the “Set issue status to the linked status of the destination workflow step" built-in post-function.

6. Publish the workflow.

You can use the option "Using a transition if one is available" option if a transition to the originating status exists. This is useful when you have validations to happen when moving back to the originating status.

Example 2:

Another use case is where you want to return from a global status to the originating global status. Consider the following partial workflow:

Consider a case where you want to be able to request information from all status(es) of the workflow and move back to the originating status on providing the information. In general, the user needs to manually identify from the history from which status the information has been requested and then trigger the respective transition. The easiest is to have an auto-transition (to the same status) on the “Information Requested” status which when triggered moves the issue to the originating status using the “Return to Previous Status” post-function. Since you already have the global transition you can move the issue to the originating status through the transition in the post-function. To configure this:

1. Add the “Provide Information” auto transition to the “Information Requested” status

2. Add the “Return to previous status” post-function to the “Provide Information” transition

3. Click on “Add”

4. Select the “Use transition if one is available” option

5. Save the post-function

6. Publish the workflow.

Now when you trigger the “Information Requested” transition from the “To Do” status and then the “Provide Information” transition, the post-function is triggered and the issue is moved back to the “To Do” status through the “To Do” transition.

Conditional execution

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. For example, on the 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.

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