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):
You install synchronizer that propagates FixVersion down. Now let's consider two scenarios:
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.}
Same as scenario 1, but (b) happens first!
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.