+++ /dev/null
-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.
-
projects / freeside.git / blobdiff