Forgot your password?
New user?
Document Actions
#4: Issue predecessors
- Contents
In many cases there is need to make references between issues where one issue depends on the resolution of another.
- Proposed by
- Lukas Zdych
- Proposal type
- Architecture
- State
- being-discussed
Motivation
User who changes issue state for example from state "in-progress" to "on hold" state because of he has to wait for another issues to be finished should be able to quick and easy refer to them.
Proposal
- Add predecessors:multi-reference
- should use ATReferenceWidget limited only for selecting issues in the current tracker. Alternatively, a standard selection widget with all open issues as a vocabulary may be easier (in fact, we want ÜberSelectionWidget here too)
- should inform that the issue depends on finishing of other issues listed in it's predecessors
- need UI improvement like: display predecessors in issue view template.
- Possibly add a usePredecessors:boolean field to tracker schema
- turns on/off availability of defining predecessors in issue edit form
- this may be unnecessary complexity, though
This should remain as information only. Adding restrictions so that e.g. issues can't be closed before predecessors are will be a massive pain.
Nested Issues
Posted by
Anton Georgiev
at
October 3, 2007 - 17:52
Isn't this actually a part of a bigger concept - nested issues? An issue depending on other issues effectively should comprise them. And furthermore (enhancing Justin's comments) a parent issue shall be resolved when _all_ its child issues have been resolved. There are some considerations though about should the parent issue be restricted to contain only nested issues or could have own task too.
Brilliant!
I second this proposal, though I disagree on one point. I feel that it would not be difficult to implement optional restrictions on issue closure. Furthermore, it may be possible to implement auto-resolve status once all predecessors are confirmed.