X-Git-Url: http://git.freeside.biz/gitweb/?p=freeside.git;a=blobdiff_plain;f=rt%2Fdocs%2Fdesign_docs%2Flink-definitions.txt;fp=rt%2Fdocs%2Fdesign_docs%2Flink-definitions.txt;h=0000000000000000000000000000000000000000;hp=e109744cf7ac92d9148abf47b6b20c588898f1e8;hb=43a06151e47d2c59b833cbd8c26d97865ee850b6;hpb=6587f6ba7d047ddc1686c080090afe7d53365bd4 diff --git a/rt/docs/design_docs/link-definitions.txt b/rt/docs/design_docs/link-definitions.txt deleted file mode 100644 index e109744cf..000000000 --- a/rt/docs/design_docs/link-definitions.txt +++ /dev/null @@ -1,143 +0,0 @@ -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. -