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.