Product Demo: JMWE for Jira Cloud

Viewing time 32 minutes   for Jira Misc Workflow Extensions for Jira Cloud 
 
Jira Misc Workflow Extensions (JMWE) for Jira Cloud offers dozens of point-and-click workflow conditions, validators, and post-functions. You can easily configure them without any knowledge of scripting. But unlike other apps, JMWE also gives you additional configuration power through simplified scripting - this will come in handy when automating more sophisticated workflows. With our top-notch support and documentation, this flexibility earns JMWE the #1 top-selling workflow app spot for Jira Cloud.

Here is what we cover in this video: 

Read more ...

How to validate field changes


If important issue updates occur outside of status changes, you cannot validate field entries using workflow Validators. That's where our powerful Event-based Actions come in. It offers a collection of triggers that will kick off one or more of JMWE's post functions to automate processes outside of workflows. One of its triggers - Issue Field Value Change - will trigger an action when an issue field value changes.

 

When a user edits an issue, validate field value input - if it's wrong, show the message and roll back to the previous value.

Viewing time 2 min 30 sec  


For your convenience, the steps from the above video have been outlined below.

  

When a user edits an issue, validate the field value input.

Here is how to validate input when a user changes a field, and display an in-app message when the input doesn't follow the required format to alert the user. Even better - automatically revert to the previous value.

  • Go to Event-based Actions in the JMWE App administration.
  • Click on "New event-based action" to create this automation.
  • Give it a name, such as "Check value of man hours."
  • In the Event trigger, select "Issue Field Value Changed."
  • In Fields to monitor, select "Man hours" field to watch for changes and to validate.



  • Optional: Select any one or more Projects to apply this to. Leave blank if this applies to all projects globally.
  • Optional: You can also select issue types to which this action will apply.
  • In the Scope section, add conditional execution by checking "Only apply to issues that match a Nunjucks condition."
  • In the "Nunjucks condition" field, navigate to and expand the "Issue Fields" tab, select "Man hours" in the field dropdown.
  • Referred to the field either by Name or ID, click on it to select and insert the proper field - issue.fields["Man hours"] - into the value section. We suggest using field IDs instead of names in case the name is edited in the future.
  • In the "Nunjucks condition" section, add >10 (to represent "greater than 10") after the name or ID of the field.



  • Press "Add post function." We'll configure a post function to display an "error" message to users if the field value entered is greater than 10.



  • Add "Display Message to User" post-function.
  • Input information you want to appear to users if the "Man hours" field entry is greater than 10.



  • Optional: select message type "Warning" and check "Automatically close message."
  • Save the post function.



  • Again, "Add post function". We'll configure a post function to roll back the field to the previous value.
  • Select the "Set field value" post function, and configure it.
  • Select Field "Man hours."
  • Type the following Nunjucks expression into the Value field:
    {{issue | fieldHistory( "Man hours" ) | last | field("from_string")}}
    This will set the previous field value. You can find all these snippets of code in our documentation.



  • Press "Save" to save the post function.
  • Press "Save" to save the Event-based Action.



  • All done.



See it all in action in the video above.


 

How to calculate field values


While Jira allows you to create custom fields, it doesn't provide a way to perform calculations within those fields. In this video, learn how to automate calculations using values that appear in your Jira issue’s custom fields using the Issue Field Value Change trigger of Event-based Actions.

 

Automate calculations, i.e., calculate the labor cost estimates based on "man hours" and "hourly fee."

Viewing time 2 min 14 sec 


For your convenience, the steps from the above video have been outlined below.

  

Build calculated fields to calculate the cost estimates based on data from other fields automatically.

Let's say you want to calculate the labor cost estimates based on custom fields that record "man hours" and "hourly fee", and display the result of it in each issue. While Jira cannot automatically do this, you can easily set up a post-function to run this calculation triggered on a field change. This will ensure that the field is always accurate and that it won't require manual calculations. Better yet, this field will automatically adjust if a custom field value that drives this calculation changes. For example, if the number of hours worked increases or the hourly fee changes, so will the labor cost.

First, set up custom fields: "Man hours", "Hourly fee", "Labor cost" (make this last one a read-only field).

Then, automate this calculation using the "Issue Field Value Changed" trigger from Event-based Actions: "Man hours" * "Hourly fee" = "Labor cost".

  • Go to Event-based Actions in the JMWE App administration.
  • Click on "New event-based action" to create this automation.
  • Give it a name, such as "Labor cost estimate."
  • In the Event trigger, select "Issue Field Value Changed."
  • In Fields to monitor, select "Man hours" and "Hourly fee". Any time one or both of these fields change, the calculation event will be triggered.
  • Optional: Select any one or more Projects to apply this to. Leave blank if this applies to all projects globally.
  • Optional: You can also select issue types to which this action will apply.
  • Click on "Add post function" to configure a post function to perform the action - calculation in this case.



  • Choose the "Set field value" post function, and Add.
  • Leave "Target issue(s): as is (Current issue).
  • In the "Field to set on the target issue" section, select a field to update. "Labor Cost" in this case.
  • In the "Value" field, navigate to and expand the "Issue Fields" tab, select "Man hours" in the field dropdown. 
  • Referred to the field either by Name or ID, click on it to select and insert the proper field - issue.fields["Man hours"] - into the value section. We suggest using field IDs instead of names in case the name is edited in the future.
  • In the value section, add * (to function as multiplication).
  • Search for and select the "Hourly fee" and click on the proper field to insert it into the value section.



  • Press "Save" to save the post function.
  • Press "Save" to save your Event-based Action.
  • All done.



