1 For 2.0, those Linking actions should be supported:
3 1. DependentOn; TobiX-style.
5 BASE is dependent on TARGET.
7 ...meaning that TARGET has to be resolved before BASE (really) is
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.
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"
19 TobiX will need to make dependency links into Bugzilla.
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
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.
28 Loops don't make sense at all, but the system above won't break if it
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.
36 2. MemberOf link (grouping)
38 BASE is a member of TARGET.
40 TobiX-style "weird actions":
41 ...when TARGET is beeing replied to, all BASE requestors should get the
44 ...when TARGET is resolved, all BASE tickets should be resolved (unless
45 they have other unresolved Dependencies/MemberOf links).
47 ...when all BASEs to one TARGET are resolved, TARGET should be resolved.
49 The alternative is to let the user choose "reply to all" and "resolve all"
50 through the user interfaces.
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.
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.
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.
69 If a work task needs to be splitted into two subtasks, MemberOf might also be
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
80 BASE is the same as TARGET.
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.
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.)
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.
97 4. RefersTo / No Action link (linking)
99 BASE is somewhat related to TARGET
101 No special actions will be taken.
103 Loops might maybe make sense
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.
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.
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:
118 1 can't connect to hosts with netscape
120 3 Can't send email: error no space on spool/mqueue
122 You have the above in the queue. You realize that DNS is down. Spawn
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.
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.