View Issue Details

IDProjectCategoryView StatusLast Update
0004639mantisbtrelationshipspublic2017-06-11 13:44
Reportertandler Assigned To 
Status acknowledgedResolutionopen 
Product Version0.19.0 
Summary0004639: 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.

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
by martin.norland who suggests to use 'depends on' 'dependant of' as terminology ==> I'd say this is rather the new relationship I'm suggesting to add.



related to 0008130 closedgrangeway Custom relationships 
related to 0013203 acknowledged incompletely customized relationships 
has duplicate 0006677 closeddhx blocking state & blocking relationship 
related to 0022960 new Request: "Follows" relationship 




2006-06-28 08:02

reporter   ~0013044

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.



2006-08-05 16:58

reporter   ~0013197

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.



2006-08-07 04:29

reporter   ~0013207

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.




2007-05-30 09:49

reporter   ~0014656


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.




2007-05-30 12:37

reporter   ~0014658

Any way this could be added as a child to 0006470?



2008-09-24 15:56

reporter   ~0019450

Would be terrific if this was added



2012-11-12 06:10

developer   ~0034297

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.