Structure Plugin
  1. Structure Plugin
  2. HJ-164

Propagate a value down the hierarchy

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: API
    • Labels:

      Description

      One possible use case:
      1. Turn on "propagation"
      2. Hover mouse over a value in Structure table
      3. Little "down" arrow appears
      4. Click on the arrow
      5. The values in the same field for all subissues are changed to that value

        Issue Links

          Activity

          Hide
          Igor Sereda added a comment -

          From HJ-559:

          1. For instance, a structure

          A
          A.1
          A.1.a
          A.1.b
          A.1.c
          A.2
          A.2.a
          A.2.b

          When I change the fixVersion on A, I want that all sub issues of A are updated
          When I change the fixVersion on A.2, the same but only for the issues under A.2

          2. "Action" solution vs "Invariant" solution? All of it + the possibility to 'add version'.

          Ie

          issue old version new version
          A 2.0 2.1
          A.1 2.0 M1 2.1 M1
          A.1.a 2.0 M1 Sprint 1 2.1 M1 Sprint 1
          A.1.b 2.0 M1 Sprint 1 2.1 M1 Sprint 1
          A.1.c 2.0 M1 Sprint 2 2.1 M1 Sprint 2
          A.2 2.0 M2 2.1 M2
          A.2.a 2.0 M2 2.1 M2
          A.2.b 2.0 M2 2.1 M2

          Modifying the version on issue A, has an impact on the fix versions of all the subissues.
          Adding a new sub issue A.1.d would add by default fix version 2.1 M1 to it.

          Show
          Igor Sereda added a comment - From HJ-559: 1. For instance, a structure A A.1 A.1.a A.1.b A.1.c A.2 A.2.a A.2.b When I change the fixVersion on A, I want that all sub issues of A are updated When I change the fixVersion on A.2, the same but only for the issues under A.2 2. "Action" solution vs "Invariant" solution? All of it + the possibility to 'add version'. Ie issue old version new version A 2.0 2.1 A.1 2.0 M1 2.1 M1 A.1.a 2.0 M1 Sprint 1 2.1 M1 Sprint 1 A.1.b 2.0 M1 Sprint 1 2.1 M1 Sprint 1 A.1.c 2.0 M1 Sprint 2 2.1 M1 Sprint 2 A.2 2.0 M2 2.1 M2 A.2.a 2.0 M2 2.1 M2 A.2.b 2.0 M2 2.1 M2 Modifying the version on issue A, has an impact on the fix versions of all the subissues. Adding a new sub issue A.1.d would add by default fix version 2.1 M1 to it.
          Hide
          Tom Jackson added a comment -

          My use case:

          Edit a parent issue in a structure and set a custom field.
          Have the field setting propagate to all children in the structure.

          Seems like a perfect job for a new species of synchronizer. Maybe a "Field Synchronizer"?

          Thanks, Tom

          Show
          Tom Jackson added a comment - My use case: Edit a parent issue in a structure and set a custom field. Have the field setting propagate to all children in the structure. Seems like a perfect job for a new species of synchronizer. Maybe a "Field Synchronizer"? Thanks, Tom
          Hide
          Igor Sereda added a comment -

          Tom, thanks for your comment!

          Yes, this could be a synchronizer. However, for a good synchronizer it should be possible to define an "invariant" - a condition that should always hold true when the synchronizer is enabled. If there's no invariant and synchronizer simply reacts as described in (2) above, then there may be undetermined and confusing behavior.

          For example, suppose you have this structure (B is sub-issue of A, C is sub-issue of B):

          A
          \-B
            \-C
          

          You install synchronizer that propagates FixVersion down. Now let's consider two scenarios:

          Scenario 1:
          a. User X sets FixVersion=v1 on A. (The synchronizer also sets FixVersion=v1 on all sub-issues of A.)
          b. User Y sets FixVersion=v2 on B. (The synchronizer also sets FixVersion=v2 on all sub-issues of B.}
          The result:

          A:v1
          \-B:v2
            \-C:v2
          

          Scenario 2:
          Same as scenario 1, but (b) happens first!
          The result:

          A:v1
          \-B:v1
            \-C:v1
          

          To make matters worse, due to technical limitations, the propagation of FixVersion may happen when the issue is changed in some other aspect!


          So, if this is going to be a synchronizer, I would imagine it would have the following configuration:

          • JQL/Saved Filter to define the issues that are sources of the propagation. Only values from matching issues get propagated down.
          • JQL/Saved Filter to define the target issues: those issues who are affected by the synchronizer. Non-matching issues will not be changed.
          • Field(s) to propagate down
          • Optionally, the depth of the propagation (by default, unlimited)

          And the invariant would be:

          Every target issue must have the same value in the selected fields as its closest parent source issue. (optionally limited by depth distance between source and target)

          How is this different?

          Well, for instance, in the example above, if A matches the source filter, and B,C match target filter, and then someone changes FixVersion of B, then this change immediately gets rolled back! Because B must have the same value in FixVersion as A.

          Please let me know if this would work for you! Sorry for a long/techy description.

          Show
          Igor Sereda added a comment - Tom, thanks for your comment! Yes, this could be a synchronizer. However, for a good synchronizer it should be possible to define an "invariant" - a condition that should always hold true when the synchronizer is enabled. If there's no invariant and synchronizer simply reacts as described in (2) above, then there may be undetermined and confusing behavior. For example, suppose you have this structure (B is sub-issue of A, C is sub-issue of B): A \-B \-C You install synchronizer that propagates FixVersion down. Now let's consider two scenarios: Scenario 1: a. User X sets FixVersion=v1 on A. (The synchronizer also sets FixVersion=v1 on all sub-issues of A.) b. User Y sets FixVersion=v2 on B. (The synchronizer also sets FixVersion=v2 on all sub-issues of B.} The result: A:v1 \-B:v2 \-C:v2 Scenario 2: Same as scenario 1, but (b) happens first! The result: A:v1 \-B:v1 \-C:v1 To make matters worse, due to technical limitations, the propagation of FixVersion may happen when the issue is changed in some other aspect! So, if this is going to be a synchronizer, I would imagine it would have the following configuration: JQL/Saved Filter to define the issues that are sources of the propagation. Only values from matching issues get propagated down. JQL/Saved Filter to define the target issues: those issues who are affected by the synchronizer. Non-matching issues will not be changed. Field(s) to propagate down Optionally, the depth of the propagation (by default, unlimited) And the invariant would be: Every target issue must have the same value in the selected fields as its closest parent source issue. (optionally limited by depth distance between source and target) How is this different? Well, for instance, in the example above, if A matches the source filter, and B,C match target filter, and then someone changes FixVersion of B, then this change immediately gets rolled back! Because B must have the same value in FixVersion as A. Please let me know if this would work for you! Sorry for a long/techy description.
          Hide
          Tom Jackson added a comment -

          That would work great for us! Thanks for the detailed explanation.

          Show
          Tom Jackson added a comment - That would work great for us! Thanks for the detailed explanation.
          Hide
          Tom Jackson added a comment -

          Is there a separate feature request for propagating values up the hierarchy? Could be useful to give users a means of creating user-defined roll-up fields along the lines or your "special columns" (Progress, Summary, etc.). The trick would be providing users a means to define the roll-up rules. Could get complex (but super cool!).

          Show
          Tom Jackson added a comment - Is there a separate feature request for propagating values up the hierarchy? Could be useful to give users a means of creating user-defined roll-up fields along the lines or your "special columns" (Progress, Summary, etc.). The trick would be providing users a means to define the roll-up rules. Could get complex (but super cool!).
          Hide
          Igor Sereda added a comment -

          There's no feature requests for exactly value propagation.

          But if you have in mind the aggregation of values – like Structure does right now for the estimates, then this is planned. First, there's a request to be able to show sum of numeric fields - HJ-724 (we might also implement other aggregating functions, like min/max), then, there's a feature planned to provide API for developers so they can define their own columns (with possible aggregation) - HJ-357

          All this would just add columns and column configuration to the Structure widget, it won't change the actual data in the issues. Is this something you have in mind?

          Show
          Igor Sereda added a comment - There's no feature requests for exactly value propagation. But if you have in mind the aggregation of values – like Structure does right now for the estimates, then this is planned. First, there's a request to be able to show sum of numeric fields - HJ-724 (we might also implement other aggregating functions, like min/max), then, there's a feature planned to provide API for developers so they can define their own columns (with possible aggregation) - HJ-357 All this would just add columns and column configuration to the Structure widget, it won't change the actual data in the issues. Is this something you have in mind?
          Hide
          Francis Martens (idalko) added a comment -

          Igor,

          Are you planning to develop this capability. We just need it for standard fields like fixversion and component.
          The issues are in the same project.

          Francis

          Show
          Francis Martens (idalko) added a comment - Igor, Are you planning to develop this capability. We just need it for standard fields like fixversion and component. The issues are in the same project. Francis
          Hide
          Igor Sereda added a comment -

          Hi Francis, yes we are!

          Show
          Igor Sereda added a comment - Hi Francis, yes we are!
          Hide
          Francis Martens (idalko) added a comment -

          Let it come !
          Have a nice weekend

          F.

          Show
          Francis Martens (idalko) added a comment - Let it come ! Have a nice weekend F.
          Hide
          Tom Jackson added a comment -

          Any more "planning" news? We are still intrigued by this feaure!

          Show
          Tom Jackson added a comment - Any more "planning" news? We are still intrigued by this feaure!
          Hide
          Igor Sereda added a comment -

          Hi Tom - sorry for slow progress on this; we have it on our radar, but currently two major features are being developed (hierarchy extensions to JQL, and extensible columns, which includes aggregation over numeric fields), so this feature in the plan is somewhere next.

          Show
          Igor Sereda added a comment - Hi Tom - sorry for slow progress on this; we have it on our radar, but currently two major features are being developed (hierarchy extensions to JQL, and extensible columns, which includes aggregation over numeric fields), so this feature in the plan is somewhere next.
          Hide
          Max Doppler [Debeka] added a comment -

          We would also like this feature.

          We add issues in Agile plugin to a sprint. What we need is, that sub issues in structure should be added automatically to the same sprint (configureable!). Thus, as in the case with the standard JIRA subtasks.

          See: https://answers.atlassian.com/questions/232730/structure-plugin-schedule-whole-tree-of-issues-to-a-sprint

          Show
          Max Doppler [Debeka] added a comment - We would also like this feature. We add issues in Agile plugin to a sprint. What we need is, that sub issues in structure should be added automatically to the same sprint (configureable!). Thus, as in the case with the standard JIRA subtasks. See: https://answers.atlassian.com/questions/232730/structure-plugin-schedule-whole-tree-of-issues-to-a-sprint
          Hide
          Mathieu Blouin added a comment -

          I support the development of this feature. It has a lot of potential applications and would be of a great help for us in the short term.

          +1 vote for this!

          Show
          Mathieu Blouin added a comment - I support the development of this feature. It has a lot of potential applications and would be of a great help for us in the short term. +1 vote for this!

            People

            • Assignee:
              Unassigned
              Reporter:
              Igor Sereda
            • Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel