Action models, links between tickets etc


#1

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.

The examples below are meant to be /bin/sh scripting, but I probably
have syntax errors. Also I am trying to use the rt 1.x commands, but
some extensions are used (e.g. link query syntax), but I don’t have
any rt docs available as I write this. Also rtq -format uses field
names rather than the proper format strings.

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

sourceTicketId destTicketId

by using rtq and rt, all other information about the tickets can
be obtained including ticket states, priorities etc. The
tobiaslink.create script may look like:

stall original ticket when a new ticket is spawned from it

rt -stall $sourceTicketId
-summary “stalled by tobiaslink to $destTicketId”

set a default due date on the new ticket iff it has not been set.

if [ “rtq -noheader -format 'duedate'” == “” ] ; then
rt -due prtdate +2weeks $destTicketId
fi

When the destination (spawned) ticket is resolved, the script
tobiaslink.resolved is called with the sourceTicketId and
destTicketId. The script can look like:

open the source ticket if it is still stalled.

if [ “rtq -noheader -format status $sourceTicketId” == “stall” ]; then
rt -open $sourceTicketId
-summary "Reopened by tobiaslink to ticket $destTicketId"
fi

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

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. 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) 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. In
the example of a full mail spool I can create a ticket “fix the stupid
mail spool” and mergelink my 47 tickets to it. When I resolve the
ticket, all 47 tickets that link to this ticket get resolved if no
other links from those tickets are unresolved. The script to do that
may look like:

mergelink.resolve

make sure that $sourceLinkId doesn’t have any linked to tickets

that are still open. Iterate over destination ticket ID’s for

links that aren’t noaction links. Finish with the destLinkId that

triggered calling of this script.

for i in rtq -noheader -format 'dest' -notlinktype noActionLink \ $sourceLinkId $destLinkId
do
if [ “rtq -noheader -format "status" $i” != “resol” ]; then
break;
fi
done

if [ $i -eq $destLinkId ] ; then

# $i was set to the link that triggered this script therefore
# all other links must have been resolved.
rt -resolve $sourceLinkId \
	-summary "Autoresolved by merge link to $destLinkId"

fi

The rt -resolve command would force rt to analyze $sourceLinkID as the
destination of mergelinks and call this script recusively if needed.

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:

srcprio=`rtq -noheader -format prio $sourceTicketId`
dstprio=`rtq -noheader -format prio $destTicketId`
# propigate change in priority along merge links.
# so that priority of destination is the same as the source
# with the highest priority.
if [ $srcprio -gt $destprio ]; then
   rt -prio $destTicketId $srcprio
    fi

All rt has to provide is to call the hooks on link creation and for
each link to a ticket being resolved. In fact different link types can
be used between tickets. This allows resolution of a single ticket
(say ticket 3) to reopen some tickets (say ticket 1) and resolve other
tickets (say ticket 2 and 4), depending on whether ticket3 was a
prerequisite for solving ticket1, or was the solution to the problem
(ticket 2 and 4).

To further clarify this how about an example.

ticket problem
1 can’t connect to hosts with netscape
2 ping is broken
3 Can’t send email: error no space on spool/mqueue

You have the above in the queue. You realize that DNS is down. Spawn
a ticket

4 DNS is down

mergelink 1 and 2 to it (if you choose to stall 1 and 2 automatically
feel free, its just a shell script change). The person working on 3
has come to the conclusion that outgoing mail is backing up because of
the DNS failure. She has cleared space by copying the mail queue to
another disk, but can’t really get email working till DNS is up. So
she does a tobiaslink to ticket 4 stalling ticket 3.

We finally get DNS working and resolve ticket 3. What happens? Tickets
1 and 2 are resolved and email is sent to requestors notifying them of
the resolution. Ticket 4 is reopened and the person working on it
starts flushing the mail queue and the moved mailq by hand.

In addition to the above other semantics such as propigating the
highest priority down the chain can be done by calling a script on any
action e.g:

   mergelink.doSourceaction sourceTicketID destTicketID prio

when priority is changed on the sourceTicket. A script like this may
be appropriate:

case $3 in
prio)
srcprio=rtq -noheader -format prio $sourceTicketId
dstprio=rtq -noheader -format prio $destTicketId
# propigate change in priority along merge links.
# so that priority of destination is the same as the source
# with the highest priority.
if [ $srcprio -gt $destprio ]; then
rt -prio $destTicketId $srcprio
fi
esac

If the rt command is executed, the rt program will need to look at all
of the links with source $destTicketId and call apropriate action
programs on them. In this way the link tree can have data propigated
across it.

The scripts themselves can be written in any language, sh, perl, tcl,
python etc. All interactions with rt are done via 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 pseudoarguments to rtq and rt are described below:

RTQ
-noheader suppresses rt headerlines leaving only the data.
-source treat ticket id as source ticket in link lookups (default)
-dest treat ticket id as destination ticket in link lookups.

