Linking actions (for 2.0)

[Tobias_Brox]

Well, I should implement the links now. I feel like to request some
help from your wetware about this.

I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:

DependsOn

…meaning that TARGET has to be resolved before BASE (really) is
resolved. A stalled BASE should be reopened when TARGET is resolved.
When “spawning” a new TARGET i.e. through the web interface, the BASE
should be stalled (if it’s open).

As earlier mentionated, we’ve implemented this in our version of RT
(1.0), and it’s working as a charm. Anyway, the support team often
resolves the incoming request (BASE) before “spawning” a new TARGET.
It’s typically a user reporting a problem, and the problem has to be
resolved - though we don’t want to notify the user when the problem
actually is solved. It might make more sense to use a RefersTo link
in that case.

MemberOf

This means that when TARGET is resolved, all BASE is automagically
resolved. When a support worker sends correspondence on a TARGET, all
BASE requestors should receive the correspondence. If all BASEs are
resolved, TARGET should automaticly be resolved.

MergedInto

This is Jesses domain. I’m not sure if it makes sense to have this as
a link. Anyway, it should me the same as the “merge” of today.

RefersTo

A “simple” link, just stating that two things are related somehow. It
shouldn’t have any special behaviour.

I think the behaviours mentionated above can be executed through the
Scrips system. I think the system, as it is in the current CVS
version, is good enough (though more documentation is needed to be
written).

It’s possible that we will need more linking actions, but not until
after 2.0, I’d daresay.

BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.
Most important for us now is to get links between RT and the KB/FAQ
system (must be handled especially in the web interface; we want it to
be possible to easily launch semi-automatic answers through the web
interface) and between RT and Bugzilla.

The mailgate should automaticly detect mail from other RT instances
and set up a link. Communication between two RT instances should
mainly be done through the mail gateway. It might make sense to allow
web users to access remote RT instances “seamlessly”.

Here’s the table from the current CVS/schema:

