Propagate field values down the hierarchy
Let the user specify, for example, that all sub-issues of the issue X should have the same Security Level and Project and Priority.
-
Hi Tom, thanks for keeping up interest in this feature. At this moment I cannot tell anything except that it is "planned". We keep it in mind by so far the whole team is doing other tasks.
I just spent some time thinking about this feature - posted my thoughts to https://jira.almworks.com/browse/HJ-164
Indeed, it is possible to implement this through a synchronizer - it can even be a separate mini-plugin, as synchronizers can be supplemented from outside Structure!
Cheers,
Igor -
Tom Jackson commented
Hi Igor,
Any news on the planning associated with this feature? I added a comment with my use case on HJ-164.
Thanks, Tom -
David, thanks for your comment.
Copying security level is also what happens when you use JIRA's Clone Issue action. We do the same. Setting a default level could also be considered elevation as it may expose information from the issue being copied.
With regards to this particular idea we're commenting, it's not about creating new issues, it's about making sure that all sub-issues and sub-sub-issues of X have the same value of F as X does.
Thanks!
Igor -
dsmorse commented
I'm confused because I'm about to open up a bug report because it appears that structure already does this when it clones the selected issue. It will allow the user (who does not have permissions to set the security level) to create an issue which clones the security level of the issue that was selected in the structure.
This is REALLY bad, because if a user does not have permission to set the security level it should ALWAYS be the default level not whatever level was set on the issue they selected in structure.
Our security folks consider it an elevation of privileges that structure is allowing a user who does not have permissions to set the security level the ability to clone an issue of any security level they desire. -
Peter, this feature won't make it into 1.6 and likely not into 1.7. However, as you can see it's one of the most voted, so it won't be left behind.
I can't promise feature release dates, but I can tell that we're expanding our team and increasing velocity.
For the companies that do their own custom JIRA development, it's possible to implement field propagation on their own using Structure API.
Sorry I couldn't provide a better response this time.
Igor -
Peter Tomolik commented
Igor, how far away in the future is this planned feature?
-
Angell commented
I agree, this is a big need for us.
-
Got it, thanks
-
Walter commented
Indeed.
More or less the same functionality as exists in the LNIO plugin. See image https://plugins.atlassian.com/server/1.0/screenshot/fetch/11746 (in french)
thx -
Walter, thanks for your comment. Could you please elaborate on the "extended implementation" - would you like to copy parent's field value to the children's *another* field?
-
Walter commented
Needs this also.
Basic implementation : a list of fields for which the data needs to be copied to the new child issue.
Extended implemenation : a mapping table - "from parent issue field to child issue field" -
cit commented
Also reverse order (by providing aggregation function like sum) would be helpful