Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

how to aggregate from related issue?

Hi, the use case i have is:

there is an ORIGIN issue and some other issues (A,B,C) that are logically related (not linked) to ORIGIN.

i would like to run an automation that sets values A,B,C in ORIGIN.

been battling this for a while.

any idea?

1 answer

Hi @Ben 

What do you mean by "logically related" for these issues?  Can you write a JQL statement to return those issues, based upon the triggering issue and some criteria?

If so, you should be able to use a JQL statement with a trigger or branch to get the issues needed for the update.

Please consider posting an image of the rule you are trying.  That may provide more context for the community to offer ideas.  Thanks!

Best regards,

Bill

the issue where summary ~ "origin" should collect the value for selectlist from each issue in the scheduled query. i can only get to have an update from 1 issue and not all. 

Thanks for the information, Ben!  I am still trying to wrap my head around what problem you are trying to solve, so I'll start with your posted rule.

  • When a scheduled trigger with JQL runs, it could find from 0 to up to the limit for a rule (100 issues).  When the count is 0, the rule doesn't fire.  Let's say the return count is X.
  • For each issue from the scheduled trigger, it attempts to process the components in the rule.  (There is an exception around conditional tests, and let's ignore that for now.)
  • You then have a branch on JQL, which would attempt to process each issue found in the branch (again 0 up to 100 issues), with an edit action in your case. Each edit is processed asynchronously with no defined order of execution.  Let's say the return count for the branch is Y.
  • The result: your branch processes X*Y times, potentially writing to the same issues multiple times, and walking-over the earlier results.

Okay, back to your use case.  It appears you want to gather up some values from issues based on some conditions, and perhaps store that as comma-separated values (CSV) in a field in the trigger issue.  Correct?

That is correct. The issues i gather from are in the scheduled query. The issue i aggregate to, is in the jql.

The issue also occurs with a simple text field. Lets call it 'country'. So the issue in the jql should contain all the countries from the issues that are under the scheduled query.

Lets say the scheduled query has issues A,B under it, and the jql references to issue C.

 

What i expect:

Query starts, for issue B, goes to issue C, updates C's country with B's country value. Issue C is now re-fetched. Now query runs for issue A and should update issue C's country with A's country. (Note that the rule edits with *add* in the edit action).

So eventually C's country will contain A+B's country.

However, in the end, C's country contains only A or B.

Thanks for clarifying! And yes, that is what I would expect to happen...

Branch execution of more than one issue spins off separate processing for each issue, independent of the rule.  There is no guarantee of the order of processing or of when they will complete.  So a re-fetch inside a branch doesn't necessarily help.

Your "country" field sounds like it is a custom field.  So unfortunately you cannot use something like Lookup Issues to quickly solve this.  (Lookup Issues only returns a small subset of the issues fields currently.)

To keep your issue "C" updated, I think you have two options:

  1. Use a rule triggered on changes to any of your "logically related" issues' Country field.  When that happens, use the changeLog from/to values to update the "C" issue.
  2. Still use a scheduled trigger, and use a web request to call the REST API with your JQL for issues.  That will return JSON that you can use to pull out the values using a regular expression, and update the field in issue "C".

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you