Inherit Custom Fields from Parent Issue

Is there any way of sub task is created inheriting a value from a custom field? For example: Customer field of sub task inherit the value of the customer field issue principal.

That's an interesting idea .. not only for custom fields but for all possible issue properties .. something like

- My child issue / assignee:"@parent"

should create a sub task with summary=My child issue and the assignee set the the parent issue's assignee.

in my use case i want to inherit most of fileds! except assigeeand watchers list... In generic i want to create the same issue on many developers

and some different cuctom fields

Hi @Aleksey Shirokih

thanks for your suggestion. So what's needed here is the possibility for a general inheritance from the parent issue and the ability to overwrite an inherited field by setting it explicitly, right?

Regards

Theresa

Agree There are many fields I wouldn't mind inheriting unless explicitly asked to overwrite, Even if it just starts with the simple inheritance of Parent things like Summary, Description, due date etc.

Sorry there any plans?

@TheresaH we could implement such a thing for the fields that are currently implemented in the dsl .. to allow this for every possible custom field could be complicated

@Micha Kops : Yes, I would really like to support that feature. Let's look into this.

Any news regarding this demand?

@danielfarias I'd like to implement inheriting values from the parent issue for the existing subtask fields in the plugin but as custom fields may contain complex data I don't feel save to implement such a feature .. I'm going to ask @TheresaH if she has an idea for a save way to handle this but atm I think this feature is not in the scope for one of the next releases.

@Micha Kops I understand, I thank you and look forward to the return of @TheresaH

Alright, starting a prototype to check whether this is actually realisable.

Wish me luck ;)

You do not need luck, are extremely competent! I wish you success!

Any update? When it's planned to be available?

@TheresaH any progress?

@Micha Kops any plans to release it?

Waiting

Issue #126 was marked as a duplicate of this issue.

@Christian Horn We'll see, for now I'll be trying to assemble a prototype and see if we're heading in the right direction.

Early unstable alpha with basic custom field inheritance from the parent issue..

@danielfarias @Aleksey Shirokih @ebaptist @Christian Horn I've created an early prototype that allows to inherit a custom field's value from the parent issue when a subtask is created. It is a protoype in the meaning that there is no error handling, no in-app documentation and atm you're only able to inherit one custom field value from the parent issue.

I've advanced one first test using the following steps:

• I've added a new custom field of type datepicker with name "Some Date"

• I've assigned it to the default screen and did an re-index

• I've created a new issue and assign a "Some Date" using the datepicker

• I've created a subtask using the syntax below

• I've verified that the subtask has the "Some Date" field assigned and with the same value as the parent issue

The syntax is like this (and might be changing in the future):

- Some subtask / cfinherit:"Some Date"

@Micha Kops , My need is exactly that. questions:

1 - When the custom field, the parent issue changes the custom field in issue daughter inherits the change?

2 - When the custom field, daughter of issue changes the custom field in issue parent receives the change?

@danielfarias It depends I'd say. In the prototype I'm simply copying the value from the custom field.

As there may exist multiple completly different custom field e.g. from a simple text field to a dynamic rendered custom field that pulls data from an external database it may be that a behaviour as described is achieved but I won't and I cannot handle it in the plugin.

On the other side - if you need to maintain dependencies between issue and sub-issue's custom fields after their creation - I am sure that third party plugins exist allowing you to manage such a scenarion.

@Micha Kops Ok

@Micha Kops Thanks, I will try to check it.

Just out of curiosity: in Issue #101 you thought to introduce the following syntax:

- Some Subtask / affectedversion:"@inherit"

Or in this case it would read:

- Some Subtask / "Some Date":"@inherit"

I started to like this syntax. What has made changing your mind?

Will the syntax be different for standard and for custom fields?

Issue #104 is related too.

@Christian Horn The syntax described above was just a quick solution not to lose too much time adjusting the dsl parser.

You're right that using @inherit is more consistent and using a similar format as described in #101 would make it easier if we'd choose to implement a function to set a custom field to a specific value instead of copying it from the parent issue one day.

@Micha Kops any update?

No update yet.

@Micha Kops Is there already an update at the moment?

Due to the way we are using custom fields, we could also really use this feature. Right now, I have a list of ~12 subtasks that we use the addon for - unfortunately, since they don't inherit the custom field value of the parent, I have to go in and manually add it for every single one.

We really appreciate any help you can provide.

@Micha Kops - any update on this feature request? Thanks :)

We would also really like that feature. Is there any update?

Still no update :( It is so much more work to manually change a custom field for every subtask that is created with this plugin......

Issue #213 was marked as a duplicate of this issue.

@Micha Kops +1 on @Christian Horn 's question above from May 2014. Thanks !

As I'm not sure if copying more complex custom fields won't be a problem but the demand for this feature seems to be pretty high, therefore I'll be adding this feature but the JIRA administrator must unlock this feature first in the configuration area (see #219).

I would already be happy if custom fields of the basic Jira types could be supported (string, long, date, user, text).

Inheriting a parent issue's custom fields is now implemented and will be added with release 4.0.0. The feature is implemented using the new extension API therefore it is possible to deactivate it in the plugin administration.

Inheriting one or more custom-field values is possible using the following syntax:

- Summary / cfield:"fieldname1:@inherit" cfield:"fieldname2:@inherit"

I have switched to this syntax in preparation for a possible future feature allowing to assign custom-field values directly using a syntax like cfield:"fieldname:value" or something similar.

I have restricted the supported field types according to @Christian Horn 's requirements and extended it so that the following custom-field types are currently supported:

• Checkboxes
• Text Field (Single Line)
• Date Picker
• Number Field
• Text Field (Multi Line)
• URL Field
• User Picker (single user)
• Select List (multiple choices)
• Date Time Picker

That's a nice Christmas present, thanks a lot :-)

Looking forward to test release 4.0.0.

Issue #250 was marked as a duplicate of this issue.

I see that Select List is supported but it appears that it is only for multiple choices lists. Is there a plan to support single select? Is there a technical reason not to support single select as well?

@trojman There is a plan. Feature #260 does exist, is implemented and pushed with release 4.1.0 to the marketplace a minute ago. Please feel free to update your plugin, test it and comment it here:

https://bitbucket.org/hascode/jira-quick-subtasks/issues/260/support-custom-field-type-select-list

Thanks for your input!

Cheers,

Micha

@Micha Kops, I have installed the latest version as suggested and it does work! Thank you! This will solve a mountain of problems for us!

Keep up the great work!

Troy

@trojman You're welcome!