diff options
Diffstat (limited to 'rt/docs/design_docs/link-definitions.txt')
-rw-r--r-- | rt/docs/design_docs/link-definitions.txt | 143 |
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 000000000..30b903567 --- /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. + |