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

[Jesse]

On Sat, Mar 25, 2000 at 05:55:01PM -0500, Rouillard, John wrote:
> 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. 
> 
>

Well, it probably defaults to rt://instancename/ticket/<id> but yeah.


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

It is a grouping operation. but it is a distinct linktype. (Think of it as grouping
a project's subtasks together) member could also easily be called child.

	what tickets are members of ticketA 
 
> > > 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.
>

 
Well, a local site is free to do whatever it wants. But the standard setup 
within the RT core will be done in perl

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

Give it a week or two to settle down.

> 
> 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.
>
Probably not for 2.0. Lets leave the 'ultimately generalizable linking' for 
a rev slightly after 2.0
 
> 
> 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?
>

Don't worry. the CLI will continue to be everything you need to use RT to its
full potential. Deb Kaplan has recently offered to spec out a CLI that's genuinely
usable (unlike RT's current monstrosity ;)  Oh. and it's called xrts, not tkrt.
Steve Rader wrote it. it's in ftp://ftp.fsck.com/pub/rt/contrib ;)

 
> 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>
That sounds reasonable. but really it's an extension, not a redesign.  it shouldn't
 be too hard to hack. Check out the cli manipulate code for 2.0 and bounce me a patch :)

 
> -- rouilj
> 
> P.S. Jesse, I haven't seen any comments from you have I missed them?
> 
>
I've been fairly quiet. Tobias and I have similar feelings on linking and I've
been pretty busy

-- 
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
--------------------------------------------------------------
And I'm told we do share some common rituals. Our "flame war" is apparently 
held in person in their land and called "project meeting".
					-Alan Cox [on "Suits"]