See it all in action in the video above.


 

2. Configuring Validators


Jira workflow validators verify that the information that the user inputs on a transition screen is valid.
This validation is done before the transition is performed: if the validation fails, the issue will not progress to the next status, and post functions will not be executed. With JMWE, you can build many rules using our point-and-click validators and even build your own.

 

Make a field mandatory during a transition but only for certain issue types.

Viewing time 4 min 43 sec  


For your convenience, the steps from the above video have been outlined below.

  

Make a field mandatory but only for certain issue types.

To make fields mandatory during a transition, you can use Jira's built-in Field Required Validator. Still, this Validator will not work if you want to make the field mandatory only for certain issue types, specific priorities, or other parameters. JMWE's Field Required Validator, however, supports conditional validation.

Here is how you can set up this conditional validation and simply click-your-way through scripting in JMWE's editor and tester: during the "Selected for Development" transition, enforce due date but only for 'bugs'.

  • Edit your workflow, go to the "Selected for Development" transition.
  • Go to the validator tab and "Add validator."
  • Select "Field Required Validator (JMWE app)", and add.
  • Choose "Due date" field, Enter the desired error message that will be displayed if the field is left empty.
  • Check the "Conditional validation" option to open JMWE's scripting editor and tester. This will enable you to specify that this validation should apply to bugs only.
  • Navigate to "Issue Fields" tab. Click to expand.


 

  • Select "Issue Type" field.
  • Click on help option in "Testing the field's value" called !!issue.issueType && issue.issueType.name == "Bug" to insert into the editor.


 

  • Add the Validator, publish the workflow, and check your work. 

See it all in action in the video above.



Read the documentation  |   Explore usage examples for JMWE Validators


 

3. Configuring Post Functions


Jira workflow post functions carry out rules after a transition is executed.
Post functions are the most common workflow extensions used for automating processes. Jira comes with several standard post functions, but JMWE ads many more. They will enable you to automate many rules using point-and-click configurations and even build your own.

 

Automatically create subtasks when a new story is created.
Close the story when all subtasks are closed.

Viewing time 12 min 8 sec  


For your convenience, the steps from the above video have been outlined below.

 

Automatically CREATE SUBTASKS when a new story is created, and CLOSE the story when all subtasks are closed. 

Part 1: Create one subtask   |   Part 2: Create multiple subtasks   |   Part 3: Close the story


Part 1 of 3:
When a new story is created, automatically create a subtask for that story.

  • Edit your workflow. Select the diagram view.
  • Choose the initial "create" transition. (The initial transition does not allow you to add conditions but supports validators and post functions).
  • Go to "Post Functions" and Add post function.
  • Select "Create issue(s) (JMWE app)" post function, press Add and configure it.
  • Leave Project as "Same as current project" - this is where the subtask will be created.
  • In Issue type, select "Sub-task".
  • In "Parent issue", leave "Current issue".
  • Optional: if you'd like to link the issue and the subtask, you can add a link in "Link to new issue" section.

 

  • You can specify the value of fields in the new issue, but in this case, let's just supply the summary: In the JMWE editor and tester, update "CLONE" to the summary of the subtask:
    This is the QA sub-task for {{issue.field.summary}}.

 

  • Optionally, you can set additional fields, as well as many other parameters. We'll skip these as we only need to create a new subtask.
  • Add a post-function, publish your draft, and check your work.

See it all in action in the video above.


 

Part 2 of 3:
Automatically create MULTIPLE subtasks - development subtask, QA sub-task, and documentation subtask - when a new story is created.

Instead of creating several "create issue" post functions described above, create multiple subtasks all in one post-function. It is easier to build and to maintain.

  • Edit your workflow. Select the diagram view.
  • Choose the initial "create" transition.
  • Go to Post Functions, and edit our "Create a new issue" post function.

 

  • To create multiple subtasks simultaneously, navigate to the "Multiple issue creation" section and select "Create multiple issues".
  • To specify an iterator, set up a list of values for new subtasks to be created. Type in: Development sub-task,QA sub-task,Documentation sub-task

  • Go up to the "Summary," insert the values of the iterator - {{it}} - which represents each value in the iterator section we set up in the previous step.

 

  • Click "update" to save the modified post-function, publish your draft, and check your work.

See it all in action in the video above.


 

Part 3 of 3:
Automatically CLOSE the story when all subtasks are closed.

  • Edit your workflow.
  • Select the "DONE" transition. When the DONE transition is triggered on the last subtask to be closed, then the parent story should be automatically closed.
  • Go to Post functions, and press "Add post function".
  • Select "Transition parent issue (JMWE app)" post-function, and Add.
  • In Transitions, click on "Transition picker..."
  • Select our workflow and the transition we want to trigger, which is "Done".
  • To add, click on "Use Transition ID", which is safer than using the Transition Name, in case the transition is renamed.

 

  • Press Add to add to the list, and Add the post function. This will ensure that when the DONE transition is triggered, it will also trigger the DONE transition on the parent task.

 

But that's not all! Note that we have not yet specified that the parent issue should only be closed if all the subtask are done. For that, let's add a condition.

  • Go to the "Conditions" tab and Add Condition.
  • Add a standard Jira condition called "Sub-Task Blocking Condition".
  • Specify the status in which the subtask should be in order for the DONE transition to be allowed on the story. Check "DONE" status. Press Add.

  • Publish your workflow and check your work.

See it all in action in the video above.



Read the documentation  |  Explore usage examples for JMWE Post Functions