[rt-devel] Some features I'd like to see

[Rouillard, John]

> From: Tobias Brox [mailto:tobiasb at tobiasb.funcom.com]
...
> Loops don't make sense at all, I guess we agree on that.  If a user
> creates a loop, it means that he has done something wrong - so it would
> make sense to do a loop-test and give an error message.

Agreed.
 
> Anyway, I think nothing really bad can happen if somebody creates a
> loop on mistake.

I'm not sure about that. The easiest way to find ticket dependencies/track
completion is to do a traveral of the tree. If a loop is created, then the
traversal code need to determine that a loop exists and stop walking that
portion of the tree. I guess the loop detection code wouldn't be that bad,
but I would prefer it not to be necessary
for heavily used programs like rtq or the web interface.

> In my system, it would not make sense to make a ticket dependent
> on a request that is either stalled or resolved.  I think it 
> makes sense to test this as well.

Strange. That happens a lot where I have been.

ticketa:ticketb:ticketc -> ticketd -> tickete:ticketf:ticketg

where the : separated tickets are all at the same level. If ticketg is
stalled pending more information (say from a vendor), work can still
progress on tickete and ticketf, but should ticketd, or ticketa, ticketb or
ticketc be stalled? In our system we said no. Only if all of tickete,
ticketf, and ticketg are stalled is ticketd (and therefore ticketa, ticketb,
and ticketc) stalled (note in our system we used real merging, so ticket a,
b, and c didn't really exist outside of ticket d).

If you mean making a new link on a stalled ticket, that happens as well.
E.G. The new disk comming in could be used to solve tickets: "Running out of
mail spool space", "need more room on userdisk2", and "need to decomission
RL02 drive".

> If I understand you correct, your terminology looks like 
> this, explained with my terminology (:
> 
> Several component tickets are dependent on one group ticket
> One parent ticket is dependent on (several) derived tickets

Correct I think. Don't forget that a parent ticket can be a group ticket.

> A reply to one group ticket should go to all dependent tickets.
> When a group ticket is resolved, the dependent tickets should 
> be resolved.

Agreed. And a group ticket can't be resolved unless all of the ticket that
have that group ticket as a parent are resolved.

> All derived tickets must be resolved before the dependent might be
> resolved.

Um if dependent in this case means parent tickets to the derived tickets,
then yes
your statement is correct.
 
> > Example A
> > 
> >        Ticket1 is componet of ticket3
> >        Ticket2 is component of ticket3
> >        ticket4 is derived from ticket1
> 
> Translated into my terminology:
> 
> #1 and #2 is dependent on #3
> When #3 is resolved, #1 and #2 should also be resolved
> Replies to #3 should go to #1 and #2.

Correct.

 
> #1 is dependent on #4
> #4 should be resolved before #1 is resolved.

Correct.


> A real life example:
> 
> #1: user A says "mail server is not working, and i demand compensation
> since I've paid for using this mail server"
> #2: user B says "mail server is not working"
> #3: 1st line support "spawns" #3: "mail server is not working"
> 	to techincal support
> #4: request from 1st line support to the customer billing department:
> 	"please make a reduction for user A"
> 
> > does that mean that ticket4 is derived from ticket2 as well?
> 
> Uhm ... no?  Absolutely not?
> 
> Request #4 and #3 will be open, the others stalled, in my system.

But 1 and 2 aren't stalled (see below) really. Work is progressing just
under another ticket number. The state of ticket 3 is also the state of
tickets 1 and 2. In my scheme ticket4 is the problem. You are right in that
it belong to ticket1, but it makes
life a hassle, because closing ticket 3 no longer implies that ticket1 can
be closed. Only when ticket4 and ticket3 are closed is ticket1 closed.

> > Ticket4 is ok as a derived ticket of ticket3. Killing ticket3 would
result
> > in the following:
> > 
> >       ticket1 stands alone
> >       ticket2 stands alone
> >       ticket3 is a derived ticket for both ticket1 and ticket2
> 
> It might be an idea setting up the system to reopen #1 and #2 if #3 is
> killed.

In my case, they would never have been closed/stalled. Maybe we need 
another status for those tickets. Then they would be moved to open status
from this new status.

Also we seem to be using stalling differently. Stalling was used for
suspending work pending an outside event. Ticket stalled too long implied
that somebody wasn't getting the assistance they needed to do their job.
E.G. "We need more disk space" would be stalled pending shipment of disks
from vendor, or getting price quote from vendor. In either case if I saw the
ticket stalled beyond its expected reopening date, I would call the person
who stalled it and find out what was up and if I could help unstall the
ticket.

> > This keeps the dependencies of the original system since all
requirements
> > flow from the top downward (i.e. there is an implicit tree transversal
> > order).
> 
> In my "thoughts" I'm going from left to right; the left ticket is
> dependent on the right ticket.  The leftmost tickets are from 
> the external
> user, the rightmost might be worktasks that needs to be done. 
>  The work flow is from left to right, but there might be an information 
> flow from the right to the left.

That's fine I can handle top == left and bottom == right. I think both ways
work.
I was just using an analogy to a tree (um the CS kind with the trunk at the
top).

> > General directed graphs are useful beasts, but I think they are overly
> > general for a trouble ticket system.
> 
> It's a general approach, and I love it.

But then the algebra of the system is more complex.

> > They also bring up dependency problems that we couldn't find firm
> > rules for at my previous job (we didn't want
> > people solving the relationship issue in an ad-hoc fashion).
> 
> I haven't encountered any problems with our dependency model, 
> and I can't see much problems with it anyway.

Well one issue I see is that you can't close ticket1 when you close ticket3
in the
example above. Sending email on ticket3 that the problem is solved isn't
true for ticket1 because s/he still want's a fee reduction which may or may
not be done.

How do you handle that issue? The easiest way would be to enforce no ticket
is closed till all of its dependents are closed, but it breaks the rule that
a group ticket closing closes all its components.

Wait a sec. I just thought of a different way of looking at it that I think
is your view. Lets see now. A group ticket is just a derived ticket from
multiple user tickets. So I guess you only have to define derived tickets,
and component tickets are merely a derive link looked at in reverse (from
the group ticket). Actually with this definition the rule for closing
tickets at the next higher level can simply be:

	if the ticket I'm derived from has no unresolved derived tickets,
		resolve the ticket I'm derived from.

That would still leave ticket 1 open till ticket 4 was resolved and
resolving ticket 4 would resolve ticket 1. 

Still doesn't address reply's to ticket3 tickets are closed when they
aren't, but that might not be a big deal since the linking of ticket 1 to
ticket 3 should generate a message to ticket1's requestor notifying him of
the change, so that s/he know to look at the new ticket for further
information.

-- rouilj