1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
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 separated 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.
|
