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

[Tobias Brox]

> 	That's a very good idea. This then allows people to extend RT with
> site specific tickets or ticket logic while still enabling the overall
> system to be useful out of the box. The fun then becomes figuring out how
> to deal with the marshaling of information between a ticket object and
> the DB.	

My idea about this is to set up extra tables having site-specific data or
data specific to some special kind of Ticket.

> 	I was thinking that given a ticket X and two dependent sub tickets
> Y & Z, logic is going to need to exist so that if someone kills/deletes X
> from the system Y & Z then also disappear or something else appropriate
> happens to them. 

With my idea, it's possible to kill ticket X and then have a check-box
that might be checked if the WebRT user wants to kill Y & Z also.  I don't
really think it's a problem in this case that "orphans" might be produced.
If anybody should try to accessing the ticket Y or X is dependent on, it
should be handled as if he/she tried accessing any other killed object.
It's not handled very nice in 1.0.

Apropos killings, I think it makes sense to just change the status, and
not actually kill it ... and then have a cleanup tool which might be used
on old tickets whenever we run low on disk space.  As I see it, that's the
only problem we have with storing killed requests/tickets, maybe with an
exception of if it's something secret/private that really shouldn't be
seen by other users of RT.

> I was mainly trying to get at some of the complexity
> involved in keeping the relationships between tickets in a known good
> state.

With my suggestions, nothing really bad will happen if the linking breaks
somehow.  I don't think it will be needed to do stuff recursively, I only
think it will be needed to do things on a ticket and the dependent
tickets.  So a loop will be harmless, though it usually won't make any
sense to have a loop (and eventually we should have a test on this).

If a ticket that is linked up "both ways" is killed, then there might be
some problems handling that.  I think it might be wishable that if ticket
A is dependent on ticket B is dependent on ticket C, and ticket B is
killed, A should be dependent on C.

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