Hi all, at my employer, we have the problem that sometimes people merge tickets wrongly. And what happens then? Some people manage to delete the ticket links, some people manage to change the state from 'merged' to something else, but I've never seen anybody successfully split out the articles that came from the original ticket, restore the previous ticket state (or just "open" it) and delete the links correctly. Is there already a solution to this (or possibly being worked on)? If not, I'm pondering how best to supply an undo for merges. 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 merge Does that sound feasible? Did I miss anything crucial? Cheers, Moritz
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 merge
With 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. Regards, mg -- Martin Gruner Senior Developer R&D OTRS AG Bahnhofplatz 1a 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann (Vorsitzender), Christopher Kuhn, Sabine Riedel Service Desk-Professionalität auf höchstem Niveau – OTRS 3.4 wird zu OTRS 4! – Jetzt Beta-Version testen! http://www.otrs.com/otrs-4-beta-mit-ultra-flachem-design-und-uberarbeitetem-...
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 merge
With 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
participants (2)
-
Martin Gruner -
Moritz Lenz