Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,458,250
Community Members
 
Community Events
176
Community Groups

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

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.

 

2 answers

0 votes

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 Atlassian Team Feb 12, 2021

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

Like Curt Holley likes this

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). 

Like Bill Sheboy likes this

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.

Like Doug Levitt likes this
0 votes

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:

Screen Shot 2021-02-12 at 5.52.26 pm.png

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.

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events