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

[Tobias Brox]

> Agreed. I think you already have a "dead" ticket status that can be used for
> that.

Yep.  In our locally hacked version of rt 1.0, killed requests are never
physically deleted.

> Transitivity I think is implicit both ways. Both as dependency (component)
> and as derived tickets. That's why I suggested the tree structure in my
> original message. The problem comes in where you can have loops, then
> transitivity isn't true, and where to assign the tickets is no longer
> obvious (well obvious to me 8-).

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.  Anyway, I think
nothing really bad can happen if somebody creates a loop on mistake.

In our locally hacked RT, an open request always indicate that somebody
has to do some work.  The workflow works quite well, I don't know of any
incidents where a ticket have just been lost in the system.

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.

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

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

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

> 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.

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

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.

> 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.

> 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.

> 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.

> 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.

> One other thing I haven't seen mentioned is searching ticket text (like
> reqglimpse). That was very useful when new people had to solve problems.
> They would do a reqglimpse looking for certain words and see what the old
> tickets had to say. It was a great learning/teaching tool. It was wonderful
> for help desk people.

In addition for plain textsearching in the database, Jesse also have a
Knowledge Base system witch eventually will be better linked up to RT.  It
doesn't work very well as of today, but the concepts behind it is 
just brilliant.

-- 
Tobias Brox (alias TobiX) - +4722925871 - _urgent_ emails to
sms at tobiasb.funcom.com.  Check our upcoming MMORPG at 
http://www.anarchy-online.com/ (Qt) and play multiplayer Spades, 
Backgammon, Poker etc for free at http://www.funcom.com/ (Java)