how to aggregate from related issue?

Question

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?

Bill Sheboy · Answer

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:

* 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.
* 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".

BEN FRIEDMAN · Answer

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.

Bill Sheboy · Answer

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?