[rt-devel] Action models, links between tickets etc.
jesse at fsck.com
Sun Mar 26 15:34:34 EST 2000
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
> 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"]
More information about the Rt-devel