1 files changed, 143 insertions, 0 deletions
diff --git a/rt/docs/design_docs/link-definitions.txt b/rt/docs/design_docs/link-definitions.txt
new file mode 100644
index 0000000..30b9035
--- /dev/null
+++ b/rt/docs/design_docs/link-definitions.txt
@@ -0,0 +1,143 @@
+For 2.0, those Linking actions should be supported:
+
+1. DependentOn; TobiX-style.
+
+ BASE is dependent on TARGET.
+ 
+ ...meaning that TARGET has to be resolved before BASE (really) is
+ resolved.
+ 
+ According to TobiX, those "weird action" makes sense:
+ ...when the link and/or TARGET is created, the BASE might be stalled.
+ Alternatively, this should be very trivial to request through the UIs.
+ ...when the TARGET is resolved, BASE will be reopened if it's stalled.
+
+ An alternative to those "weird actions" is to have some run-time logic that
+ takes care of this; i.e. letting the search interface handle "please hide
+ all requests with unresolved dependencies"
+ 
+ TobiX will need to make dependency links into Bugzilla.
+
+ Dependency links should be made when more work to BASE should be done
+ after the TARGET is resolved and/or BASE can't be resolved before TARGET is
+ resolved.
+
+ Dependency links are often 1:1, but n:n links makes sense; one ticket can
+ depend on several others, several tickets can depend on one ticket, etc.
+
+ Loops don't make sense at all, but the system above won't break if it
+ encounter loops.
+
+ Dependency links is more for workflow than anything else.  When a new
+ TARGET is created, some of the work might be passed over to another
+ department/person ... but _not_ the responsibility for the communication
+ with the external requestor.
+
+2. MemberOf link (grouping)
+
+ BASE is a member of TARGET.
+
+ TobiX-style "weird actions":
+ ...when TARGET is beeing replied to, all BASE requestors should get the
+ reply.
+
+ ...when TARGET is resolved, all BASE tickets should be resolved (unless
+ they have other unresolved Dependencies/MemberOf links).
+
+ ...when all BASEs to one TARGET are resolved, TARGET should be resolved.
+ 
+ The alternative is to let the user choose "reply to all" and "resolve all"
+ through the user interfaces.
+
+ MemberOf should be used when BASE ticket states more or less the same as
+ the TARGET ticket, and we do want to give a reply to all requestors, but we
+ don't want to merge them (Individual tickets from individual external
+ requestors should be respected as separate entities). If BASE tickets from
+ more than one external requestor is linked to a TARGET ticket, we denote
+ the TARGET ticket as a "Group ticket".  This is only a documentation
+ definition, you won't find any references to "Group tickets" in the source.
+
+ I think the proper etiquette should be to clearly state in a reply to a
+ group ticket that the mail is going to several persons, and that the
+ requestor should reply back if they feel their Ticket hasn't got the
+ attention it deserves.  The user documentation should reflect this.
+
+ MemberOf links can also be used to hand away the work flow. The person in
+ charge of the TARGET ticket will also be in charge of the BASE tickets and
+ the communication with the end user.
+
+ If a work task needs to be splitted into two subtasks, MemberOf might also be
+ used.
+
+ 1:n links makes more sense, but n:n can also work in some cases.
+ The reply stuff might break seriously upon loops.  Recursement might be
+ handy for splitting a work task into subtasks (making a hierarchical tree
+ of the worktasks).
+
+
+3. Merge (connecting)
+
+ BASE is the same as TARGET.
+
+ ...the system should somehow merge together transactions for both tickets.
+ ...BASE should be more or less deleted, only the TARGET should apply.
+ ...actions done toward BASE should be redirected to TARGET.
+
+ I think MergeLinks should be used when two tickets accidentally has
+ appeared twice in the system, and/or there is no reason to keep the two
+ tickets separately.  It might be that it's the same requestor (i.e.
+ clicking the "send" button twice in a web environment) or that we don't
+ care much about giving the requestor individual follow-up (typically
+ "internal" requestors, etc.)
+
+ Based on user feedback, merged tickets will be displayed as the same ticket
+within RT's user interfaces. but the original tickets' transactions will be
+kept seperated in the database. this may require some magic.
+ 
+4. RefersTo / No Action link (linking)
+
+ BASE is somewhat related to TARGET
+
+ No special actions will be taken.
+ 
+ Loops might maybe make sense
+
+BASE and TARGET are usually Tickets within one RT instance, but it
+might also point to external RT instances, other DB systems, etc.
+
+
+
+
+In future revisions, it should be very easy to set up site-specific link action types.
+We should also consider to include more linking actions in the box.
+
+An example stolen from John Rouillard.  Eventually the [comments] should be
+removed, and the text modified to fit the planned 2.0 link actions:
+
+  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 [I would rather say "make a MemberOf link _or_ a
+  dependency link from 1 and 2 to 4" --TobiX] (if you choose to stall 1 and
+  2 automatically feel free, its just a shell script change) [well, you
+  might choose dependency instead of MemberOf --TobiX]. 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
+  creates a Dependency linkon  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 [This is the default behaviour for 2.0 MemberOf-linked tickets.
+  Remember that if we send Replies to "Group Tickets" (that is, the target
+  of several "MemberOf" links) --TobiX]. Ticket 4 [should be 3? --TobiX] is
+  reopened and the person working on it starts flushing the mail queue and
+  the moved mailq by hand. 
+