rt/docs/design_docs/link-definitions.txt

   1 For 2.0, those Linking actions should be supported:
   2
   3 1. DependentOn; TobiX-style.
   4
   5  BASE is dependent on TARGET.
   6
   7  ...meaning that TARGET has to be resolved before BASE (really) is
   8  resolved.
   9
  10  According to TobiX, those "weird action" makes sense:
  11  ...when the link and/or TARGET is created, the BASE might be stalled.
  12  Alternatively, this should be very trivial to request through the UIs.
  13  ...when the TARGET is resolved, BASE will be reopened if it's stalled.
  14
  15  An alternative to those "weird actions" is to have some run-time logic that
  16  takes care of this; i.e. letting the search interface handle "please hide
  17  all requests with unresolved dependencies"
  18
  19  TobiX will need to make dependency links into Bugzilla.
  20
  21  Dependency links should be made when more work to BASE should be done
  22  after the TARGET is resolved and/or BASE can't be resolved before TARGET is
  23  resolved.
  24
  25  Dependency links are often 1:1, but n:n links makes sense; one ticket can
  26  depend on several others, several tickets can depend on one ticket, etc.
  27
  28  Loops don't make sense at all, but the system above won't break if it
  29  encounter loops.
  30
  31  Dependency links is more for workflow than anything else.  When a new
  32  TARGET is created, some of the work might be passed over to another
  33  department/person ... but _not_ the responsibility for the communication
  34  with the external requestor.
  35
  36 2. MemberOf link (grouping)
  37
  38  BASE is a member of TARGET.
  39
  40  TobiX-style "weird actions":
  41  ...when TARGET is beeing replied to, all BASE requestors should get the
  42  reply.
  43
  44  ...when TARGET is resolved, all BASE tickets should be resolved (unless
  45  they have other unresolved Dependencies/MemberOf links).
  46
  47  ...when all BASEs to one TARGET are resolved, TARGET should be resolved.
  48
  49  The alternative is to let the user choose "reply to all" and "resolve all"
  50  through the user interfaces.
  51
  52  MemberOf should be used when BASE ticket states more or less the same as
  53  the TARGET ticket, and we do want to give a reply to all requestors, but we
  54  don't want to merge them (Individual tickets from individual external
  55  requestors should be respected as separate entities). If BASE tickets from
  56  more than one external requestor is linked to a TARGET ticket, we denote
  57  the TARGET ticket as a "Group ticket".  This is only a documentation
  58  definition, you won't find any references to "Group tickets" in the source.
  59
  60  I think the proper etiquette should be to clearly state in a reply to a
  61  group ticket that the mail is going to several persons, and that the
  62  requestor should reply back if they feel their Ticket hasn't got the
  63  attention it deserves.  The user documentation should reflect this.
  64
  65  MemberOf links can also be used to hand away the work flow. The person in
  66  charge of the TARGET ticket will also be in charge of the BASE tickets and
  67  the communication with the end user.
  68
  69  If a work task needs to be splitted into two subtasks, MemberOf might also be
  70  used.
  71
  72  1:n links makes more sense, but n:n can also work in some cases.
  73  The reply stuff might break seriously upon loops.  Recursement might be
  74  handy for splitting a work task into subtasks (making a hierarchical tree
  75  of the worktasks).
  76
  77
  78 3. Merge (connecting)
  79
  80  BASE is the same as TARGET.
  81
  82  ...the system should somehow merge together transactions for both tickets.
  83  ...BASE should be more or less deleted, only the TARGET should apply.
  84  ...actions done toward BASE should be redirected to TARGET.
  85
  86  I think MergeLinks should be used when two tickets accidentally has
  87  appeared twice in the system, and/or there is no reason to keep the two
  88  tickets separately.  It might be that it's the same requestor (i.e.
  89  clicking the "send" button twice in a web environment) or that we don't
  90  care much about giving the requestor individual follow-up (typically
  91  "internal" requestors, etc.)
  92
  93  Based on user feedback, merged tickets will be displayed as the same ticket
  94 within RT's user interfaces. but the original tickets' transactions will be
  95 kept seperated in the database. this may require some magic.
  96
  97 4. RefersTo / No Action link (linking)
  98
  99  BASE is somewhat related to TARGET
 100
 101  No special actions will be taken.
 102
 103  Loops might maybe make sense
 104
 105 BASE and TARGET are usually Tickets within one RT instance, but it
 106 might also point to external RT instances, other DB systems, etc.
 107
 108
 109
 110
 111 In future revisions, it should be very easy to set up site-specific link action types.
 112 We should also consider to include more linking actions in the box.
 113
 114 An example stolen from John Rouillard.  Eventually the [comments] should be
 115 removed, and the text modified to fit the planned 2.0 link actions:
 116
 117   ticket  problem
 118     1         can't connect to hosts with netscape
 119     2         ping is broken
 120     3         Can't send email: error no space on spool/mqueue
 121
 122   You have the above in the queue. You realize that DNS is down. Spawn
 123   a ticket
 124
 125     4         DNS is down
 126
 127   mergelink 1 and 2 to it [I would rather say "make a MemberOf link _or_ a
 128   dependency link from 1 and 2 to 4" --TobiX] (if you choose to stall 1 and
 129   2 automatically feel free, its just a shell script change) [well, you
 130   might choose dependency instead of MemberOf --TobiX]. The person working
 131   on 3 has come to the conclusion that outgoing mail is backing up because
 132   of the DNS failure. She has cleared space by copying the mail queue to
 133   another disk, but can't really get email working till DNS is up. So she
 134   creates a Dependency linkon  ticket 4 stalling ticket 3.
 135
 136   We finally get DNS working and resolve ticket 3. What happens?  Tickets 1
 137   and 2 are resolved and email is sent to requestors notifying them of the
 138   resolution [This is the default behaviour for 2.0 MemberOf-linked tickets.
 139   Remember that if we send Replies to "Group Tickets" (that is, the target
 140   of several "MemberOf" links) --TobiX]. Ticket 4 [should be 3? --TobiX] is
 141   reopened and the person working on it starts flushing the mail queue and
 142   the moved mailq by hand.
 143