[rt-devel] Linking actions (for 2.0)

[Tobias Brox]

> > <BASE> DependsOn <TARGET>
> > 
> > ...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
:)

> > <BASE> MemberOf <TARGET>
> > 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.

> > <BASE> MergedInto <TARGET>
> > 
> > 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