Can we concatenate values from a Select List across all issues and set a similar value in the Epic?

[Doug Levitt]

I have a set of issues of type: Story, Bug, Task, Spike.

Each issue is associated with a Custom Field called ThisTeam which is a Select List (single choice).  The list of possible values is: TeamA, TeamB, TeamC, TeamD, TeamE.

Each epic is associated with a Custom Field called WhichTeams which is a Select List (multiple choices).  The list of possible values is: TeamA, TeamB, TeamC, TeamD, TeamE.

I want a rule (that runs nightly) that will scan through all EPICs, setting the Custom Field WhichTeams based upon the ThisTeam value for those issues associated with that the EPIC.

As an example #1:

- Assume EPIC-1 includes:

• Story-1 (where ThisTeam = TeamA)
• Bug-2 (where ThisTeam = TeamB)
• Task-3 (where ThisTeam=TeamD)
• Spike-4 (where ThisTeam = TeamA)

- The automation would set WhichTeams in EPIC-1 to: TeamA, TeamB, TeamD

As an example #2:

- Later, assume EPIC-1 now includes:

• Story-1 (where ThisTeam = TeamA)
• Bug-2 (where ThisTeam = TeamB)
• Spike-4 (where ThisTeam = TeamA)
• Story-5  (where ThisTeam = TeamE) 
• Note: Task-3 was moved to a different EPIC

- The automation would set WhichTeams in EPIC-1 to: TeamA, TeamB, TeamE

I was thinking of doing this as a scheduled job.  But if it could be done at the time the event fires that's fine as well.  I have ~30 Jira Projects and ~ 20K tickets using this configuration.

[Bill Sheboy]

Hi @Doug Levitt 

Rather than using a scheduled rule, have you considered using a rule triggered on issue changes for ThisTeam to update the parent epic's WhichTeams?

Adding a new team (not yet in WhichTeams) is easy, and the trick is removing the prior values without clearing the list.  (which is what you would do for a scheduled trigger rule).

I was able to do the add/remove with components using an additional custom field for working space and string/list functions of automation rules.  Please see here for details:

https://community.atlassian.com/t5/Jira-Software-questions/Re-Re-how-to-delete-specific-issue-components-using-aut/qaq-p/1540660/comment-id/109023#M109023

Best regards,

Bill

[wwalser]

Just wanted to say that the linked rule is pretty clever. Nicely done.

[Doug Levitt]

Thanks @BIL - I love the suggestion.  However, I need to be careful about the complexity of the automations I implement.  As ultimately, someone needs to support these things.  And I am afraid I will get push back on the complexity of the solution (which is very clever). 

[Bill Sheboy]

Indeed!  Something I learned over the years is when another developer calls you to their desk to see some "cool and clever code", reach over their shoulder and press "delete"  :^)  Such code is often brittle and usually unmaintainable...especially once you forget how you got it to work in the first place.  (e.g. Base-36 numbering systems to solve Y2K with numbers and letters.)

That being clarified, my approach is a work-around for the absence of a "delete item from list" action.  Automation rules are very helpful, *and* they provide a narrow scope, little language.  As the automation engine evolves the helpful and missing features will no doubt be added.

[Michał]

hey Bill,

thanks for you help. It's to complex for me due to lack of sorting list and getting version handler. I decided to do this automation with script outside Jira.

thank for your help and KUDO!

Michal

[wwalser]

This is a cool use case but I'm not sure that it's possible at the moment. I'll take through a few considerations but and leave the implementation to the reader.

The decision to do this nightly or on edit should be a user experience question — do the users of this Jira instance care that issues can be out of date until their nightly "cleanup"? However, given your instance size, you may create performance problems if every issue edit is triggering an automation run. Jira Premium raises the rule execution limit so perhaps this isn't a problem. Rules running and rarely doing anything shouldn't be a problem so judicious use of conditions is advisable.

Now, actually implementing this…

I don't think the on edit version is possible. The key problem is when issues are moved between epics. Automation can trigger on issue edits, but it only knows the new state of the issue, not what it was changed from. This means that editing the old epic to remove values from WhichTeam sounds… hard.

Doing this daily is still difficult but I think it's possible. You need two rules. One which clears the "Which teams" field in every epic and another which adds them back based on issues in the epic. This ensures the the lists don't just get added but, but are correctly subtracted from when ThisTeam is changed or an issue moves between epics. The second rule is slightly more complex and looks something like this:

I've used "Affects versions" as a stand in for your "Which teams" field as I didn't want to create custom fields in my instance.

You'll want to be sure that the automation that clears the which team value completes before the second rule runs. Unfortunately I don't have good advice here besides scheduling them with some amount of time between them. You'll have to monitor the epic field clearing automation to know how much time. It should be fairly fast.

The number of executions this is going to cause is still a concern for this version for me. If you're going to do it, maybe create the rule tied to a single project or two for a few days and check the performance insights screen after it runs to be sure it's not a problem.

[Doug Levitt]

Thanks @wwalser I appreciate the suggestion.  I had a question.  Say I have two EPICs:

- Epic-1

- Epic-2

Say, Epic-1 contains a issue, Story-1.

If I move Story-1 from Epic-1 to Epic-2, does that itself trigger an "event" that is caught by Automation for Jira?  That is, does Epic-1 get notified that Story-1 has been "moved out"?  Likewise, does Epic-2 get notified that Story-1 has been "moved in"?

Thanks,

Doug