RT
-summary allows a one line comment to be included in all transactions

– rouilj


#2

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” :slight_smile:

(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 …) :wink:

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

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

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

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@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)


#3

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” :slight_smile:

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

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

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?


#4

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

For one thing, we have a knowledge database which we’re using locally.
It’s very nice to be able to link it up to tickets. Many of the replies
from the support is made semi-automaticly with information from the KB.
It would be silly not to “make a link” at the same time. It can be used
for statistics, for having a look at what kind of customers that have one
particular problem, etc.

One of our teams here use Bugzilla for their bug tracking … so we’re
going to make a linking action for it.

Eventually we could deal with both bugs and articles in the knowledge base
as “tickets”, but eventually we will need to store more attributes than
what a standard ticket has,

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, quite many wants to let external requestors use the WebUI to track
their tickets. It’s quite thinkable that there can be a communication
between two companies or two departments that both use RT, but running at
different servers. It would be great to let a WebRT user tracking a
ticket easily move from one RT instance to another.

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

“Grouping” and “Linking” might have strikingly similar features. I feel
quite sure that Jesse’s thought about “MemberOf” is similar to your
thoughts about the relationship between tickets (complaints from user
about the mail server beeing down) and a group ticket (telling the
sysadmin that the mail server is, indeed, down).

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.

I have tried making a table for “link definitions” (like MemberOf vs
NoAction vs Dependency), and it seemed like no good idea, we should rather
do it object oriented, and hard-code different behaviour by subclassing.

…but URIs should be in the database. I think it might make sense to
have one link table which tells base ID and target ID, which is the ticket
ids (or similar ids for other databases), “Type” (what kind of link it
is), but also source and destination which either points to the URIs of
the other installations (or NULL for the local RT system).

Jesse has suggested to form URIs like rt://server/path/ticketid … which
I think might be a good idea … though it would be nice to be able
to extract both the mail address and the web address through the URI.

Your mail was really large, I’ll have to print it out and come with some
comments. It is of course nice to get design ideas from several minds …
at the other hand, this seems like a costly, escalating email thread. I
do have bad experiences with such - email discussions aren’t always the
most efficient mean of design planning.

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@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)


#5

I’m not going to comment on Linking models right now. there’s just too much there
for me to deal with right now, though I must say that the conversation
has been useful

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.

No. Among other things, tickets of different types may eventially have different
attributes and different UI associated with them

If the rt command is executed, the rt program will need to look at all
of the links with source $destTicketId and call apropriate action
programs on them. In this way the link tree can have data propigated
across it.

The scripts themselves can be written in any language, sh, perl, tcl,
python etc. All interactions with rt are done via the CLI.

While I agree that all ticket manipulation must be possible from the CLI,
the RT core and associated actions will be written in perl. At least for 2.x.

I’d like to hold off on the advanced state change on link manipulation stuff
for now, as if we go that route, I’m afraid we’ll never get it out.

jesse reed vincent – jrvincent@wesleyan.edujesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
This is scary. I’m imagining tracerouting you and seeing links like “Route
84” and “Route 9, Exit 14”. Obviously, this is illness induced.
–Cana McCoy


#6

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/ 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 :slight_smile:

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 :wink: Oh. and it’s called xrts, not tkrt.
Steve Rader wrote it. it’s in ftp://ftp.fsck.com/pub/rt/contrib :wink:

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

– 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@wesleyan.edujesse@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”]


#7

I’m an expert on forgetting printouts at the printer…so I still haven’t
had the time reading through your mail. Will do it later …

My top priority now is to get a working 1.3 that can be demonstrated and
tested locally. It won’t have all the features, it won’t have the admin
tools, it won’t have support for other DBs than mysql, but it should work,
and it should have a Web UI. As long as we can achieve this goal with the
current design, I will not spend more time on design discussions until 1.3
is eventually out. I hope it will be “tomorrow” (that is Tuesday or
Wednessday … I’ll tell you which timezone “tomorrow” applied to when
we eventually get 1.3 out :slight_smile:

I think it would be great if the design discussions actually proved
useful, I’ve been into projects earlier where several weeks has been
wasted discussing design and writing several hundred kilobytes of emails
before a single line of a design document was written … and eventually
the email threads continued after writing the first line of the design
document.

Please check out rt/docs/design_docs with the rt-1-1 tag. If you have
just small comments or things to be added, include your comment in
brackets and send me a patch. If you think whole concepts are flawed,
we’ll discuss it by email. If you’re seriously thinking that it’s very
important that we need to do things differently for 1.3, yell out loudly.
I’m more in favor of finding out (through testing the 1.3 version) what
actually works and what doesn’t work before continuing this design
discussion.

Tobias Brox (alias TobiX) - +4722925871 - urgent emails to
sms@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)