Jira Expressions - But Why?

[#1]

If, like me and countless others, you're coming to Jira Cloud after years of working on Jira Server or Data Center. One of the first things you might run into is the fact that your favorite old plug-ins (fine, apps, add-ons, whatever Atlassian is calling them today) you used to use to create workflow validators or conditions don't work quite the way they used to.

I'm talking about stalwart standbys like Jira Workflow Toolbox, Jira Miscellaneous Workflow Extensions, Power Scripts and ScriptRunner.

So here's the deal: Atlassian changed things up. Now the only way that plug-ins can provide validators and conditions is via a tricky language called Jira Expressions.

It's syntax is kind of Javascripty (so says @Radhika Vijji _Innovalog_), but if you're like me, and don't know much Javascript (or run screaming from it), it can be a tough learning curve.  

Luckily some add-ons provide handy templates (Cloud Workflows, and Power Scripts) that you can then tweak, or include a helpful editors and testers (Cloud Workflows, JMWE and JWT). But inevitably, you're going to have to get in there and figure it out yourself.

Bottom line:

If you want to use custom workflow validators or conditions on Jira Cloud, you're going to have to learn Jira Expressions.

Examples:

At its simplest, you might need to do something like "Only the Reporter should be able to close a ticket". So that expression would be:

user == issue.reporter

(That's from JMWE's Use Cases.)

Or maybe you need the old "Check for unresolved sub-tasks" condition before you let a user resolve a parent:

issue.subtasks.filter(s => !(s.resolution != null)).length == 0

(That's from JWT's Use Case Library.)

You can even check links:

issue.links
.filter(link => link.type.inward == "is blocked by" ||
  link.type.inward == "is mitigated by")
.length > 0

Even more examples

• Cloud Workflows -  Using Jira Expressions
• Cloud Workflows - Cookbook (Jodocus)
• JMWE - Use Cases
• JMWE - Configuring Workflow Conditions for Jira Cloud (video)
• JWT - Use Case Library
• ScriptRunner - Workflow Extensions
• Jodocus Blog - Various Jira Expression of the Week articles

There's a lot you can do with Jira Expressions, and you're going to "get" to learn Boolean logic which is... some kind of fun. But for sure, the best way to learn is by doing. Check those links above, as it's very likely there's an existing "recipe" that can be adapted to your use.

But if you're really stuck, post here in the forums (tags: cloud, jira-cloud, jira-expressions), where some of us apparently have nothing better to do but than to debug others' Jira Expression issue. (Or in some cases like @David Fischer maybe they get paid for it. :-)

[David Fischer]

Nice summary, @Darryl Lee !

David

P.S. I actually don't get paid for helping, but as the creator of JMWE and JMCF, I do care about users making the most of the apps...

[Darryl Lee]

@David Fischer yes, I meant that tongue-in-cheek since I know JMWE is your baby. :-}

[Matt Doar]

Thanks for pointing this out. 

[Max Foerster - K15t]

Very cool and comprehensive write-up, @Darryl Lee! And I feel you, you will have to learn it because there's no way around it. I struggle with it myself, but luckily there is help. 😁

[Jack Brickey]

Thangs for sharing. One thing to note about Cloud here - you can install the Workflow plugin and achieve a lot of capabilities in your workflow. App key - com.atlassian.jira.plugin.system.workflow

[Juhaina Almama]

Very nice, thanks for sharing

[Darryl Lee]

So... this is a Necropost, but recently a consultant spoke about a client wanting to drop JMWE and JSU to save costs, which unfortunately is forcing them into the position of trying to use Automation to implement what REALLY should be a Condition: Prevent transition if all linked issues are not closed.

With Automation, all you can do is REVERT the transition and add a scolding comment, which is a horrible User Experience, because they will have no warning about what they did.

So then, I was inspired to look at how much using Jira Expressions will cost you. To ballpark it I chose 100 users, annual pricing as of Jan 29, 2024:

• Extensions for Jira Workflow - Conditions & Validators FREE: $0
• Cloud Workflows: $500
• JSU Automation Suite for Jira Workflows: $1,190
• Jira Workflow Toolbox: $1,250
• Jira Misc Workflow Extensions (JMWE): $1,500
• Power Scripts - Jira Workflow Automation: $1,550
• ScriptRunner for Jira: $2,500

Now as I mentioned in my original article, many of these tools offer additional tools that will help you generate Jira Expressions, or offer various "canned" validators/conditions/post-functions that you can use. And something like ScriptRunner is going to offer a LOT more functionality beyond workflow customization.

I do not know much about that FREE solution. It seems pretty new. @Krzysztof Bogdan did you want to say anything about it? Can folks expect it to stick around, be supported, etc?

[Krzysztof Bogdan]

Hi  there @Darryl Lee 

It is interesting topic. I can put my 2 cents from app developer perspective.
Before I do that, lets say it at loud, it is FREE (https://youtu.be/4p8vqoIVESc?feature=shared&t=9)!
Ok.Now when we are it proper mindset. Let's go.

"Extensions for Jira Workflow - Conditions & Validators FREE" (EFJW for short) - this is my side project.
I have created External Share for Jira & External Share for Confluence apps and a bunch of other apps.
I think it gives me some credibility. EFJW is not going away. It is here to stay. Now it is dead simple and a lot of stuff is missing.
There is some paperwork to be done,
like Cloud Fortified badge.
More docs, more examples.
Expression validator is missing,
failed expression log is missing and
postfunction custom logic is missing.
All of which I plan to cover.
But event without it is still very useful. I think it covers like 50% of use cases.
With custom post-function logic it will cover like 90%.
For those who have problem with writing jira expression, ChatGTP or similar - can help,
it is far from perfect but with some tweaks it can get job done.
Right now I am working on custom post functions and I think this is going to be a game changer.
WASM postfunctions, written in C, C++, Rust, Go, .Net, C#, TypeScript or other language
that can be deployed with Bitbucket pipeline or GitHub or curl or whatever.
Using WASM should be very efficient and cheap to run.
I would love to keep infrastructure cost low.
I mostly finished postfunction handling.
Queues, WASM runner, Sandbox (Network, CPU, Memory and storage limits) all hard stuff is done.
Once I will achieve some level of maturity, I will probably start charging for it (CPU & Memory is not free 🤷‍♂️) yet I want to keep it affordable.
Currently, I am working on UI and documentation for custom WASM postfunctions.
Over all, I think there is a niche for less complex app and cheaper app.
This is where I am aiming with EFJW.
What is also interesting, I think there are actually few things that could disrupt the Jira workflow "market" but sorry I can't share it yet :).

It is beautiful:

and the result, you can run custom code: