Jira automation and #lookup behaviour / question

[Dave Furlani]

We have ChangeManagement tickets that go through peer reviews and CAB on their way to a release. The CM ticket has links to the Epics included in the release. My A4J rule is triggered when a CM transitions to CAB Review status. 

The first lookup action steps has the following JQL: 

key in linkedIssues({{triggerIssue.key}}, "is caused by")

Which I then use to populate a variable releasedEpics

{{#lookupIssues}}{{key}}{{^last}}, {{/}}{{/}}

Further on I have another lookup action step

parent in ({{releasedEpics}}) AND project not in (ALF, CM, SD, CDD) AND category = "System Layer" AND statusCategory = Done

This gives me all the tasks the developers worked on in each of the epics linked to the CM for the release.

From that 2nd lookup I want to extract the sprints that the tickets were in. Ideally, I'd like to see which delivery team (set in the Delivery Stream field), required the most sprints to deliver their dev tasks.

I have tried a few things with MAX() to no avail (no data at all)

I also tried to get fancy with this one and got no data either

{{#lookupIssues.customfield_10109.value}}{{sprint.distinct.size}}{{/}}

The following at least gives me a total count of sprints across all teams (e.g. 27) and a list of all the sprints or the unique groups of sprints the issues had. In the later I can see where some tasks took multiple sprints to resolve, but because this result is an array, there are individual sprints mentioned multiple times in different elements of the array. Example as follows:

[MH Sprint 77 ], [MH Sprint 78], [MH Sprint 79], [MH Sprint 80], [MH Sprint 77, MH Sprint 78], [MH Sprint 78, MH Sprint 79, MH Sprint 80], [MH Sprint 79, MH Sprint 80]

Because .size counts the elements in the array, this produces a result of 7.

I could read through that to find the unique sprints for each team, but the result I would like to see is number of individual sprints, which is 4 (sprints 77, 78, 79, and 80).

{{lookupIssues.sprint.distinct.size}}  
{{lookupIssues.sprint.distinct.name}} 

What I'd really, really like to see is that of all 95 tasks in the epics delivered, team Bowie took 4 sprints to deliver their tasks, team Zappa took 2 sprints, Team Grohl took 1 sprint, etc.

Does any clever individual want to suggest how I might achieve either of those desired outcomes?

[Bill Sheboy]

Hi @Dave Furlani 

My suggestion on this unique use case would be: divide and conquer.  Pick one of those measures, and once it works, the methods you develop may help to solve the others.  

For example, if you take your count of sprints by team...(Disclaimer: I am describing this and not writing this based on creating a test rule I ran :^)

• Rather than creating a bunch of variables, you could use a lookup table for temp storage.  Lets call that tblSprintCounts.
• And for each team, create a row which stores the lookup issues for the tasks filtered by the team (Delivery Stream), and...
• One technique is to just store the sprints, using nested iterators and conditionals:

{{#lookupIssues}}{{#if(equals("Delivery Stream","A-Team"))}}{{#Sprint}}{{name}}{{^last}},{{/}}{{/}}{{/}}{{/}}

• Now that you have a table with a list of sprints for each team, the count per team would be {{tblSprintCounts.get("A-Team").split(",").distinct.size|0}}

Perhaps try that, writing the results to the audit log as you go, and see what helps.

Kind regards,
Bill

[Dave Furlani]

Your knowledge amazes me @Bill Sheboy

That all seems to work, except for the .get(). I experimented with a few ideas there. The Atlassian doco suggests it only takes an integer for the position of the array element, and I know very little about the way .get works, so it wasn't a particularly educated guess. To help me look up things in future are those commands java or python based?

For a laugh, I did a few experiments with .find() too, but no luck there either.

That's not to say .get or .find aren't the answer, I am very likely not using them correctly. Do either have a special way to handle wildcards?

Using your suggestion I tried create a variable for each team and storing the sprints as you suggest, then just use that variable with the .split(",").distinct.size. Sadly, some issues have gone back and forth between teams, so the distinct count ends up being incorrect in some cases, so can't be trusted. To that end I tried this for each team, which gives me the number I'm expecting:

{{#lookupIssues}}{{#if(equals(customfield_10109.value,"TeamX"))}}{{#Sprint}}{{#if(name.startsWith("TeamX"))}}{{name}},{{/}}{{/}}{{/}}{{/}}

While this gives me the correct number of sprints for work of one team, if a team sat on a task for a sprint, then handed it to another team, the total will be out.

Progress over perfection.

Getting that .get() filter for the team name before the distinct size will be the next trick, and once that works, storing the sprints can go into a single var as you suggest above. Then it'll be perfect

[Bill Sheboy]

Progress; well done! 

I suspect my original suggestion for the table, row data expression had a problem and that is why get() failed to work.  You could validate that by writing the table to the log and see what it contains.

By the way, get() got overloaded when implemented for the new Lookup Tables feature:

• For a generic list, get() only accepts a 0-based, numeric parameter
• For a lookup table, get() originally only accepted a text string.  This was recently improved so the function will accept text, numbers, and will use the default attribute for objects.  (e.g., when get(someJiraIssueObject) is used, the issue key is the parameter passed.

[Dave Furlani]

That link helped explain .get(), and also how to build a lookup table (I was just doing a normal lookup and a var with {{#lookup}} for each team), so thanks again @Bill Sheboy.

Sadly though I'm getting no result from .keys, .entries and .size.  Not sure where I've gone wrong there, but as I said before, I have the less elegant version giving results for now so I have breathing room to play around with it later (It's temporary, unless it works)

Cheers