[rt-devel] Action models, links between tickets etc.

[Tobias Brox]

> > The source and dest is not always ticketID ... we will at least need:
> > - links to external RT instances
> > - links to other tables in mysql
> > - links to external web based databases
> 
> I have to admit I don't see the utility of these other links

For one thing, we have a knowledge database which we're using locally. 
It's very nice to be able to link it up to tickets.  Many of the replies
from the support is made semi-automaticly with information from the KB.
It would be silly not to "make a link" at the same time.  It can be used
for statistics, for having a look at what kind of customers that have one
particular problem, etc.

One of our teams here use Bugzilla for their bug tracking ... so we're
going to make a linking action for it.

Eventually we could deal with both bugs and articles in the knowledge base
as "tickets", but eventually we will need to store more attributes than
what a standard ticket has, 

> since
> imformation flow back from them would be via a standard RT mechanism such as
> CLI, email etc, but to allow for generality rather than ticketID we use
> ticket URI, which default to ticket ID in the case that we are referencing
> internal tickets to this RT instance. 

Well, quite many wants to let external requestors use the WebUI to track
their tickets.  It's quite thinkable that there can be a communication
between two companies or two departments that both use RT, but running at
different servers.  It would be great to let a WebRT user tracking a 
ticket easily move from one RT instance to another.

> Hmm, MemberOf sounds more like grouping/set type operations not linking. I
> would think semantics of memberof would be:

"Grouping" and "Linking" might have strikingly similar features.  I feel
quite sure that Jesse's thought about "MemberOf" is similar to your
thoughts about the relationship between tickets (complaints from user
about the mail server beeing down) and a group ticket (telling the
sysadmin that the mail server is, indeed, down).

> These email semantics could be defined in terms of source and destination
> tickets (ticket URI ...) and then associated with any number of links in the
> LinksDefinition table. So if somebody created a new link type, it could
> benefit from the same email distribution semantics as a mergeLink.

I have tried making a table for "link definitions" (like MemberOf vs
NoAction vs Dependency), and it seemed like no good idea, we should rather
do it object oriented, and hard-code different behaviour by subclassing. 

...but URIs should be in the database.  I think it might make sense to
have one link table which tells base ID and target ID, which is the ticket
ids (or similar ids for other databases), "Type" (what kind of link it
is), but also source and destination which either points to the URIs of
the other installations (or NULL for the local RT system).

Jesse has suggested to form URIs like rt://server/path/ticketid ... which
I think might be a good idea ... though it would be nice to be able 
to extract both the mail address and the web address through the URI.

Your mail was really large, I'll have to print it out and come with some
comments.  It is of course nice to get design ideas from several minds ... 
at the other hand, this seems like a costly, escalating email thread.  I
do have bad experiences with such - email discussions aren't always the
most efficient mean of design planning.

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