Hi all,
what is the conceptual difference between Parent/Child and Depends on/
Depended on by? To me, they mean essentially the same and I can’t come
up with a use case where both would be used simultaneously or even just
differently.
If there is no real difference, wouldn’t it make sense to deprecate
either (while still supporting it, of course).
Richard
Hi all,
what is the conceptual difference between Parent/Child and Depends on/
Depended on by? To me, they mean essentially the same and I can’t come
up with a use case where both would be used simultaneously or even just
differently.If there is no real difference, wouldn’t it make sense to deprecate
either (while still supporting it, of course).Richard
Parent/child simply describes a relationship between tickets (children
belong to parent). Depends on enforces a rule - the depended on ticket
must be resolved before its dependent tickets can be resolved.
I would point you to the RT Essentials book, but this part is backwards in
the book (in my edition at least).
STeve
Stephen Turner
Senior Programmer/Analyst - SAIS
MIT IS&T
Parent/child simply describes a relationship between tickets (children
belong to parent). Depends on enforces a rule - the depended on ticket must
be resolved before its dependent tickets can be resolved.
So basically, parent/child sit between the strong Depend and the weak
Refer. Not sure if that is useful in any application, but I now know
that I don’t need it for my workflows.
Thanks 
Richard
So basically, parent/child sit between the strong Depend and the weak
Refer. Not sure if that is useful in any application, but I now know
that I don’t need it for my workflows.Thanks
Richard
I think we’ve used parent/child to group tickets that refer to the same
issue - for example an outage reported by several people. It makes it easy
to locate all those tickets and send out a single reply to them all when
the outage is fixed.
Steve
Stephen Turner
Senior Programmer/Analyst - SAIS
MIT IS&T
Richard,
There is also another difference. In the LINKS table, the "TYPE" of
link maintained for a ticket is also different. In a situation where
there is a Parent/Child relationship, the type is defined as “MembersOf”
and if it is a DependsOn relationship, then the type is defined as
“DependsOn”. This would be important when creating a search. Hope this
helps.
Kenn
LBNLOn 9/22/2008 7:35 AM, Richard Hartmann wrote:
On Mon, Sep 22, 2008 at 15:03, Stephen Turner sturner@mit.edu wrote:
Parent/child simply describes a relationship between tickets (children
belong to parent). Depends on enforces a rule - the depended on ticket must
be resolved before its dependent tickets can be resolved.So basically, parent/child sit between the strong Depend and the weak
Refer. Not sure if that is useful in any application, but I now know
that I don’t need it for my workflows.Thanks
Richard
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Richard,
We use the Parent/Child and DependsOn relationships a great deal and
this is how we do it. Whenever we have a ticket that in and of itself
causes other work to be done within the SAME support group for the same
queue, we make those tickets “Children” tickets of the main/original
request ticket. This can go to several leve3ls, if necessary. When a
queue receives a ticket that requires work to be done by another support
group for another queue, we create a ticket in that other queue and make
the relationship a “DepensOn” ticket. For example, my support queue may
get a request ticket that requires several programs to be developed. the
origianl ticket is the parent and the ticket for each new program will
be children tickets. Each of those children tickets may also require
work, like a sub-routine that can be used by all the other children
tickets. At the same time, this work may also require a new field to be
defined in the DataBase. So we then create a ticket in the DBA queue for
that field and THAT new ticket in the DBA queue will be created as a
"DenedsOn’ ticket.
I can see all those relationships when I run a search that includes
“Parents”, “Children”, “DependsOn”, and “DependedOnBy” as well as the
due dates and “Work-Status” (a CF we have as mandatory for every ticket
in all queues. It shows what process the work or development is in, ie.
“Requested”, “In Process”, “UnitTesting”, “System Testing”, “QA
Testing”). This allows us to create spreadsheet that becomes a project
management report. Hope this helps.
Kenn
LBNLOn 9/22/2008 4:10 AM, Richard Hartmann wrote:
Hi all,
what is the conceptual difference between Parent/Child and Depends on/
Depended on by? To me, they mean essentially the same and I can’t come
up with a use case where both would be used simultaneously or even just
differently.If there is no real difference, wouldn’t it make sense to deprecate
either (while still supporting it, of course).Richard
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We use the Parent/Child and DependsOn relationships a great deal andthis is how we do it. Whenever we have a ticket that in and of itself causes
other work to be done within the SAME support group for the same queue, we
make those tickets “Children” tickets of the main/original request ticket.
[…]
This allows us to create spreadsheet that becomes a project management
report.
Thanks for taking the time to explain your process. It seems to me that you
are mainly using parent/child vs depends for management purposes, i.e. to
show which business unit did what.
You do this at the loss of automatic sanity checking (i.e. forcing the large
ticket to stay open until all subtickets have been closed), but from how you
write, I assume it’s working nicely, for you.
I still can’t see the advantage in this scheme (for example, you could use
depends and another CF that holds the name of the department), but as
I said, I may simply think about this the wrong way and/or just work
differently.
Again, thanks for your mail,
Richard
Richard,
Actually, I've NEVER been able to resolve a parent ticket without all
the children tickets being resolved first. Because of the way the LINKS
table works, I can have a child ticket ALSO be a “DependedOnBy” ticket
as well, although I’m not sure that is required. I even remember someone
on the list having written a scrip that checks all dependencies,
parents, etc and when the last dependency for a parent is resolved, the
parent is automatically resolved as well.
As to automatic sanity, I created a query to run whenever I go to the
home page that lists all non-resolved tickets and all the
dependencies/children as well as the Custom Fields that shows their
“Work-Status” (In Progress, Unit Testing, system Testing, etc.), Due
date, TIme Left, priorities, owners, etc. SO whenever I need to see
what’s up, I just go to my home page. No sweat!
I don’t need departments because each of our support queues works for
one department. We have over 115 support Queues and each queue has one
manager (AdminCc) and 1 support group (techies) and 1 User group as well
as a few other groups allowed to participate in either a consulting or
watching role. We let the Queue Manager (AdminCc) manage who is allowed
to access their queue.
Not only is all our project management of each project done with RT,
but we have our own Approval Queues set up with new Ticket Statuses like
“pending rv”, “rq approvd” for review and approval before we move it to
the appropriate support queue. We have an entire User guide to show our
users how to use this infrastructure as well as a “Queue Admin” guide to
show our Queue managers how to manage their queues and the privileges
they have and how to use them. Because of the nature of our
infrastructure for software support, we also have Ticket Statuses of
“pending qa” and “qa approvd” for our QA/User Acceptance testing
procedures as well as scrips to ensure that the developer does NOT
approve their own work. I also created a “Glossary of Terms”, “Rights
Dictionary”, and “Data Dictionary” as tools for management of RT. We
have no loss of “AUTOMATIC SANITY”. Hope this helps.
Kenn
LBNLOn 9/23/2008 4:11 AM, Richard Hartmann wrote:
On Mon, Sep 22, 2008 at 19:07, Kenneth Crocker KFCrocker@lbl.gov wrote:
We use the Parent/Child and DependsOn relationships a great deal andthis is how we do it. Whenever we have a ticket that in and of itself causes
other work to be done within the SAME support group for the same queue, we
make those tickets “Children” tickets of the main/original request ticket.
[…]
This allows us to create spreadsheet that becomes a project management
report.Thanks for taking the time to explain your process. It seems to me that you
are mainly using parent/child vs depends for management purposes, i.e. to
show which business unit did what.
You do this at the loss of automatic sanity checking (i.e. forcing the large
ticket to stay open until all subtickets have been closed), but from how you
write, I assume it’s working nicely, for you.I still can’t see the advantage in this scheme (for example, you could use
depends and another CF that holds the name of the department), but as
I said, I may simply think about this the wrong way and/or just work
differently.Again, thanks for your mail,
Richard