[rt-devel] Linking actions (for 2.0)

[Jesse]

On Fri, Apr 14, 2000 at 01:57:20PM +0200, Tobias Brox wrote:
> 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).
>
I'd sort of rather that we not use "Stalled" for that, but that we 
actually figure out what tickets are dependent on a given ticket at runtime.

 
> 
> <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.
> 
I disagree. MemberOf shouldn't automatically resolve either BASE or TARGET.
There should be a way to "Resolve all members" or somesuch, though

> 
> <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.
> 
The thought was that for 2.0 "merging" should become just another linking type
that did intelligent things with the requestors for each ticket, to make
it easier to track history, among other things.

> 
> <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).
> 
Hrm. If you did this, then I could set things up to not perform the weird
actions :)

> It's possible that we will need more linking actions, but not until
> after 2.0, I'd daresay.
> 
*nod* I'll buy into that.
> 
> 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".
> 
>
Interesting. I'm actually hoping to have a better inter-instance communication
story at some point in the future. But the auto-linking could be quite cool.
what links were you thinking of?
 
> 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?

Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don't think that would suck too badly

-- 
jesse reed vincent -- jrvincent at wesleyan.edu -- jesse at fsck.com 
pgp keyprint:  50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
--------------------------------------------------------------
 "That package looks like what I wanted, but the site was down today, 
   so I decided to reimplement it in Perl."
							-me