​This solution was provided by Sait Kiremit. It has earned a $50 donation to FIRST by Blended Perspectives. 

Challenge:

​In Jira Service Desk, a customer request type needs either a custom field or an attachment. For example, if the user does not enter the value in the custom field called "Request Participants" on the request screen, the user will be warned of a required attachment. If the user enters the "Request Participants" field, this warning will disappear when creating a request.

Jira Misc Workflow Extensions (JMWE) comes with over 40 point-and-click Jira workflow post-functions, conditions, and validators (here is the PDF cheatsheet of all extensions). Configuring these no-code extensions will often be enough to automate most of your workflows, especially the essential ones. 

However, what sets JMWE apart from all the "code-free" Jira workflow apps is the extensibility of all these extensions with simplified scripting. Even if you are a Groovy novice, you can use code snippets right inside all extensions for more sophisticated workflows. Our user-friendly editor and tester will assist with scripting - often, you'll be able to click your way through "coding".

Additionally, advanced Groovy users can do super-powerful workflow automation with JMWE. Take a look at this use case that Carl E. Allen just shared on the Atlassian Community site. 

This use case is for Jira Data Center and Jira Server. JMWE is also available in Jira Cloud, but it uses (optional) Nunjucks and Jira expressions to extend your workflows. 

It's smart to make Jira workflows as simple and flexible as possible. I like to give users multiple ways to transition issues between statuses and even let them skip statuses when needed. But sometimes skipping a status is undesirable or creates a compliance problem. Consider an approval status for example. You'd certainly fail an audit if work was started on an issue or an issue was completed before it was approved. Luckily, Innovalog's Jira Misc Workflow Extensions (JMWE) app has a validator to prevent it.

Use Case: Before work is started or an issue reaches its final workflow status, make sure it passes through the "Approval" status.

Bonus: Conditional Approval, to allow selected issues to bypass the "Approval" status.

You can also read/download this PDF document.

Customers who run older Jira instances might still have the free version of JSU. Now it is no longer free and requires a license to operate, which you'd need upon upgrading to the latest Jira instance. Recently, JSU announced price increases, up to three-fold, and as of November 4, 2019, JMWE and JSU are priced the same*. However, some customers either consider purchasing a single workflow automation tool or want to replace JSU with JMWE. In most cases, thanks to many point-and-click extensions in JMWE, as well as extensibility via simple yet powerful scripting, it can be done easily.  

If you set up a Jira Service Desk email address, when a customer submits a support request by email, it is captured and becomes a new ticket (issue). These are added to your queues so that your team can focus on all your customer requests in one place. Sometimes, however, issues might not be relevant and you and you might consider it SPAM. 

In the past, the issue view in Jira Cloud has displayed a transition tab, the feature some have come to rely on for activity information essential to their business processes. For example, managers and auditors could have a clear understanding of what actions have been taken on issues, that the right people work on or approve them, and that the processes always follow the appropriate workflow.

Since then, on the new issue view this tab is no longer available and only older Jira Cloud instances still show this option. However...

JMWE's new Transitions tab option gives users a precise view of transitions and if you are using this app, it is enabled by default. However, some older Jira Cloud instances might show a second "old view" Transitions tab. This is a legacy tab originally provided by Jira Suite Utilities (JSU).

To avoid confusing your users with two similar options, you might want to disable one of the tabs. But which one should you keep?

As a Jira administrator, I frequently see this problem: child issues are closed but nobody remembered to close the parent issue. Users have already moved on to the next thing and the parent issue sits in its incorrect status forever. Or maybe it's the opposite: the Epic is closed, but its Stories, Bugs, and Tasks were forgotten.

When issue status does not reflect reality, reporting is a nightmare. All completed or unneeded issues should be transitioned to their final status. Why not take this step off your user's "to do" list and automate it? It's easy to automatically transition issues with Innovalog's Jira Misc Workflow Extensions (JMWE) app.

Use Case: When all child issues are closed, automatically transition the parent so users don't need to do it manually. Example: When all Sub-tasks are transitioned to the "Closed" status, automatically transition the Task issue to the "Closed" status.

 
You can also read/download this PDF document.

Viewing time under 2 minutes | for Jira Misc Custom Fields 

Here, we use the Transition Caller custom field type to display the person who resolved an issue (as an example). Using this custom field type, you can display, search for and report on the author of any transition based on actual transition IDs or between one, many, or all statuses. We cover the latter one in the above video.

In Jira, you can customize your Board cards to help users focus on important details. You can filter according to your preferences, change colors, and display up to three fields. Adding a field you already have available in Jira is not difficult. However, you often want to show information not stored in an issue field, or pull it from a related issue.