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

[Rouillard, John]

> I also think that the single "dependency" link as I've described might
> deal with almost all thinkable needs regarding workflow and 
> information flow.

It should definately be one of the link types supported out of the box.
However I can see people wanting to tweak the information flow.

> > I assume that links point from a source to a destination.  Further I
> > assume that the database has a table called link with fields, data
> > types of:
> > 
> > 	linktype   string
> > 	source     ticketID
> > 	dest       ticketID
> >   LinkInfo   string
> 
> 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 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. 

rouilj> > The actions Tobias describes, stalling a ticket when it links to a
> > newly spawned ticket and opening the parent ticket when the spawned
> > ticket is resolved can be handled by a tobiaslink. When a tobiaslink
> > is created, an external script called tobiaslink.create is called with
> > the following arguments:
> 
> Well, we have actually discussed most of the aspects with the 
> "tobiaslink"  earlier on this list,
...
> I think it will make more sense to call it a "dependency" :)

Ok.

> The new things is that it should be possible to send mails to the
> dependent requestors, and that it should be possible to change the status
> of dependent requests from the UIs.  Anyway, it seems to me like Jesse is
> going to make a "MemberOf" linking action which defaults this behaviour.
> Well, it might make more sense anyway.

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

	is ticketA a memberof tickets linked to ticketB

> > by using rtq and rt, all other information about the tickets can be
> > script may look like:
> 
> Sorry, site-specific linking actions must be done in perl :)

I know you put a smiley there, but I have to disagree.
 
> It might be done even today by using the Scrips/Action 
> system, though I don't really think it's the Right Place to put such stuff

> anyway.  I had thought of subclassing a Link class.

Great minds think alike.

> > Also, a noActionLink can be used to link a "buy more disk for mail
> > spool space" to the 47 tickets reporting that mail isn't being
> > delivered because your out of space. A noActionLink does exactly what
> > its name implies. The noactionlink.create script is empty as is the
> > noactionlink.resolved script. As Tobias said there are some spawned
> > tickets where the requestor of the original ticket doesn't need to be
> > kept up to date.
> 
> It can be done by resolving or reopening the original request while
> "spawning" a dependency.  Well, not a very elegant solution, maybe
> "noActionLink" deserves to be taken into consideration.

Agreed. NoActionLink basically is a link that says, "these two tickets are
related in
some way that doesn't require any action". My example below was the
initiating event for the noaction link.

> > You want to see how many complaints have been caused
> > by this ticket not being solved, its a one line shell script:
> > 
> >        rtq -noheader -linktype noactionlink -format sourceTicketID \
> > 	   -dest <ticketID> | wc -l


> It seems to me that Jesse is going to handle (ordinary 1.0'ish) merges by
> using a MergeLink.  Merges are complicated, and it's still buggy in the
> 1.0 series, I guess doing it as a link action will improve it slightly.
> Anyway, it's still a complicated matter which I'm quite happy to leave to
> Jesse :)
> 
> > that has the semantics
> > of resolving source tickets when the destination ticket is resolved if
> > the source ticket doesn't have any unresolved destination tickets.
> 
> ...and that a reply to the new ticket will go to all old requestors.  I
> think this will be the MemberOf linking action in 2.0.

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

  MergeLink_MailRule defined as:

	transactionType for link destination:
	respond -> send to source requestor
      respond -> record in source ticket
      comment -> ignore
      stall -> ignore
      ...

  MailRule3 defined as:
      transactionType for link destination

	respond -> send to source requestor
	respond -> record in source ticket
      respond -> send to queue maintainers
	comment -> send to queue maintainers

( I have been watching your scripts/email stuff with interest, but I am
afraid I just don't get it. I'll have to get the newest sources and look
through them.) Then when the link is defined we have:

	LinkType: Mergelink2
	MailPropagation: MailRule3
      Link_CreateAction: Links/Actions/MergeLink2.create
      Link_ResolveAction: Links/Actions/MergeLink2.resolve
	...


