Adding sub task data to the parent

[George Carvill]

Is there an add-in that will let me add text from a subtask to text already in a field in the parent?

[George Carvill]

It has never been clear to me how to figure out which plugin provides which fields or functions.

[Natalie Hobson]

I just tried it myself, you are correct - neither Labels nor a custom field of the type Labels is working - I guess they don't count as "multi select"? I am able to get the post function to work with other fields, such as Component and custom fields like Multi Select. It might be worth it to contact the plugin developers and ask them for a comprehensive list of what field types apply to the post function - I wasn't able to find one myself, unfortunately.

[George Carvill]

Yes. The field behaves like one, too, as far as putting in data, etc.

[Natalie Hobson]

And the type of custom field you made is a Labels type?

[George Carvill]

OK, so I moved it down to the bottom, right above "Fire a Issue Resolved event..."

But it still didn't populate the field in the parent.

I can open the parent for edit, go to the field, and the number is available in the drop down. But it is not getting entered into the field.

[Natalie Hobson]

If you are adding the value of "Changelist Number New" to the sub-task in the transition screen used by the same transition where you are adding that same value from sub-task to parent, then you need to move the post function below "re-index an issue to keep indexes in sync with the database". Otherwise, you are telling it to add the value of the field to the parent before the value is really there.

[George Carvill]

All

Conditions (1)

Validators (0)

Post Functions (8)

Set issue status to the linked status of the destination workflow step.

— THEN

Add a comment to an issue if one is entered during a transition.

— THEN

The value(s) of field Changelist Number New will be added to the issue's parent's field.

— THEN

The field Resolved by will take the value from Assignee.

— THEN

The value(s) of field Resolved by will be copied to the issue's parent's field (replacing existing values).

— THEN

Update change history for an issue and store the issue in the database.

— THEN

Re-index an issue to keep indexes in sync with the database.

— THEN

Fire a Issue Resolved event that can be processed by the listeners.

[Natalie Hobson]

What order are your post functions in?

[George Carvill]

Seemed like a sound idea, but it didn't work.

Added the field 'Changelist Number New' to all types and I have this in the transation step:

"The value(s) of field Changelist Number New will be added to the issue's parent's field."

And I transition the subtask through it and fill in the field. The value is in the subtask all right, but doesn't show up in the parent.

[Udo Brand]

George, yes it should work. I have similar setups.

[Natalie Hobson]

If you install that plugin I mentioned above, and use that post function on a transition (in the sub-task workflow) , it will take the value(s) of the field you specify in the sub-task (in this case the Label custom field you end up making), and add them to the value of the field in the parent issue. So you'll need to make the custom field, add it to your screens for those issue types, and decide at what point(s) in the sub-task workflow that you want to add the values to the parent (maybe just when you're closing it, if you only want to do it once?).

Udo-no prob! :)

[Udo Brand]

Sorry, was on the road for couple of hours otherwise I had commented it myself. Thanks Nat for jumping in.

[George Carvill]

I see that I can create a custom field of the "Label" type. (Missed it before because I only looked at the fields I had already created. Sorry.)

So, are you saying if I have this field in Stories and Subtasks, if I put one label in one subtask and another in another subtask I can get the workflow to put both into the Story?

[Natalie Hobson]

Udo's right, Labels would also do what you're wanting without all that prep work. Labels is a custom field type that comes with JIRA (it's not from a plugin or anything); I'm pretty sure it's been around since 4.2. What version are you running, GeorgeCC?

[George Carvill]

@Nat - I will ask the question.

@Udo - Sorry, but I don't quite follow your suggestion. I don't see "Label" as a type of custom field.

[Udo Brand]

If your field "change list numbers" would be of the type Label field it actually could work with Nats proposed plugin. You don't need to set up all those numbers in advance just a new number for each subtask that then will be added to the parent.

[Natalie Hobson]

Hmm, I'm not sure - I guess the two things to worry about would be A) is there a limit on the number of options that can exist in a multi select field and B) is there a limit to how many of those options can currently be a value in the field when working with the issue. Maybe someone from Atlassian would be able to chime in on those?

[George Carvill]

Humm... So it might work, would it, if the multi-value field already had a series of numbers, say 46000 to 100000 as selectable values. Is there a limit to the number of values I can have ready?

[Natalie Hobson]

Thanks - this wouldn't work for text, but if someone else doesn't have an answer for exactly what you want, you can use JIRA Misc Workflow Extensions; it has a post function "Add Field Value to Parent" which will add the value of a multi-valued field into the same field in the issue's parent.

[Natalie Hobson]

Just to clarify, do you mean like this example:

Parent issue has "This is an issue" in the Description field

Sub-task issue has "- clarification - blah blah blah" in the Description field

You wish to have the sub-task tell the parent to update its Description field to "This is an issue - clarification - blah blah blah"

? Or are you looking to replace the text? And does it have to be text, or can this be a field like "Multi Select"?

[George Carvill]

Your second is correct: have the sub-task tell the parent to update its Description field to "This is an issue - clarification - blah blah blah"

The actual use case is to have a field called "change list numbers" and as each subtask is checked in an gets a change list number, the number is added to the parent. Thus in the end the parent has a list of all the changelist numbers that made up the change.