Is it possible to use functions such as asJsonObject() inside iteration?
I couldn't make this:
{
"fields": {
"fixVersions": {{#project.versions}}{{#not(archived)}}{{#not(released)}{{asJsonObject("id")}}{{/}}{{/}}{{/}}
}
}
So I had to do this:
{
"fields": {
"fixVersions": [
{{#project.versions}}{{#not(archived)}}{{#not(released)}}
{
"id": "{{id}}"
}{{^last}},{{/}}
{{/}}{{/}}{{/}}
]
}
}
My guess is asJsonObject() like any other method has to be accessed from object variable, but how to get it from inside iteration? I can get only its properties like name or id.
My another question is how to filter-out list by regex expression? From above example if I add {{#if(name.match("^\d+\.\d+\.\d+$"))}} I get nothing. I tried many variations and did not succeed even with {{#if(not(name.match("^\d+\.\d+\.\d+\.$").isEmpty))}}. I tried simple regular expressions like ".*" and they cannot match anything inside iteration. Is it ever possible?
Hi @Aleksey Midenkov -- Welcome to the Atlassian Community!
You are correct that the asJsonObject() function must have the context of some object to work: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-json-functions/#asJsonObject-keyName-
And...once the rule is inside of an iterator, only the attributes from that scope are available. And so asJsonObject() could not work in your scenario. If there was an object with lower level attributes, I expect it would work. (For example, iterating over a {{lookupIssues}}, and then using asJsonObject() on a list field like fixVersions or watchers.)
Regarding your question on the regular expression, a few things to consider:
And for some context, what is an example version name to which you are trying to match?
Finally, I know your rule is trying to reference the project smart value. Is the trigger for your rule for a project? Otherwise I do not believe that one is available with all version data (from an issue). Instead one would need to call the REST API functions with a webrequest to get all versions for a project.
Kind regards,
Bill
Hi @Bill Sheboy , thanks for the quick reply!
And...once the rule is inside of an iterator, only the attributes from that scope are available. And so asJsonObject() could not work in your scenario.
Hmm, looks like big omission... Some access to iteration subject should be possible. Some languages use special syntax for that (like "$_" or "it"). But since we access all the properties without any accessor syntax it is meant we have object context inside iteration. Using asJsonObject() without dot-operator in such context seems to be natural. If properties accessed, why methods cannot be accessed? This looks like a bug (in terms of design at least).
Although the match() use of regex is based on the Java Pattern class, we have no documentation of what does/does not work. I recommend testing outside of an iterator first with a simple expression to confirm supported expressions.
And how to test it most easily? Switching back and forth between issue and automation log, pushing publish, etc. One try requires a lot of clicks!
But even the simplest ".*" (with grouping or not) seems to not work inside the iteration, so what's the point to test outside iteration? I thought converting to boolean is done with isEmpty(), but I tried your suggestion with exitst() as well. Nothing works! Actually there is not enough documentation on that topic.
And for some context, what is an example version name to which you are trying to match?
10.4.1
Is the trigger for your rule for a project? Otherwise I do not believe that one is available with all version data (from an issue)
Issue context. No, it is accessible from issue. Of course I tested that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
FYI, I am just another customer trying to offer suggestions and share what I know about the behavior of rule syntax, not the design decisions the Atlassian team made.
And one reason to test regular expressions (in automation rules) using logging with and without an iterator wrapper is isolation to determine symptom causes.
As you seem to have concerns / feedback about the design, I suggest working with your Jira site admin to contact Atlassian Support here: https://support.atlassian.com/contact/#/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.