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 |
Reporter | tandler | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Product Version | 0.19.0 | ||||
Summary | 0004639: New relationship "predecessor / successor" | ||||
Description | 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. | ||||
Additional Information | 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 | ||||
Tags | project_management | ||||
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. |
|
Hi mdpearson, 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. Cheers, |
|
Bump! 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. --James |
|
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 [1], shouldn't this issue be closed ? If not, please provide clear specification of what is missing. http://www.mantisbt.org/wiki/doku.php/mantisbt:customizing_relationships |
|