Hi Martin, On 11/03/2014 10:16 AM, Martin Gruner wrote:
Hi Moritz!Is there already a solution to this (or possibly being worked on)?None that I know of.My current thoughts: 1) introduce a transaction ID in the ticket_history table 2) make sure that all individual entries in the ticket_history table that are created during a merge get the same transaction ID 3) currently a merge moves the history for each article that is merged. This would need to be changed to a copy operation, or otherwise a history entry for each article that is moved needs to be created 4) when the steps above are done, there should be enough meta data to undo a merge: 4.1) remove all LinkObjects created during a merge 4.2) move all articles back that were moved during a merge 4.3) restore the old state of the merge ticket 4.4) (Optional) undo changes to dynamic fields that were done during the mergeWith the current database design most operations in OTRS are not cleanly reversible. In the case of merges it is particularly so. Your proposal could be a workaround, but think of a ticket A merged to B, then B to C etc. DynamicFields could also have been changed in the meantime.
I'm aware of that. Still most accidental or wrong merges are detected pretty quickly, and even just the ability to undo the last merge per ticket would be a huge boon for us. (And judging by the google results for "otrs undo merge", we're not the only ones).
That said, if you have ideas for making it less of a workaround, I'm all ears. (Maybe storing old values in the ticket history would make it easier to revert to older states?)
Also to be clear, in the spirit of traceability, I don't want a complete undo, more of an opposite action. In git terminology, I want a revert, not a history rewrite.
Cheers, Moritz
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