> MemberOf will resolve recursively.  Loops (which we agree shouldn't occur 
> ... but I don't think it's that important to create loop checks) will
> anyway be harmless as it's impossible to resolve a ticket twice.

For resolution, yes you are correct, but information flow can go on forever
because there is no state retained to stop the loop. E.G.

    ticket1 > ticket2 > ticket3 > ticket1

all use MailRule1 as above. Send a reply to ticket 3. Watch mail server run,
see mail server run, watch mail server die, because without loop checks, the
response sent to ticket 3 will never end.

The response to 3 will be sent to the requestor of ticket 2 and entered into
ticket 2. Then it will be sent to the requestor of ticket 1 and entered into
ticket1, which will then be sent to the requestor of ticket3 (because of the
link from ticket 3 to ticket1) and entered, which will then be propigated to
ticket 2 and so on.

This loop can be stopped by terminating when we would cross an already
crossed link, or 
we have come full circle and are about to have our destination become the
source (ticket 3 above).

> should neither resolve requests which are members of other unresolved
> requests and/or are dependent on unresolved requests.  The 
> last two might  demand some complexity (particularly if people are free to

> add new linking actions as they like).

Agreed, but the logic is in the scripts that are external to the rt core.
The rt administrator can always create a new link type called mymerge and
use it rather than merger, or s/he can change the merge actionscript to
respect a new link type.

> > In addition for mergelinks, the priority of the destination should be
> > the same as the source with the highest priority, so I create the script
> > mergelink.create to contain:
> 
> Modify it to "should not be lower than", and I agree it might be a good
idea.

Again this is something that can be handled on a site by site basis. We
defer making those decisions by not building it into the rt core.

> > The scripts themselves can be written in any language, sh, perl, tcl,
> > python etc.
> 
> Nah ... better do it in object oriented perl.  People who  don't know perl
> can always ask/hire somebody else to do it. 

I have to strongly disagree here. While it may be less efficient to have to
work in another language and go through the CLI, this allows a lot of
experimentation and adaptation to be done without a lot of expense or a
large learning curve.

> > All interactions with rt are done via the CLI.
> Slower and less flexible.

Slower, definately, but I can perform setting an automatic 2 week due date
upon a dependency in 20 seconds by adding one simple command line leveraging
tools I already have. Later, after I am sure it is a good idea to do it, I
can implement it in perl and speed things up, but for most sites a proptype
implementation will easily fill the bill.

Less flexible, not really. Think of RT as an object where its CLI is the
API.
I manipulate the object via the CLI, so anything that I need to do should be
accessible via the CLI.

> Besides we end up discovering that we have to add a lot of complexity to
the CLI.

If I can't carry out all actions via the CLI then rt is useless as far as I
am concerned. I can't automate if certain actions are available only through
the web. As I said above, the CLI is effectively an API for calling rt from
anything else (e.g. tk/tcl, MS-DOS batch file etc). Anybody up for tkrt?

A would also like to see the CLI changed a bit to a single event/action
instance. Right now each argument takes a ticket number. So that 

	rt -resolve 25 -stall 13

is a valid command line. I think this sort of action occurs less frequently
than:

	rt -resolve 24 -resolve 23 -resolve 14

what I suggest is:

     rt <action> <ticket numbers>

so

	rt -resolve 24 23 14

or
	rt -linktype merge -destination 16 1 2 45 87 9 10

to mergelink 1, 2 ... to ticket 16. This new CLI syntax better follows
(IMHO) standard unix syntax in that the objects being operated on stand
alone on the command line.
It also makes things like assigning bunches of tickets much easier to do
when generating ticket numbers as the result of an rtq search. E.G.

	rt -user rouilj -give `rtq -owner stevens -area MAC -format "%n"`

to batch move ticket to rouilj from stevens because stevens has been fired.
Why should I have to fire up mysql and try to figure out the SQL code to do
this?

-- rouilj

P.S. Jesse, I haven't seen any comments from you have I missed them?