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.
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 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 allows us to create spreadsheet that becomes a project management
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
Again, thanks for your mail,