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-core/?lang=de _______________________________________________ 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