{{{ TABLE Links

CREATE TABLE Links (
id int(11) AUTO_INCREMENT PRIMARY KEY,
Base VARCHAR(255),
Target VARCHAR(255),
Type char(20) NOT NULL, #
Creator INT(11),
Created TIMESTAMP,
LastUpdatedBy INT(11),
LastUpdated TIMESTAMP
)\g

Type is one of “DependsOn”, “MemberOf”, etc.

BASE and TARGET is shaped like URLs. This is one of the things I’d
like to discuss. Here’s Jesse’s idea:

fsck.com-rt://instancename/ticket/

Well. I’m a bit positive, but I’m absolutely not sure. The "url"
above can’t be used for anything, as long as it doesn’t contain more
data about how to communicate with (instancename). It might be a good
idea to have something like this if there exist a mapping from the
instancename to such information somewhere. Anyway, I wouldn’t call
it an “URL”, as it is “broken” without this extra information. Any
thoughts?

I thought of implementing a Link class with possibilities for
subclassing it. As mentionated, “link behaviour” is to be pushed to
the scrips system. I haven’t thought much of it, but it should be
quite so possible to fix an Action which call an arbritrary shell
script. I also agree that all relevant things should be possible to
do through the CLI, but I’m not willing to spend time and resources
myself on fixing the CLI.

Another thing; all linking actions should be (easily) available
through all interfaces, and it should be possible to add linking
actions as well as new external databases and similar to link to
without having to do any work with all the separate UIs at all. I
think that is a major challenge which I’m happy to postpone until
after the summer…

Tobias Brox
aka TobiX
+47 22 925 871

[Jesse1]

Well, I should implement the links now. I feel like to request some
help from your wetware about this.

I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:

DependsOn

…meaning that TARGET has to be resolved before BASE (really) is
resolved. A stalled BASE should be reopened when TARGET is resolved.
When “spawning” a new TARGET i.e. through the web interface, the BASE
should be stalled (if it’s open).

I’d sort of rather that we not use “Stalled” for that, but that we
actually figure out what tickets are dependent on a given ticket at runtime.

MemberOf

This means that when TARGET is resolved, all BASE is automagically
resolved. When a support worker sends correspondence on a TARGET, all
BASE requestors should receive the correspondence. If all BASEs are
resolved, TARGET should automaticly be resolved.

I disagree. MemberOf shouldn’t automatically resolve either BASE or TARGET.
There should be a way to “Resolve all members” or somesuch, though

MergedInto

This is Jesses domain. I’m not sure if it makes sense to have this as
a link. Anyway, it should me the same as the “merge” of today.

The thought was that for 2.0 “merging” should become just another linking type
that did intelligent things with the requestors for each ticket, to make
it easier to track history, among other things.

RefersTo

A “simple” link, just stating that two things are related somehow. It
shouldn’t have any special behaviour.

I think the behaviours mentionated above can be executed through the
Scrips system. I think the system, as it is in the current CVS
version, is good enough (though more documentation is needed to be
written).

Hrm. If you did this, then I could set things up to not perform the weird
actions

It’s possible that we will need more linking actions, but not until
after 2.0, I’d daresay.

nod I’ll buy into that.

BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.
Most important for us now is to get links between RT and the KB/FAQ
system (must be handled especially in the web interface; we want it to
be possible to easily launch semi-automatic answers through the web
interface) and between RT and Bugzilla.

The mailgate should automaticly detect mail from other RT instances
and set up a link. Communication between two RT instances should
mainly be done through the mail gateway. It might make sense to allow
web users to access remote RT instances “seamlessly”.

Interesting. I’m actually hoping to have a better inter-instance communication
story at some point in the future. But the auto-linking could be quite cool.
what links were you thinking of?

Here’s the table from the current CVS/schema:

{{{ TABLE Links

CREATE TABLE Links (
id int(11) AUTO_INCREMENT PRIMARY KEY,
Base VARCHAR(255),
Target VARCHAR(255),
Type char(20) NOT NULL, #
Creator INT(11),
Created TIMESTAMP,
LastUpdatedBy INT(11),
LastUpdated TIMESTAMP
)\g

Type is one of “DependsOn”, “MemberOf”, etc.

BASE and TARGET is shaped like URLs. This is one of the things I’d
like to discuss. Here’s Jesse’s idea:

fsck.com-rt://instancename/ticket/

Well. I’m a bit positive, but I’m absolutely not sure. The “url”
above can’t be used for anything, as long as it doesn’t contain more
data about how to communicate with (instancename). It might be a good
idea to have something like this if there exist a mapping from the
instancename to such information somewhere. Anyway, I wouldn’t call
it an “URL”, as it is “broken” without this extra information. Any
thoughts?

Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don’t think that would suck too badly

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
“That package looks like what I wanted, but the site was down today,
so I decided to reimplement it in Perl.”
-me

[Rouillard_John]

I am off to Boston for a copuple of weeks, so I won’t be able to participate
in this discussion till I come back on 12 May.

Jesse said:

I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:

DependsOn

…meaning that TARGET has to be resolved before BASE (really) is
resolved. A stalled BASE should be reopened when TARGET is resolved.
When “spawning” a new TARGET i.e. through the web interface, the BASE
should be stalled (if it’s open).

I’d sort of rather that we not use “Stalled” for that, but that we
actually figure out what tickets are dependent on a given
ticket at runtime.

I used to be in your camp Jesse, but I think Tobias’s scheme of stalling the
BASE has some merit. Stalling means: “don’t work on this ticket until
something changes”. So it implies that new transactions shouldn’t be added
to that ticket, instead they should be added to the tickets created as
targets of the DEPENDSON links.

Also, if it can be done through a script, then its a non issue. The admin
(if s/he wants it stalled) simply puts the DependsOn script in place that
stalls the base ticket. See below for another possibile way to handle this.
Which should be the default, I’ll let you two battle over. BTW just what
does the API for the Scrips (is that a typo? should it be Scripts?) systems
look like? One monoloithic script that handles all linking actions could
have an CLI like:

linkscript BASEID TARGETID action OtherArgs

where action would be: CreateLink, TargetIsResolved, DeleteLink,
NewBasePriority,
NewTargetPriority … OtherArgs affect the operation of the linscript e.g.
StallBaseTicket. The linkscript that implements appropriate linking actions
(distribution scripts written in perl of course) does all the real work
using the perl api’s. If the user wants other types of links, fine. They can
write them in whatever language they want using the rt cli to do the actual
operations in rt.

Or you can split each action to its own script:

linkscript.create BASEID TARGETID
linkscript.TargetISResolved BASEID TARGETID
…

I’d argue for a monolithic script. They can always write the big script to
call subscripts and exec the subscripts.

MemberOf

This means that when TARGET is resolved, all BASE is automagically
resolved. When a support worker sends correspondence on a TARGET, all
BASE requestors should receive the correspondence. If all BASEs are
resolved, TARGET should automaticly be resolved.

I disagree. MemberOf shouldn’t automatically resolve either
BASE or TARGET. There should be a way to “Resolve all members” or
somesuch, though

Maybe another link type? There is nothing to say that there can’t be
multiple links between two tickets. Remember that actions/relations are
implied by the links.
A link that causes the BASE to be resolved when the TARGET is resolved may
very well be a separate action that they want performed. I’ll agree that
displaying
multiple links in a rational way is a bit tough, but I think it adds a lot
of flexability to the system. I’ll see if I can come up with some ascii
visualization method that will work.

MergedInto

This is Jesses domain. I’m not sure if it makes sense to have this as
a link. Anyway, it should me the same as the “merge” of today.

The thought was that for 2.0 “merging” should become just
another linking type that did intelligent things with the requestors
for each ticket, to make it easier to track history, among other things.

Agreed. MergeInto definately should have the semantics that resolving TARGET
also resolves BASE if BASE isn’t a base for links whose tickets are open.
The exact semantics gets a bit tricky here, because closing a BASE for a
simple link has no
ramifications, but closing a BASE for a DEPENDSON link whose target isn’t
closed
is a problem. Again this can be handled by changing a small script rather
than by changing the core code, so its not as big a deal as it could be.

RefersTo

A “simple” link, just stating that two things are related somehow. It
shouldn’t have any special behaviour.

Just the ability to print the simple links given base or target ticketID’s.

I think the behaviours mentionated above can be executed through the
Scrips system. I think the system, as it is in the current CVS
version, is good enough (though more documentation is needed to be
written).

Cool. That would make it a nice modular system that was easy to adapt.

Hrm. If you did this, then I could set things up to not
perform the weird actions

Agreed. Actions should be linked to link types and be modifyable at the end
site, not built into the core.

It’s possible that we will need more linking actions, but not until
after 2.0, I’d daresay.
nod I’ll buy into that.

Agreed. I think all of the 4 types of links I identifed have been covered.

The ID’s should be animals that can be given to RT directly (either in perl
or
command line), or they should be parsable into method, host, id, args quads.
I think URI’s are perfect:

method://host/IDHERE?args?args?args

BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.
Most important for us now is to get links between RT and the KB/FAQ
system (must be handled especially in the web interface; we want it to
be possible to easily launch semi-automatic answers through the web
interface) and between RT and Bugzilla.

What about an ANSWERLINK that looks like:

kbfaq://kbfaqserver/....

the : will immediately determine that its not a local rt link (they consist
only of numbers). The kbfaq implies that some kbfaq method of access has to
be used. Not being familiar with kb/faq I hesitate to elaborate further.
There may be some times of links that shouldn’t or can’t be made remotely.
E.G for development use a link to a file may be represented as:

file://localhost/nfs/harbour/testcases/badtests/output.19990302.caseA

This isn’t any worse than links to other databses, or rt instances. All of
them have the problem that there is no way to insure that the TARGET of a
link exists.

The mailgate should automaticly detect mail from other RT instances
and set up a link. Communication between two RT instances should
mainly be done through the mail gateway. It might make sense to allow
web users to access remote RT instances “seamlessly”.

Interesting. I’m actually hoping to have a better
inter-instance communication
story at some point in the future. But the auto-linking could
be quite cool. what links were you thinking of?

How about something like:

RemoteRTLinkMail
mailto:rt@mailhost?[RT%20#74]:%20this%20is%20a%20ticket%20subject

then mail could be used (granted the email gateway will have to be expanded
a bit)
to do remote manipulation etc. Similiar links could be set up for:

RemoteRTLinkWWW
http://remotehost/rt/webrt.cgi?serial_num=104&display=History

and

RemoteGnatsLink
mailto:gnats@mailhost?[gnats%20subject%20line%20with%20tag]

the list is endless. I do think that the URI format can be used to encode
the proper info. What to do with the info, or how to display it can be
shifted off to scripts as well:

RemoteGnatsLink LOCALRT_TICKET_ID TargetGnatsLinkURL DisplayTarget
WEBPAGE

and DisplayTarget target can do:

return a real URL that can be clicked on maybe with < A href=…>
markers.

text explaining how to access it manually for dummy access methods.

BASE and TARGET is shaped like URLs. This is one of the things I’d
like to discuss. Here’s Jesse’s idea:

fsck.com-rt://instancename/ticket/

Well. I’m a bit positive, but I’m absolutely not sure. The “url”
above can’t be used for anything, as long as it doesn’t contain more
data about how to communicate with (instancename). It might be a good
idea to have something like this if there exist a mapping from the
instancename to such information somewhere. Anyway, I wouldn’t call
it an “URL”, as it is “broken” without this extra information. Any
thoughts?

Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don’t think that would suck too badly

I would write the fsck.com-rt link as either:

mailto:rt@fsck.com?..

or
http://fsck.com/rt/…

as I have above. Both are perfectly resolvable, and can be further
manipulated into url’s that will work. Also the DisplayTarget (and maybe
DisplayBase) code can do arbitrary mapping even turning fsck.com-rt:… into
one of the above forms.

– rouilj

[Brandon_S_Allbery_KF]

| > > DependsOn
| > >
| > > …meaning that TARGET has to be resolved before BASE (really) is
| > > resolved. A stalled BASE should be reopened when TARGET is resolved.
| > > When “spawning” a new TARGET i.e. through the web interface, the BASE
| > > should be stalled (if it’s open).
| > >
| > I’d sort of rather that we not use “Stalled” for that, but that we
| > actually figure out what tickets are dependent on a given
| > ticket at runtime.
|
| I used to be in your camp Jesse, but I think Tobias’s scheme of stalling
| the BASE has some merit. Stalling means: “don’t work on this ticket until
| something changes”. So it implies that new transactions shouldn’t be added
±–>8

The problem with this is, how do you determine when to un-stall the ticket?
Currently, any non-comment communication unstalls it (and this is quite
useful); either this would need to change or a hierarchy of rules for
un-stalling tickets would need to be developed.

brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering KF8NH
carnegie mellon university [“better check the oblivious first” -ke6sls]

[Jesse1]

Jesse said:

I think we more or less have a concensus about what links should be
available for 2.0, and how they should behave:

DependsOn

…meaning that TARGET has to be resolved before BASE (really) is
resolved. A stalled BASE should be reopened when TARGET is resolved.
When “spawning” a new TARGET i.e. through the web interface, the BASE
should be stalled (if it’s open).

I’d sort of rather that we not use “Stalled” for that, but that we
actually figure out what tickets are dependent on a given
ticket at runtime.

I used to be in your camp Jesse, but I think Tobias’s scheme of stalling the
BASE has some merit. Stalling means: “don’t work on this ticket until
something changes”. So it implies that new transactions shouldn’t be added
to that ticket, instead they should be added to the tickets created as
targets of the DEPENDSON links.

Except that’s not always true. Sometimes you can do some work on a ticket with
unresolved dependenices. Anyway, by having this in the scrips system, it becomes site configurable.

Also, if it can be done through a script, then its a non issue. The admin
(if s/he wants it stalled) simply puts the DependsOn script in place that
stalls the base ticket. See below for another possibile way to handle this.
Which should be the default, I’ll let you two battle over. BTW just what
does the API for the Scrips (is that a typo? should it be Scripts?)

No. it’s scrips. the API is currently “in the code” exclusively,
though it will get documented as we get closer to release.

I’d argue for a monolithic script. They can always write the big script to
call subscripts and exec the subscripts.

We’ve got a handle on it and a more elegant way to do this, I believe.

What about an ANSWERLINK that looks like:

kbfaq://kbfaqserver/…

KB links for MKIA, my KB server will get solidified as MKIA becomes more
solid itself.

Interesting. I’m actually hoping to have a better
inter-instance communication
story at some point in the future. But the auto-linking could
be quite cool. what links were you thinking of?

How about something like:

RemoteRTLinkMail
mailto:rt@mailhost?[RT%20#74]:%20this%20is%20a%20ticket%20subject

then mail could be used (granted the email gateway will have to be expanded
a bit)
to do remote manipulation etc. Similiar links could be set up for:

RemoteRTLinkWWW
http://remotehost/rt/webrt.cgi?serial_num=104&display=History

and

RemoteGnatsLink
mailto:gnats@mailhost?[gnats%20subject%20line%20with%20tag]

No. not for RT anyway. there will be real interfaces for inter-instance communication.

– rouilj

---

Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Pelcgb-serrqbz abj!

[Rouillard_John]

Rrouilj says:

I used to be in your camp Jesse, but I think Tobias’s scheme of stalling
the
BASE has some merit. Stalling means: “don’t work on this ticket until
something changes”. So it implies that new transactions shouldn’t be
added
to that ticket, instead they should be added to the tickets created as
targets of the DEPENDSON links.

Jesse said:

Except that’s not always true. Sometimes you can do some work
on a ticket with
unresolved dependenices. Anyway, by having this in the
scrips system, it becomes site configurable.

True.

Also, if it can be done through a script, then its a non issue. The
admin
(if s/he wants it stalled) simply puts the DependsOn script in place
that
stalls the base ticket. See below for another possibile way to handle
this.
Which should be the default, I’ll let you two battle over. BTW just what
does the API for the Scrips (is that a typo? should it be Scripts?)

No. it’s scrips. the API is currently “in the code” exclusively,
though it will get documented as we get closer to release.

Ok. Guess I’ll have to wait.

I’d argue for a monolithic script. They can always write the big script
to
call subscripts and exec the subscripts.

We’ve got a handle on it and a more elegant way to do this, I believe.

Ok, can you sketch an outline of how it works? I don’t believe I have seen
anything on that cross the mailing list.

Interesting. I’m actually hoping to have a better

interinstance communication
story at some point in the future. But the auto-linking could
be quite cool. what links were you thinking of?

How about something like:

RemoteRTLinkMail
mailto:rt@mailhost?[RT%20#74]:%20this%20is%20a%20ticket%20subject

then mail could be used (granted the email gateway will have to be
expanded
a bit) to do remote manipulation etc. Similiar links could be set up
for:

RemoteRTLinkWWW
http://remotehost/rt/webrt.cgi?serial_num=104&display=History

and

RemoteGnatsLink
mailto:gnats@mailhost?[gnats%20subject%20line%20with%20tag]

No. not for RT anyway. there will be real interfaces for inter-instance
communication.

Hmm, interesting. How do you get around the need to embed passwords in the
inter-instance communication with the remote [my]sql server? Or would the
user just authenticate at the time of contact?

– rouilj

[Rouillard_John]

Brandon S. Allbery said:

±----
| > > DependsOn
| > >
| > > …meaning that TARGET has to be resolved before BASE (really) is
| > > resolved. A stalled BASE should be reopened when TARGET is
resolved.
| > > When “spawning” a new TARGET i.e. through the web interface, the
BASE
| > > should be stalled (if it’s open).
| > >
| > I’d sort of rather that we not use “Stalled” for that, but that we
| > actually figure out what tickets are dependent on a given
| > ticket at runtime.
|
| I used to be in your camp Jesse, but I think Tobias’s scheme of stalling
| the BASE has some merit. Stalling means: “don’t work on this ticket
until
| something changes”. So it implies that new transactions shouldn’t be
added
±–>8

The problem with this is, how do you determine when to un-stall the
ticket?
Currently, any non-comment communication unstalls it (and this is quite
useful); either this would need to change or a hierarchy of rules for
un-stalling tickets would need to be developed.

I’m comfortable with unstalling the ticket if it receives a direct email.
What that means is that the owner of the ticket should pay attention to it
again.
Even if the attention is nothing more than to restall the ticket and wait
for the
resolution of the Target ticket to unstall it.

A similar question occurs for merge links. What happens when email is sent
to the BASE ticket of a merged ticket? Where does the transaction occur? In
the BASE ticket of the mergelink or the target ticket of the mergelink? I
can see arguments for both sides. From the requestors point of view, it
should probably be put into the BASE ticket
since that is the one that s/he will know about. From the owners point of
view I can see an argument for putting it into the target of the mergelink.
Arguably the transaction should be stored once and linked into both tickets
so the info is available from either ticket.

Hmm.

– rouilj

[Tobias_Brox]

Interesting. I’m actually hoping to have a better inter-instance communication
story at some point in the future. But the auto-linking could be quite cool.

…we don’t need it right now right here, but it would be �bercool, and
from time to time I see activity from users that it might already be
needed. It’s important to think about how it should be done already, so
we won’t find ourselves banging the head against the wall (or needing to
redesign the whole idea about “links”) when we (or somebody) suddently
need to implement it. So, I don’t think we should priority this for 2.0,
but we should absolutely supply a hacker guide about how we thought it
could be implemented for 2.0.

what links were you thinking of?

…when RT gets a mail that actually originates from another RT instance,
a “RefersTo” link is automagically set. With a lot of luck and right
access permissions, a webuser watching one ticket at instance A can just
follow this link, and continue tracking the issue at the remote RT
instance.

ATOH, maybe some kind of “Merge” is better suited when two RT instances
keep sending mail to each other on the same ticket (which will have two
different ticket IDs).

When somebody makes a link into another instance, there should be links
both ways (BASE points to TARGET at both BASE and TARGET RT instance) -
and RT should launch an email to set up the remote link.

Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don’t think that would suck too badly

Hmm … correct me if I’m wrong; the srv records is some old stuff that is
ment to be something of the same as the mx record, just more general - a
genious idea but unfortunately almost nobody knows about this record, and
absolutely nobody uses it.

I like the idea about using it, ATOH it might be confusing to those who
doen’t know the record and/or don’t have access to a DNS.

Tobias Brox
aka TobiX
+47 22 925 871

[Jesse1]

Interesting. I’m actually hoping to have a better inter-instance communication
story at some point in the future. But the auto-linking could be quite cool.

…we don’t need it right now right here, but it would be übercool, and
from time to time I see activity from users that it might already be
needed. It’s important to think about how it should be done already, so
we won’t find ourselves banging the head against the wall (or needing to
redesign the whole idea about “links”) when we (or somebody) suddently
need to implement it. So, I don’t think we should priority this for 2.0,
but we should absolutely supply a hacker guide about how we thought it
could be implemented for 2.0.

What I’d like to do is have the format for representing it within 2.0, but
not any code to support its use.

what links were you thinking of?

…when RT gets a mail that actually originates from another RT instance,
a “RefersTo” link is automagically set. With a lot of luck and right
access permissions, a webuser watching one ticket at instance A can just
follow this link, and continue tracking the issue at the remote RT
instance.

ATOH, maybe some kind of “Merge” is better suited when two RT instances
keep sending mail to each other on the same ticket (which will have two
different ticket IDs).

When somebody makes a link into another instance, there should be links
both ways (BASE points to TARGET at both BASE and TARGET RT instance) -
and RT should launch an email to set up the remote link.

That’s kinda neat. Basically I want to deal with the possibilty of inter-site
ticket escalation.

Hrm. If it became instancedomain/instancename then DNS srv records could
be used for glue. I don’t think that would suck too badly

Hmm … correct me if I’m wrong; the srv records is some old stuff that is
ment to be something of the same as the mx record, just more general - a
genious idea but unfortunately almost nobody knows about this record, and
absolutely nobody uses it.

They’re actually getting more popular and closer to a standard. Win2k
actually adopted them for some things… (not that that’s a reason to use them,
but it means they’ll be higher visibility.)

I like the idea about using it, ATOH it might be confusing to those who
doen’t know the record and/or don’t have access to a DNS.

They certainly won’t be needed for “regular” RT. But for intersite ticket
relationships, I think it’ll make life a lot easier. It’s either that
or maintaining a full table of where every other instance you need to talk to
lives this week.

jesse

–
Tobias Brox
aka TobiX
+47 22 925 871

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
“That package looks like what I wanted, but the site was down today,
so I decided to reimplement it in Perl.”
-me

[Tobias_Brox]

DependsOn

…meaning that TARGET has to be resolved before BASE (really) is
resolved. A stalled BASE should be reopened when TARGET is resolved.
When “spawning” a new TARGET i.e. through the web interface, the BASE
should be stalled (if it’s open).

I’d sort of rather that we not use “Stalled” for that, but that we
actually figure out what tickets are dependent on a given ticket at runtime.

Hrmgrmblhm.

I think “stalled” makes sense; also because it’s more possible to override
the default behaviour that way. I.e. if a requestor writes back, the
ticket will be automaticly reopened. It might make sense doing it
site-configurable, anyway. Which makes the scrips implementation elegant

MemberOf This means that when TARGET is resolved, all BASE is automagically resolved. When a support worker sends correspondence on a TARGET, all BASE requestors should receive the correspondence. If all BASEs are resolved, TARGET should automaticly be resolved.

I disagree. MemberOf shouldn’t automatically resolve either BASE or TARGET.
There should be a way to “Resolve all members” or somesuch, though

My original idea was to have only one linking type (dependency) and let
the user do things like “resolve this and all dependent” and/or “reply to
all dependent requestors”. Anyway, some French guy eventually convinced
me that it might be better to do it more like the way above.

I think that it will be sufficient, and I think it will be easier to
implement. Also, it will keep complexity off the user interfaces, which I
think is a Good Idea.

MergedInto

This is Jesses domain. I’m not sure if it makes sense to have this as
a link. Anyway, it should me the same as the “merge” of today.

The thought was that for 2.0 “merging” should become just another linking type
that did intelligent things with the requestors for each ticket, to make
it easier to track history, among other things.

Sounds elegant, but can you implement it easily?

I don’t care much - I think the other linking actions will be sufficient.
I’m happy to leave the complexity behind merging to you

Hrm. If you did this, then I could set things up to not perform the weird
actions

That’s the beauty with the scrips system as it is now, it will be site
configurable whether the “weird actions” are wanted or not.

I think we have two different paradigms here; those “weird actions” vs.
doing things run-time.

Through those “weird actions” I’m trying to avoid complexity. Keep It
Simple Stupid! The alternative is to add more complexity into the user
interface (which is a very bad thing, as the complexity will have to be
added for each and every user interface), and eventually scatter around
code about how different links are to be respected in different
situations. Actually, I think we can keep (almost) all things into some
“weird actions” executed by the Scrips system. Nice, clean, simple.
Alternatively, you might replace my “weird action” with run-time logic
some time in the future. It shouldn’t be that hard.

I’m willing to implement my “weird actions” ideas, test it in a real-life
environment and put up a document with some examples of intended usage …
but it might take more than a week to do the two latter things…

Tobias Brox
aka TobiX
+47 22 925 871

[Tobias_Brox]

To: “Rouillard, John” RouillardJ@brevard.cc.fl.us,

Ehm … darn … I must be confused … I thought Rouillard was French.
Is it just because the name seems French, or have you used a French email
earlier?

Hm, a bit offtopic, but anyway …

[“weird action”: when BASE is set dependent on TARGET, stall BASE]

The problem with this is, how do you determine when to un-stall the ticket?
Currently, any non-comment communication unstalls it (and this is quite
useful); either this would need to change or a hierarchy of rules for
un-stalling tickets would need to be developed.

In addition, BASE should automagically be reopened when (one or all?)
TARGET(s) is/are resolved. This is how our 1.0-based version works now,
and it works great.

Tobias Brox
aka TobiX
+47 22 925 871

[Tobias_Brox]

I’d argue for a monolithic script. They can always write the big script to
call subscripts and exec the subscripts.

I think the Scrips system is nice. Well, it should eventually be extended
to handle shell scripts as well as perl modules. And the CLI (and the
other UIs) should eventually b extended to be just as flexible as the
library calls themselves. Anyway, I really doubt something like this can
be ready for 2.0.

I haven’t read through Jesse’s answer on what the Scrips really are yet -
I hope it’s a good enough answer. Anyway, I’d like the attention to the
design docs that are in the CVS in the rt-1-1 branch; there are some
“definitions” documents there (mostly written by me, but I stole a bit
from you as well). The “subscription-definitons” tells about the Scrip
system.

Agreed. I think all of the 4 types of links I identifed have been covered.

I also think so

kbfaq://kbfaqserver/…

the : will immediately determine that its not a local rt link (they consist
only of numbers).

I didn’t think of this, but it makes sense to let local numbers have a
shorter URI.

the list is endless. I do think that the URI format can be used to encode
the proper info. What to do with the info, or how to display it can be
shifted off to scripts as well:

Indeed; we can make something similar to the Scrips system for use with
the UI. Anyway, this is a bit far off. I think I will do it
quick-and-dirty with the few URI types I need as for now.

Tobias Brox
aka TobiX
+47 22 925 871

[Tobias_Brox]

Except that’s not always true. Sometimes you can do some work on a
ticket with unresolved dependenices.

That’s another beuty with “my” system; a user (including requestors) can
just reopen the stalled request!

Tobias Brox
aka TobiX
+47 22 925 871

[Jesse1]

Rather than using “Stalled,” I’d rather allow people to limit the queue
by whether there are "unresolved dependencies"On Tue, Apr 25, 2000 at 03:26:53PM +0200, Tobias Brox wrote:

Except that’s not always true. Sometimes you can do some work on a
ticket with unresolved dependenices.

That’s another beuty with “my” system; a user (including requestors) can
just reopen the stalled request!

–
Tobias Brox
aka TobiX
+47 22 925 871

---

Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
After all, it’s not every day you meet up with an evil power
-M. Bulgakov

[Tobias_Brox]

They’re actually getting more popular and closer to a standard.

I thought it had been a “forgotten” standard for many years.

Win2k
actually adopted them for some things… (not that that’s a reason to use them,
but it means they’ll be higher visibility.)

I’d rather call that a reason not to use them Well, sounds like a great
idea anyway. Then what about rt2://fsck.com?ticket=345&queue=general

Tobias Brox
aka TobiX
+47 22 925 871

[Tobias_Brox]

Rather than using “Stalled,” I’d rather allow people to limit the queue
by whether there are “unresolved dependencies”

Neat enough, but I’d suggest postponing that until after 2.0 - my
stalling idea is just simpler to implement.

Tobias Brox
aka TobiX
+47 22 925 871

[Jesse1]

I’d very much like to see this in the 2.0 release. I can most likely take care
of the code.On Wed, Apr 26, 2000 at 08:38:02AM +0200, Tobias Brox wrote:

Rather than using “Stalled,” I’d rather allow people to limit the queue
by whether there are “unresolved dependencies”

Neat enough, but I’d suggest postponing that until after 2.0 - my
stalling idea is just simpler to implement.

–
Tobias Brox
aka TobiX
+47 22 925 871

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Transporters are so ungodly. if god had wanted us to travel great distances
instantaneously, he would have given us an internal
materialisation/dematerialisation control.
– Shoshe Cole

[Jesse1]

They’re actually getting more popular and closer to a standard.

I thought it had been a “forgotten” standard for many years.

Win2k
actually adopted them for some things… (not that that’s a reason to use them,
but it means they’ll be higher visibility.)

I’d rather call that a reason not to use them Well, sounds like a great
idea anyway. Then what about rt2://fsck.com?ticket=345&queue=general

Hrm. I should probably go dig out the relevant specs on URIs. I remember
something about the scheme having to have a vendor ID in it for things other
than IETF standards.

Why do you have the queue in there? htat could easily change without the remote site knowing about it, nor does the remote site need it to look up the reference.

As far as I know there’s no real need for the silly http style parameter passing.

How about fsck.com-rt:///ticket/

in practise this would look like:

fsck.com-rt://fsck.com/ticket/2734 

or fsck.com-rt://support.funcom.com/ticket/89235

my one real concern with this scheme is that some people seemed to have badly named their RT instances as “support” or “help”

jesse

–
Tobias Brox
aka TobiX
+47 22 925 871

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I think co-ordinating 1000 prima donnas living all over the world will be as
easy as herding cats…" – Andy Tanenbaum on the linux development model, 1992

[Tobias_Brox]

Why do you have the queue in there? htat could easily change without the
remote site knowing about it, nor does the remote site need it to look
up the reference.

I did have a good reason for it, though I can’t remember. Maybe it is
not so important anyway. But it should be possible to do lookups on other
things that only ticket ids anyway.

How about fsck.com-rt:///ticket/

Maybe. There should be valid URIs both for viewing a ticket …
alternatively with an alternative template … and for viewing a queue
view.

fsck.com-rt://fsck.com/ticket/2734
or fsck.com-rt://support.funcom.com/ticket/89235

my one real concern with this scheme is that some people seemed to have badly named their RT instances as “support” or “help”

If you’re going to do it as an URI, and if you’re going to use svc
records, the middle thing cannot be the instance name, but rather the
domain it’s coming from or .domain.

I will start working with this either right away or tomorrow.

Tobias Brox
aka TobiX
+47 22 925 871

[Jesse1]

Why do you have the queue in there? htat could easily change without the
remote site knowing about it, nor does the remote site need it to look
up the reference.

I did have a good reason for it, though I can’t remember. Maybe it is
not so important anyway. But it should be possible to do lookups on other
things that only ticket ids anyway.

How about fsck.com-rt:///ticket/

Maybe. There should be valid URIs both for viewing a ticket …
alternatively with an alternative template … and for viewing a queue
view.

The UI isn’t for viewing a ticket, but for allwoing RT to know where a ticket is.

But yes, for a queue uri, we’d get /queue/

fsck.com-rt://fsck.com/ticket/2734 

or fsck.com-rt://support.funcom.com/ticket/89235

my one real concern with this scheme is that some people seemed to have badly named their RT instances as “support” or “help”

If you’re going to do it as an URI, and if you’re going to use svc
records, the middle thing cannot be the instance name, but rather the
domain it’s coming from or .domain.

Yeah. The problem is that instance names don’t map cleanly to domains.

maybe it should be fsck.com-rt://domain/instancename/ticket/number

I will start working with this either right away or tomorrow.

–
Tobias Brox
aka TobiX
+47 22 925 871

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I admit that X is the second worst windowing system in the world, but all the
others I’ve used are tied for first.