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)
-
repo owner -
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 @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?
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.
-
reporter Sorry there any plans?
-
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
-
@hascode : Yes, I would really like to support that feature. Let's look into this.
-
reporter Any news regarding this demand?
-
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.
-
reporter @hascode I understand, I thank you and look forward to the return of @resah
-
-
assigned issue to
Alright, starting a prototype to check whether this is actually realisable.
Wish me luck ;)
-
assigned issue to
-
reporter You do not need luck, are extremely competent! I wish you success!
-
Any update? When it's planned to be available?
-
@resah any progress?
@hascode any plans to release it?
-
reporter Waiting
-
repo owner - edited description
-
assigned issue to
- changed version to 3.0.1
-
repo owner - changed status to open
-
repo owner Issue
#126was marked as a duplicate of this issue. -
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.
-
repo owner - changed title to Inherit Custom Fields from Parent Issue
-
repo owner - attached jira-quick-subtasks-3.1.0-ALPHA.jar
Early unstable alpha with basic custom field inheritance from the parent issue..
-
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"
-
-
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?
-
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.
-
reporter @hascode Ok
-
@hascode Thanks, I will try to check it.
Just out of curiosity: in Issue
#101you 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
#104is related too. -
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
#101would 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. -
@hascode any update?
-
repo owner No update yet.
-
@hascode 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.
-
@hascode - 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......
-
repo owner Issue
#213was marked as a duplicate of this issue. -
@hascode +1 on @Chris4 's question above from May 2014. Thanks !
-
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).
-
I would already be happy if custom fields of the basic Jira types could be supported (string, long, date, user, text).
-
repo owner - changed milestone to 4.0.0
-
repo owner - changed status to resolved
-
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
-
That's a nice Christmas present, thanks a lot :-)
Looking forward to test release 4.0.0.
-
repo owner Issue
#250was 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?
-
repo owner @trojman There is a plan. Feature
#260does 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
-
@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!
Troy
-
repo owner @trojman You're welcome!
- Log in to comment
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.