Combining values from a bunch of Jira Items with a multiple select custom field.

Following up on my earlier answer, @Dick: depending on why the Movement needs the combined value, there may be a way to skip the write-back entirely. If you're open to using an app from the Atlassian Marketplace, JXL for Jira can help with this. Specifically, its formula columns allow you to compute the union of the children's Domain values live on each Movement row:

const values = this.hierarchy.children
  .flatMap(c => c.domain ?? [])
  .map(o => o.value);
return [...new Set(values)].join(", ");

It runs on Data Center, and the Movement > Initiative relationship works through the same Parent Link your hierarchy already uses. The computed value updates as Initiatives change and comes along in exports. The caveat: it's a display column, so if other JQL or boards must read the real Domain field on the Movement, your REST route is still the right call.

Disclosure: I work for the team that builds JXL.

All the best,

Ivan

Hi @Ivan Manolov _Appfire_,
A couple of things I would like to mention:

• First: please say hello to Hannes from me :) We did some debugging on JXL together.
• I need the value stored on the movement as I use it to gather Jira Items for displaying purposes, so I need to get the REST route working. 
• jql='parent link' = {{triggerIssue.parent link}} returns an error "URL failed to Parse" in the Send web request, with a remark that I should use: {{value.urlEncode}} for the smart value. This sadly doesn't port to the {{ }} in the jql, neither when I first declare the MovementKey variable as MovementKey = {{triggerIssue.parent link}} and then use {{MovementKey.urlEncode}} in the jql. 
  
• The single quotes around parent link are a god-sent to me. Thank you for that.
  The Atlassian suggested usage double quotes on the "how to get the url-friendly version using the url of an issue search action" didn't work. 
  

So the story to nailing this continues. 

Kind regards,
Dick

Tiny result
Using:
<our instance>/REST/API/3/search?jql=%27parent%20link%27%20%3D%20{{MovementKey}}

gives me a Response 200 and a 

Request GET with the complete path

The {{webhookResponse.body}} however contains a lot of stuff that isn't related to specific Jira Items. Even this came along: 

{{webhookResponse.body}}

{\u0022product\u0022:\u0022jira\u0022,\u0022destination\u0022:\u0022/REST/API/3/search?jql\u005Cu003d%27parent%20link%27%20%3D%20DIR-1\u0022,\u0022forgotLoginDetailsUrl\u0022:\u0022/secure/ForgotLoginDetails.jspa\u0022,\u0022signupUrl\u0022:\u0022/secure/Signup!default.jspa\u0022,\u0022permissionsViolationContext\u0022:{\u0022showLoginForm\u0022:true,\u0022warningMessages\u0022:[\u0022\u005Cu0027starm001\u005Cu0027 does not have permission to access this page.\u0022,\u0022If you think you shouldn\u005Cu0027t get this message, please contact your Jira administrators.

DIR-1 is indeed the MovementKey. But I'm admin of this Jira instance, and all the projects that are in scope of the Automation that runs the Webrequest. I'm a bit baffled by the permissions violation. 

Here's hoping :)
Dick

Hi @Dick,

I'll pass the greetings along :)

Your 200-with-login-page result can be caused by two things, fixable in the web request config:

1. Wrong API version for Data Center. /rest/api/3/ only exists on Cloud. On DC use lowercase /rest/api/2/search?... (or /rest/api/latest/). Your uppercase /REST/API/3/ path doesn't hit the REST servlet at all, which is why Jira answered with a regular web page instead of JSON.

2. The request is anonymous. A web request doesn't inherit the automation actor's session, so Jira treated the call as not-logged-in ('starm001' and the login form in the body are the giveaways). Add two headers to the action: Authorization: Bearer <token> using a Personal Access Token (create one under the service account's profile, Personal Access Tokens, available since Jira 8.14), and Accept: application/json.

Before wiring this back into the rule, I'd prove the calls outside automation with curl (or Postman: Authorization tab, type Bearer Token). That separates Jira-side URL/auth problems from smart value problems:

curl -s -H "Authorization: Bearer <PAT>" -H "Accept: application/json" \
  "https://<your-instance>/rest/api/2/search?jql=%27parent%20link%27%20%3D%20DIR-1&fields=customfield_10301"

If that returns the children with their Domain values, the same URL and headers dropped into the Send web request action will too. The PUT can be tested the same way (against a test Movement first, since it overwrites the Domain field):

curl -s -X PUT -H "Authorization: Bearer <PAT>" -H "Content-Type: application/json" \
  -d '{"fields":{"customfield_10301":[{"value":"A"},{"value":"B"}]}}' \
  "https://<your-instance>/rest/api/2/issue/DIR-1"

Once both work standalone, in the rule log {{webhookResponse.body.issues.key}} to confirm the response parses, then try building the union with {{webhookResponse.body.issues.fields.customfield_10301.value.flatten.distinct}} before the PUT step.

On the urlEncode parse error: your manual percent-encoding is a perfectly fine permanent fix, no need to fight the smart value there.

Cheers,

Ivan

Hi Ivan,

It was your point 1: The call to the api had flaws. 

/rest/api/2/search?jql=%27parent%20link%27%20%3D%20{{MovementKey}}

gives me the initiatives now properly using the log action with this message:

Looked up issues = [ {{webhookResponse.body.issues.key}} ]

I already added the Authorization and Bearer <PersonalAccessToken> combination in the managed secret keys section of Jira, which meant I could rule-out your second suggestion. 

Thank you kindly for your support in this matter. 
Dick

A silver lining, but in the end falling flat on my face: 

• The correct issues are found using the webrequest.
• The correct domains are found inside two arrays when polling the domain customField of these issues.
• Then flatten in all it's combinations came along and wiped the content of the domain customField arrays.
• Even distinct isn't looking across a display's border. Yes, I know that a select list has distinct values. 

Why isn't flatten working for me?

OpenJDK-21 perhaps?

Going for the How to sum story custom filed values to an epic? solution using web request to the REST API mentioned in the comments by Bill. 

These pictures contain the test Gor asked. The parentheses after flatten are not making a difference. 

I'm now suspecting our underlying Java (openJDK-21). 

Kind regards,
Dick

Ah okay. Apologies, I missed the tags

Hi @Dick

Thanks for the reply.

The interesting part of your audit log is that the lookup itself works correctly, while the Domain expression is already empty before distinct really becomes relevant.
I would therefore go one level simpler and inspect how Automation for DC is exposing this particular multi-select field.
Could you try logging these directly, without flatten or distinct? {{triggerIssue.customfield_10301}}
{{triggerIssue.customfield_10301.value}}

and, after the Lookup

{{lookupIssues.customfield_10301}}
{{lookupIssues.customfield_10301.value}}
I'd use the field ID rather than Domain for this test, just to remove field-name resolution from the equation.

Regards,
Gor

wee change to the Edit action: the update function will only add value but it will never remove values that are removed from the child tasks.

Use this JSON instead