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

[Tobias Brox]

> Tobias and I have differing expectations of what links should do, and
> what actions should occur. Here is what I propose. Rather than having
> multiple types of tickets (bugs, tasks, group), have just one ticket
> type. Any ticket can link to or be linked to by 1 or many other tickets.
> However there are multiple types of links. When a link is created, or
> a ticket is resolved (or a change is made to a ticket), an external
> script is called that performs the actions associated with that link
> type. This has the advantage of not imposing a particular action model
> on the rt users, making the system much more flexible and able to be
> tailored to a site's requirements.

Now, this might make quite some sense.  It might obsolete the need of
plug-in transaction types as described in my previous mail.

I also think that the single "dependency" link as I've described might
deal with almost all thinkable needs regarding workflow and 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

> 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, and it works so perfectly in my organization,
and I also have so high expectations that it will work perfect in
other organizations as well, that I think it will make more sense to call
it a "dependency" :)

(I don't want to scare people away from using it.  Quite some people
already get bad associations from terms like "tobiasfood" (hey, I am
really a good cook ... some people is just a bit slow to realize it
;), "tobiasdriving" (hey, I'm a good driver.  Just wrecked some few cars,
that's all), etc ...)   ;)

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.

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

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.

> I think this implements the actions Tobias is using in his
> system. Tobias feel free to correct me if I have misunderstood your
> system.

It seems correct, or even better.  Didn't have the "default due date in
two weeks" part yet.

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

> 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
> 
> 
> You can also implement a mergelink (my model) 

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.

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

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

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

> All interactions with rt are done via the CLI.

Slower and less flexible.  Besides we end up discovering that we have to
add a lot of complexity to the CLI.

> Quips, comments, suggestions, evasions or answers anybody? This seems
> a bit too simple, so I am pretty sure that there is something I am
> missing.

The simpler the better :)

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