[rt-devel] Linking actions (for 2.0)

[Tobias Brox]

Well, I should implement the links now.  I feel like to request some
help from your wetware about this.

I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:

<BASE> DependsOn <TARGET>

...meaning that TARGET has to be resolved before BASE (really) is
resolved.  A stalled BASE should be reopened when TARGET is resolved.
When "spawning" a new TARGET i.e. through the web interface, the BASE
should be stalled (if it's open).

As earlier mentionated, we've implemented this in our version of RT
(1.0), and it's working as a charm.  Anyway, the support team often
resolves the incoming request (BASE) before "spawning" a new TARGET.
It's typically a user reporting a problem, and the problem has to be
resolved - though we don't want to notify the user when the problem
actually is solved.  It might make more sense to use a RefersTo link
in that case.


<BASE> MemberOf <TARGET>

This means that when TARGET is resolved, all BASE is automagically
resolved.  When a support worker sends correspondence on a TARGET, all
BASE requestors should receive the correspondence.  If all BASEs are
resolved, TARGET should automaticly be resolved.


<BASE> MergedInto <TARGET>

This is Jesses domain.  I'm not sure if it makes sense to have this as
a link.  Anyway, it should me the same as the "merge" of today.


<BASE> RefersTo <TARGET>

A "simple" link, just stating that two things are related somehow.  It
shouldn't have any special behaviour.


I think the behaviours mentionated above can be executed through the
Scrips system.  I think the system, as it is in the current CVS
version, is good enough (though more documentation is needed to be
written).

It's possible that we will need more linking actions, but not until
after 2.0, I'd daresay.


BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.
Most important for us now is to get links between RT and the KB/FAQ
system (must be handled especially in the web interface; we want it to
be possible to easily launch semi-automatic answers through the web
interface) and between RT and Bugzilla.

The mailgate should automaticly detect mail from other RT instances
and set up a link.  Communication between two RT instances should
mainly be done through the mail gateway.  It might make sense to allow
web users to access remote RT instances "seamlessly".


Here's the table from the current CVS/schema:

# {{{ TABLE Links

CREATE TABLE Links (
  id int(11) AUTO_INCREMENT PRIMARY KEY,
  Base VARCHAR(255),
  Target VARCHAR(255),
  Type char(20) NOT NULL, # 
  Creator INT(11),
  Created TIMESTAMP,
  LastUpdatedBy INT(11),
  LastUpdated TIMESTAMP
)\g

Type is one of "DependsOn", "MemberOf", etc.

BASE and TARGET is shaped like URLs.  This is one of the things I'd
like to discuss.  Here's Jesse's idea:

fsck.com-rt://instancename/ticket/<id>

Well.  I'm a bit positive, but I'm absolutely not sure.  The "url"
above can't be used for anything, as long as it doesn't contain more
data about how to communicate with (instancename).  It might be a good
idea to have something like this if there exist a mapping from the
instancename to such information somewhere.  Anyway, I wouldn't call
it an "URL", as it is "broken" without this extra information.  Any
thoughts?

I thought of implementing a Link class with possibilities for
subclassing it.  As mentionated, "link behaviour" is to be pushed to
the scrips system.  I haven't thought much of it, but it should be
quite so possible to fix an Action which call an arbritrary shell
script.  I also agree that all relevant things should be possible to
do through the CLI, but I'm not willing to spend time and resources
myself on fixing the CLI.

Another thing; all linking actions should be (easily) available
through all interfaces, and it should be possible to add linking
actions as well as new external databases and similar to link to
without having to do any work with all the separate UIs at all.  I
think that is a major challenge which I'm happy to postpone until
after the summer..

-- 
Tobias Brox 
aka TobiX
+47 22 925 871