View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004639||mantisbt||relationships||public||2004-09-29 14:49||2017-06-11 13:44|
|Summary||0004639: New relationship "predecessor / successor"|
First: the relationships make Mantis a really powerfull tool.
What I noticed: In addition to the child / parent relationship, another very important relationship is the predecessor / successor. In bugzilla this is called "bug blocks / blocked by", I think.
While I regard the child / parent relationship as to group issues hierarchically, the predecessor / successor relationship is orthogonal.
I think this distinction becomes especially important as soon as someone had the time to write a hierarchy visualization for issues / Gantt chart view / whatever.
This relationship is also essential if you want to model workflows.
The alternative is--of course--to be able to add custom relationship types, but this one I really regard as very essential.
BTW: See also the note added to http://manual.mantisbt.org/manual.configuration.relationships.php
Having implemented the mindmap export (0007214) now, I again noticed that there should really be a difference between sub-issues (children) and dependent issues (that are not necessarily sub-issues). Only sub-issues should be displayed as sub-nodes.
I decided to have a go at modifying Mantis to implement both the dependant/blocks and child_of/parent_of relationships. The more depth I went into in the code and message strings though the more I realised that the terms 'dependant'/'blocks' and 'child'/'parent' were being used interchangeably. What seemed at first a simple task is actually more complex because of this tangling of terminology.
I agree that the 'child of'/'parent of' relationship is fundamentally different to the 'predecessor of'/'successor to' or 'blocks'/'dependent on' relationship.
As an aside, the 'blocks' relationship type could also be named 'prerequisite of'.
Maybe a first step is to rationalise the terminology and modify the code throughout to deal in a semantically consistent manner with one of these relationship types. Then the other one could be added more easily.
Hope this makes sense and is useful to somebody out there.
good to hear that someone else agrees that this should be two different relationships (nearly two years after I submitted this issues :-))!
I agree that a terminology cleanup would make sense, but I think this needs to be backed by the Mantis project management before starting such a larger change. (Victor et al., what do you think?)
My proposal would be to name it 'child of'/'parent of' and 'predecessor of'/'successor to'.
Is 'predecessor of'/'successor to' used as terminology in the code? (I didn't have a look into this yet.) If not, these two tasks (new relationship type and termonology cleanup) should be really independent.
Having additional relationship types of "blocks"/"dependent of" (or whatever terms are selected) would be awesome to have, especially for figuring out resources and planning schedules.
Please keep this request alive.
Any way this could be added as a child to 0006470?
Would be terrific if this was added
Considering that it is possible since 1.1 to add custom relationships , shouldn't this issue be closed ? If not, please provide clear specification of what is missing.