Inherit Custom Fields from Parent Issue

Create issue
Issue #39 resolved
Daniel Farias created an 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.

Comments (48)

  1. Micha Kops repo owner

    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.

  2. Алексей Широких

    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

  3. TheresaH

    Hi @freeseacher

    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?



  4. Eric Baptist

    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.

  5. Micha Kops repo owner

    @resah 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

  6. Micha Kops repo owner

    @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 @resah 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.

  7. Micha Kops repo owner

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

  8. Micha Kops repo owner

    @danielfarias @freeseacher @ebaptist @Chris4 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"
  9. Daniel Farias reporter

    @hascode , 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?

  10. Micha Kops repo owner

    @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.

  11. Christian Horn

    @hascode 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.

  12. Micha Kops repo owner

    @Chris4 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.

  13. conrad hollomon

    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.

  14. Dylan Kusters

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

  15. Micha Kops repo owner

    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).

  16. Christian Horn

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

  17. Micha Kops repo owner

    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 @Chris4 '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
  18. Troy Johnson

    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?

  19. Troy Johnson

    @hascode, 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!


  20. Log in to comment