Listener: copy a field on one issue to another field on the same issue on every issue update

[Christopher Kelley]

We have a series of issues which have a custom JMCF fields which copy a user value from parent customer single-user fields. For instance, copying a user selection from the Initiative to the custom field in the child Workstream in portfolio, and so forth. One can assume:

1. User_1 from parent (a standard custom user picker field in JIRA) is copied to field User_1_A on the given issue (a JMCF single user scripted field successfully using groovy to pull and insert the value.
2. The data type fro both the source and destination is identical - DelegatingApplicationUser).
3. The field above builds and populates correctly.

Now, we want the field User_1_A on the above child issue to copy to User_1 on the same child issue. In practice, this means one needs to set User_1 on the parent, and then it auto-cascades to all children (reducing data entry overhead).

We have spent a huge number of hours trying to get this to work under Automation for JIRA, PowerScripts for JIRA, and ScriptRunner for JIRA to no avail. Our admin is fairly new to this, but it can’t be that hard to have a listener to set these fields to be the same at each issue update.

I have to think this is very obvious. Any pointers for this type of listener for any of the above three listener engines?

[David Fischer]

I believe the problem is that there is a misunderstanding: JMCF calculated fields are, well... calculated. This means that their value is not stored but calculated on the fly when the issue is displayed. This also means that you cannot set their value.

Said differently, your calculated field doesn't copy the value from another issue but shows it.

That said, it's likely you can achieve what you need but I'm not sure I quite understand what it is. Could you describe it again with an example?

[Christopher Kelley]

Hi David,

We have a standard structure to Plans being tracked in Advanced Roadmaps:

• Initiative
  • Workstream
    • Epic / Requirement
      • Story / Issue
        • Sub-task

There are single user select fields on each which cover the following data points:

• Initiative Associate Engineer
• Initiative Check Engineer
• Initiative Lead Engineer
• Initiative Release Engineer
• Initiative Specialty Engineer

Each of the fields are set at the Initiative level. However, their value is the same in reality for the whole tree.

We want to enter the data to these fields at Initiative and then, as a watcher (not a trigger in workflow), have each child in this tree update these fields at the child against the value stored at the Initiative level. For JMCF using Groovy, this is wildly simple to do if just cloning that data to a custom JMCF field in each child. 

The end goal is to just sync the above five fields.

Here is the Groovy code in JMCF for one of the fields, which executes flawlessly:

if(issue.get("customfield_10605")=='Workstream'){

//Let's copy the parent value 
return issue.portfolioParent."customfield_11000"

}

else if(issue.get("customfield_10605")=='Epic'){

//Let's copy the parent value 
return issue.portfolioParent."customfield_11000"

}

else if(issue.get("customfield_10605")=='Story'){

//Let's copy the parent value 
return issue.epic."customfield_11000"

}

else if(issue.get("customfield_10605")=='Bug'){

//Let's copy the parent value 
return issue.epic."customfield_11000"

}

else if(issue.get("customfield_10605")=='Material Substitution'){

//Let's copy the parent value 
return issue.epic."customfield_11000"

}

else if(issue.get("customfield_10605")=='Research'){

//Let's copy the parent value 
return issue.epic."customfield_11000"

}

else if(issue.get("customfield_10605")=='Release'){

//Let's copy the parent value 
return issue.epic."customfield_11000"

}

else if(issue.get("customfield_10605")=='Sub-task'){

//Let's copy the parent value 
return issue.parentObject."customfield_11000"

}

[David Fischer]

Right. So what is it that you are looking to achieve that currently doesn't work with this JMCF field?

[Christopher Kelley]

The following JMCF fields are created and work fine, copying the value of the parent as described earlier:

• Initiative Associate Engineer Parent
• Initiative Check Engineer Parent
• Initiative Lead Engineer Parent
• Initiative Release Engineer Parent
• Initiative Specialty Engineer Parent

We have not been able to get either:

1. Initiative Associate Engineer Parent to copy to Initiative Associate Engineer for any given individual issue (for all five examples)
2. Any copy (outside of the JMCF field work) of Initiative Associate Engineer of the parent Initiative to copy to Initiative Associate Engineer of a given child issue.

I'm less concerned between which method is used - the copy from X to Y (method #1 above) versus copy from parent to issue (method #2 above). 

Hope this helps clarify!

[David Fischer]

Hi Christopher,

I'm afraid there's still some confusion. JMCF calculated fields don't copy field values, they're like a "view" of the source field. 

I also don't understand what you mean by "Initiative Associate Engineer Parent to copy to Initiative Associate Engineer for any given individual issue". 

In general, you should configure your Single User Picker fields to show only at the topmost level of the hierarchy (in the custom field configuration), and then define a calculated field (like you did) that shows the parent value on all levels of the hierarchy. But of course only the original user picker will be editable (at the top of the hierarchy) - the calculated field at all the other levels will be read-only.

So "Associate Engineer" will be associated only to the Initiative issue type (and thus you don't need to call it "Initiative Associate Engineer"), and "Initiative Associate Engineer" should be a calculated field that reflects the value of the "Associate Engineer" from the parent Initiative and is available on all issue types except Initiative.

David

[Christopher Kelley]

For the sake of terminology, we can establish that we know JMCF is a calculated reference value. Copy/point/clone/replicate/etc are synonyms for this discussion.

Quite simply, we do not want a copy of the "Initiative Associate Engineer" field value in different field for all children than "Initiative Associate Engineer". If the Initiative level value for ""Initiative Associate Engineer" is "Jimmie" we want "Jimmie" as the value for the ""Initiative Associate Engineer" field of every issue under that initiative. We should not need to have multiple fields for the same underlying value.

• The naming of each field is intentional, and we would not want to go down the path of removing Initiative from the name (We understand your point, but it's not a good idea for this user audience).
• When a user goes into Plans, they see the "Initiative Associate Engineer" (or one of the five assigned user types from the list above) for the initiative and for each and every single child issue in the exact same field. We do not want to see the value as blank, or require a user in Plans view to infer a value - the value should be explicitly displayed and in a consistent way.
• Advanced Workflows cannot display a column where the field is of a JMCF type (so even if we did want to show that field/column, it's not possible).

So, in short:

"Jimmie" needs to be entered in "Initiative Associate Engineer" for #502 of the above image, and it then "Jimmie" shows as the "Initiative Associate Engineer" for each and every child in the tree once that issue is updated. 

If "Jimmie" becomes "Jane", then this change is as well pushed down at first update. 

Alternatively, a listener against "Initiative Associate Engineer" at Initiative could be set up to "push" (trigger) the corresponding change to all child issues in the tree upon a change. 

There is no use case to change or retain a change to the "Initiative Associate Engineer" value for all children (in other words, a change to Initiative is replicated to all children, and the value in the target is overwritten).

Hope this clear it up.

Thanks!

[David Fischer]

Yes, that's much clearer now. So basically you'd like to replace the JMCF approach of creating a calculated field to reflect the Initiative's custom field with an approach where you use an event listener to replicate yourself the value of the user picker to the whole hierarchy of issues under it (in the same user picker custom field).

This should be possible with ScriptRunner, however, the user picker field will remain editable on the non-initiative issues unless you use a different Edit screen for Initiative and other issues and add the user picker only to the Initiative's Edit screen (which will essentially prevent users from editing the field on other issue types).

I'll let a ScriptRunner expert explain how to implement the event listener, I'm not really familiar with ScriptRunner.

[Christopher Kelley]

Correct, this largely reflects the need.