[rt-devel] Linking actions (for 2.0)

[Rouillard, John]

I am off to Boston for a copuple of weeks, so I won't be able to participate
in this discussion till I come back on 12 May.

Jesse said:
> On Fri, Apr 14, 2000 at 01:57:20PM +0200, Tobias Brox wrote:
> > 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.

I used to be in your camp Jesse, but I think Tobias's scheme of stalling the
BASE has some merit. Stalling means: "don't work on this ticket until
something changes". So it implies that new transactions shouldn't be added
to that ticket, instead they should be added to the tickets created as
targets of the DEPENDSON links.

Also, if it can be done through a script, then its a non issue. The admin
(if s/he wants it stalled) simply puts the DependsOn script in place that
stalls the base ticket. See below for another possibile way to handle this.
Which should be the default, I'll let you two battle over. BTW just what
does the API for the Scrips (is that a typo? should it be Scripts?) systems
look like? One monoloithic script that handles all linking actions could
have an CLI like:

  linkscript BASEID TARGETID action OtherArgs

where action would be:  CreateLink, TargetIsResolved, DeleteLink,
NewBasePriority,
NewTargetPriority .... OtherArgs affect the operation of the linscript e.g.
StallBaseTicket. The linkscript that implements appropriate linking actions
(distribution scripts written in perl of course) does all the real work
using the perl api's. If the user wants other types of links, fine. They can
write them in whatever language they want using the rt cli to do the actual
operations in rt.

Or you can split each action to its own script:

  linkscript.create BASEID TARGETID
  linkscript.TargetISResolved BASEID TARGETID
  ...

I'd argue for a monolithic script. They can always write the big script to
call subscripts and exec the subscripts.

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

Maybe another link type? There is nothing to say that there can't be
multiple links between two tickets. Remember that actions/relations are
implied by the links.
A link that causes the BASE to be resolved when the TARGET is resolved may
very well be a separate action that they want performed. I'll agree that
displaying
multiple links in a rational way is a bit tough, but I think it adds a lot
of flexability to the system. I'll see if I can come up with some ascii
visualization method that will work.

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

Agreed. MergeInto definately should have the semantics that resolving TARGET
also resolves BASE if BASE isn't a base for links whose tickets are open.
The exact semantics gets a bit tricky here, because closing a BASE for a
simple link has no
ramifications, but closing a BASE for a DEPENDSON link whose target isn't
closed
is a problem. Again this can be handled by changing a small script rather
than by changing the core code, so its not as big a deal as it could be.

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

Just the ability to print the simple links given base or target ticketID's.

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

Cool. That would make it a nice modular system that was easy to adapt.

> Hrm. If you did this, then I could set things up to not 
> perform the weird actions :)

Agreed. Actions should be linked to link types and be modifyable at the end
site, not built into the core.

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

Agreed. I think all of the 4 types of links I identifed have been covered.

The ID's should be animals that can be given to RT directly (either in perl
or
command line), or they should be parsable into method, host, id, args quads.
I think URI's are perfect:

  method://host/IDHERE?args?args?args

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

What about an ANSWERLINK that looks like:

	kbfaq://kbfaqserver/....

the : will immediately determine that its not a local rt link (they consist
only of numbers). The kbfaq implies that some kbfaq method of access has to
be used. Not being familiar with kb/faq I hesitate to elaborate further.
There may be some times of links that shouldn't or can't be made remotely.
E.G for development use a link to a file may be represented as:

   file://localhost/nfs/harbour/testcases/badtests/output.19990302.caseA

This isn't any worse than links to other databses, or rt instances. All of
them have the problem that there is no way to insure that the TARGET of a
link exists.

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

How about something like:

  RemoteRTLinkMail
	mailto:rt at mailhost?[RT%20#74]:%20this%20is%20a%20ticket%20subject

then mail could be used (granted the email gateway will have to be expanded
a bit)
to do remote manipulation etc. Similiar links could be set up for:

  RemoteRTLinkWWW
http://remotehost/rt/webrt.cgi?serial_num=104&display=History

and

  RemoteGnatsLink 
	mailto:gnats at mailhost?[gnats%20subject%20line%20with%20tag]

the list is endless. I do think that the URI format can be used to encode
the proper info. What to do with the info, or how to display it can be
shifted off to scripts as well:

   RemoteGnatsLink LOCALRT_TICKET_ID TargetGnatsLinkURL DisplayTarget
WEBPAGE

and DisplayTarget target can do:

 return a real URL that can be clicked on maybe with < A href=...> </A>
markers.

 text explaining how to access it manually for dummy access methods.

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

I would write the fsck.com-rt link as either:

   mailto:rt at fsck.com?....

or
   http://fsck.com/rt/...

as I have above. Both are perfectly resolvable, and can be further
manipulated into url's that will work. Also the DisplayTarget (and maybe
DisplayBase) code can do arbitrary mapping even turning fsck.com-rt:... into
one of the above forms.

-- rouilj