Introducing Jira Expressions

And thanks a lot for your quick answer!

Thanks for the clarification, @mabd. Reducing to a map is just a matter of having operations on Maps that can create a new map from the current one with a new entry – this is something that could be totally possible in the future.

I’m thinking of something like this:

project.issues.reduce((bucket, i) => 
           bucket.with([i.sprint], bucket(i.sprint) + i.storyPoints, {})

Note that currently this is still just one REST API call to the JQL search endpoint with some simple post-processing afterwards, is it not?

Sounds swell!

I was thinking about how to solve the things I needed do using the expression call only.

Reading my own comments, I can understand why that was not clear to you. I was probably in too much haste! :-).

And, you are right, it is no big deal using the existing rest api, but for reasons I am not going to bother you with, it is sometimes a lot easier in our end to code a single call that presents the info we need, rather than having to postprocess. (And, it is also easier to move between languages / platforms).

Anyway: Will make sure to follow this part of the api.

Thanks!

1 Like

I really like this feature and think it’s awesome!

However, I was testing it today and somehow figured out that it’s not possible to only provide a project in the context data (i.e. leaving out an issue key). Is this intentional?
For example, if I use the following JSON as the HTTP body to evaluate an expression using the REST API, I receive an internal server error response:

{ “expression”: “project.key == ‘TEST’”, “context”: { “project”: { “key”: “TEST” } } }

This seems to be a quite simple expression to me and I’m wondering why it’s not working. Please correct me if I misunderstood something here…

1 Like

Whoa! This is definitely not intentional. It should be totally possible to provide just a project. Thanks for reporting this, @shesse! I will fix it as soon as possible.

Edit: fixed.

2 Likes

Hi,
Do you have any plan supporting for Jira Server about Jira expression?

Hi, @abe.kenichi,

This feature is available exclusively on Jira Cloud.

Indeed, it doesn’t make much sense on Jira Server.

The problem Jira expressions are trying to solve is that certain classes of extension points require fast and reliable computations (e.g. workflow or web conditions). With Jira expressions, such extension points can now be offered to third-party apps.

But that problem doesn’t exist on Jira Server, since you can already enhance Jira Server in whatever way you need with P2 plugins running on the same JVM.

Best regards
Krzysztof

1 Like

Hi @kkercz how would I go about counting the number of linked issues (of type “is blocked by”) that are not resolved. I have tried using issue.linkedIssues(“is blocked by”) but that doesn’t seem to work.

Thanks
Paul

Edit: Changed to ask the right person (sorry abe)

1 Like

Hi @kkercz ,

I thought that’s right.

But if it were available on Jira Server too, we could use the almost same implementation in add-ons for Jira Server and Cloud.

Thanks
Kenichi

Hi, @paul,

Unfortunately, getting linked issues is currently not available, but it is on our roadmap. I’ll keep you posted.

By the way, all available issue fields are listed in the documentation, in the Context variables section: https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-expression-eval-post

Best regards
Krzysztof

Hi @kkercz, thanks for that. I’d seen the documentation page but couldn’t find anything on linked issues.

I have a customer wanting a feature based on knowing the number of resolved linked issues, do you have any idea when this will be available, or do I just need to keep checking the documentation.

Thanks
Paul

I don’t have any dates yet, @paul. I’ll let you know if this becomes available. Alternatively, you can also create an issue in the ACJIRA project on ecosystem.atlassian.net and keep track of it.

1 Like

Hi @kkercz, thanks for this powerful feature!

When using expressions as web conditions is it possible (or planned) to use other entity properties for evaluating conditions similar to entity_property_contains_context ?

For example, in expressions docs there is this example:

['Bug', 'Task'].includes(issue.issueType.name)

but the list to search within is static. And with entity_property_contains_context I can create something like this:

{
  "condition": "entity_property_contains_context",
  "params": {
    "entity": "addon",
    "propertyKey": "issueTypes",
    "contextParameter": "issue.issueType.name"
  }
}

to make the issueTypes list dynamic. Can I use something like this in expressions too?

addon.issueTypes.includes(issue.issueType.name)

Kind regards,
Kirill

Hi, @k.menshov,

It is already possible to use entity properties in Jira expressions. See the Entity properties section in the documentation for more details.

Unfortunately, add-on properties are currently not available, but it is high on our roadmap. After we add it, the expression equivalent to your example will be :

addon.properties.issueTypes.includes(issue.issueType.name)

Meanwhile, perhaps you could store your configuration per project, in project properties?

project.properties.issueTypes.includes(issue.issueType.name)

The above is supported right now.

Best regards,
Krzysztof

1 Like

Thanks a lot, Krzysztof! I don’t think I will be able to use projects unfortunately (there’s too many of them, and I would have to create the same list for all of them), but it’s great to know that the addon entity is coming. Really looking forward to it, thanks again!

1 Like

Hi, @k.menshov,

App properties are now available in Jira expressions. You can access them through the app context variable, which is available:

So you can for example store an object containing a list of issue type names in a property named “your.app.key.property”:

{
   "issueTypeNames": ["Bug", "Task"]
}

And then write a condition that checks if the current issue type has a name included on the list:

app.properties['your.app.key.property'].issueTypeNames.includes(issue.issueType.name)

By the way, it’s probably better to refer to issue types by IDs, since names are configurable and can be changed at any time by Jira administrators. You can do issue.issueType.id to get the ID of an issue type.

Best regards,
Krzysztof

1 Like

Hi Krzysztof,
awesome news, thank you so much!

Are expressing available on server?

This feature is available exclusively on Jira Cloud.

Indeed, it doesn’t make much sense on Jira Server.

The problem Jira expressions are trying to solve is that certain classes of extension points require fast and reliable computations (e.g. workflow or web conditions). With Jira expressions, such extension points can now be offered to third-party apps.

But that problem doesn’t exist on Jira Server, since you can already enhance Jira Server in whatever way you need with P2 plugins running on the same JVM.

1 Like

Thanks for the clarification.