{composition-setup}
cloak.toggle.type=wiki
cloak.toggle.open=>> _more info_
cloak.toggle.close=<< _less info_
{composition-setup}
{tip:title=Plugin download and support}
For more information on this plugin, including:
* download link
* version history
* JIRA version compatibility
* support and bug reporting

please refer to the following entry in the Atlassian Plugin Exchange: https://plugins.atlassian.com/plugin/details/292
{tip}

h2. Description/Features

{excerpt}This plugin provides a set of workflow extensions ([conditions|#Conditions], [validators|#Validators] and [post-functions|#functions]) that you can use to customize your JIRA workflows.
{excerpt}

h4.{anchor:Conditions} Conditions

h5. Previous Status Condition
A workflow condition that allows you to disable a particular transition (hiding it from the list of Available Workflow Actions) if the current Issue either:
* has _never been_ in the specified Status
* or was not in the specified Status _just before_ it entered the current Status (if "Most recent status only" is checked)

{toggle-cloak:id=previousstatuscondition}
{cloak:id=previousstatuscondition}
!Previous Status Condition.png|align=center!

{tip:title=Why on Earth would I need something like this?}A typical use for this workflow condition is when you can reach a certain Status from several other Statuses (through the same Transition) and want to be able to return to the originating Status.
Consider the following partial workflow :
!Previous Status example.gif|align=center!
JIRA will allow you to create a single Transition from both _Open_ and _In Progress_ statuses to the _Waiting for clarification_ status. But how do you create the transition (_Provide info_) back to _Open_ and _In Progress_? And, more importantly, how do you make sure the issue is transitioned back to the _originating_ status?
Here's the trick:
# create two _Provide info_ transitions, one from _Waiting for clarification_ to _Open_, and another from _Waiting for clarification_ to _In Progress_ (just add a space at the end of the name of one of the two transitions so that JIRA doesn't complain about duplicate transition names).
# on the first transition, add a Previous Status Condition to make the transition available only if the previous status was _Open_ (don't forget to check the "Most recent status only" checkbox).
# on the second transition, add a Previous Status Condition to make the transition available only if the previous status was _In Progress_ (don't forget to check the "Most recent status only" checkbox).

And voilà\! Your users will see only one transition from the _Waiting for clarification_ status, and it will transition the ticket back to the originating status.
You can also restore the previous Assignee by saving it in a custom field during the _Request clarification_ transition and then restoring it during the _Provide info_ transition (see _Copy Value From Other Field_ workflow function in [JIRAEXT:JIRA Suite Utilities]). Alternatively, you can use the _Assign to last role member_ function described below to assign the issue to the last user in the _Users_ role.
{tip}
{cloak}

h5. Separation of Duties Condition _^(new in 1.1)^_

A workflow condition that enforces separation of duties (for SAS-70 compliance), i.e. that makes sure the same user cannot trigger two incompatible transitions on the same issue.
For example, you can prevent a user who has triggered the "Resolve Issue" transition on an issue to trigger the "Close" issue.

{toggle-cloak:id=sepdut}
{cloak:id=sepdut}
!Separation of Duties.png|align=center!

{info:title=Specifying the incompatible transition}Because JIRA does not keep track of actual _transitions_ (or _workflow actions_) but only of changes in the _Status_ of an issue, it is impossible to distinguish between two transitions that share the same source and destination Statuses.
Therefore, the Separation of Duties Condition requires that you specify transitions in the form of a destination Status and a source Status (or _Any_ for all transitions leading to the destination Status).
{info}
{cloak}

h4. {anchor:Validators}Validators

h5. Field has been modified Validator _^(new in 1.3)^_

A validator that forces users to modify a field during a transition. 

h5. Comment Required Validator

A validator than forces users to enter a comment during a transition. If they don't, a customized error message will be displayed.
{toggle-cloak:id=comreq}
{cloak:id=comreq}
 !Comment Required Validator.png|align=center!
\\
Note that this validator is disabled if the transition is being made through SOAP because the progressWorkflowAction method does not let you specify a comment.
{cloak}

h5. Field has single value Validator

A workflow validator that checks that a multi-valued field does not contain more than one value during a transition. This can be useful, for example, to make sure users don't select more than one "Fix version" during the _Resolve_ transition.
{toggle-cloak:id=singval}
{cloak:id=singval}
\\
!Field has single value Validator.png|align=center!
\\
Option "Excluding values copied from sub-tasks" is a bit more complex. During the single-valuation test, it will make the validator ignore values that are associated with the issue's sub-tasks, if any. For example, if the issue has one sub-task, and this sub-task's _Fix version(s)_ is "1.0", then a _Fix version(s)_'s value of "1.0, 2.0" will be acceptable during the issue's transition (because "1.0" will be ignored).
{cloak}

h5. Previous Status Validator

A validator that does basically the same thing as the Previous Status Condition above.

h5. Parent Status Validator

A workflow validator that ensures that the current issue's parent issue is in one of the specified Statuses. This is useful only for sub-tasks.
{toggle-cloak:id=parstat}
{cloak:id=parstat}
!Parent Status Validator.png|align=center!
{cloak}

h4. {anchor:functions}Post-functions

h5. Assign to role member _^(new in 1.2)^_

A worfklow function that assigns the current issue to the _default member_ of the specified _project role_.
{toggle-cloak:id=assrolmem}
{cloak:id=assrolmem}
!Assign to role member.png|align=center!

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 by going through all the members of the project role looking for a User Property with the following characteristics:
* Property Key: _\{ProjectName\}{_}{*}x{*}_\{RoleName\}_ (for example: CoolProjectxQAMembers)
* Property value: "*default*" (without the quotes)

If no such member is found, the first member of the project role is used instead.

This can be used for scenarios like: "when a developer resolves the issue, assign the issue to the QA lead".
{cloak}

h5. Assign to last role member _^(new in 1.2)^_
A worfklow function that assigns the current issue to the _latest_ Assignee (excluding the current one) who is a member of the specified _project role_.
{toggle-cloak:id=asslastrole}
{cloak:id=asslastrole}
!Assign to role member.png|align=center!

When the function is executed it goes backwards through the change history of the issue. When it finds a user that belongs to the specified role, it assigns the issue to that user.

This can be used for scenarios like: "when QA fails assign the issue to the last developer who worked on it".
{cloak}

h5. Increase value of field Function

A workflow function that increases the value of a numerical field by one.

h5. Set field value from User Property value Function 

A workflow function that sets a field to the value of a User Property.
{toggle-cloak:id=setuserprop}
{cloak:id=setuserprop}
!Set field value from User Property value.png|align=center!
A typical use is to store the country, or department, or other such information, of the Reporter of an issue into the issue itself (so that it can be displayed, searched, or used by the workflow).
{cloak}

h5. Copy Field Value to Parent Function _^(new in 1.3.2)^_

A worfklow function that copies the value(s) of field into the same field of the issue's parent issue.

h5. Add Field Value to Parent Function

A worfklow function that adds the value(s) of a multi-valued field (such as _Fix version(s)_) into the same field of the issue's parent issue.

h5. Set Issue Security From User's Project Role Function _^(new in 1.5)^_

A worfklow function that sets the issue security level based on the Project Role to which the current user belongs. This function can be used on the Create transition to set a different issue security level depending on whether the issue is being created by an internal user or by an external user (e.g. a customer).

h2. Installation

Install the plugin by copying the JAR to *WEB-INF/lib* inside your JIRA web application and *restart JIRA*.

h2. Maintenance and new features

If you encounter a problem with this plugin, or if you would like to suggest enhancements or even new workflow extensions, please submit an issue into this plugin's [JIRA project|http://developer.atlassian.com/jira/browse/JMWE]. I will look into it as soon as possible.