Merging is a dangerous process in Zammad: Very easily one enters a wrong ticket ID (multiple, sometimes different, clipboards in X11 and other reasons) and the merging cannot be rolled back. We have quite some tickets which are merges of two completely unrelated contents.
I suggest to
a) redesign the merge “wizard” in that after having entered the Ticket ID it presents the title of the target ticket and asks if it is ok to merge the current ticket with the target ticket
Please don’t get me wrong, but I guess there’s a reason nobody does it. :-X
Besides, yes merging is a critical step, but I think agents should be careful.
As for me, I always open the other ticket to touble check if it really is this ticket and copy this number from the top. In all my years in working with ticket system, this was never a problem to me. But it could just be me.
I was aware that such a process would entail lots of problems, but I still wanted to throw in the suggestion ;-). However now that I realize the list of potential pitfalls I’d rather withdraw my suggestion “b”. Personally I think that the confirmation step should be enough. And yes, I agree that with appropriate discipline one can avoid merging issues, but I cannot control other people’s discipline
A colleague of mine mentioned that he would like more merge functionality. I think that, perhaps merge should be reworked. I have a lot of projects that I’m currently working on, but I should be able to take a look at some point.
Perhaps the current merge process is a bit dangerous, and over-complicated (at least in the source). From the user’s perspective, a ticket merge simply moves all the articles from a ticket to the parent, any incoming article is then allocated to the parent ticket rather than the old ticket (recursively). If this process was altered, so that merging only ‘tags’ articles to be displayed on the parent ticket, this could make the merge process completely undoable. This could be done by adding a column to the database table that links tickets. (Boolean is_merge indicates whether the link is a merge action). Then, when rendering a ticket, you can render articles from a slightly different query which is a recursive union over the tickets which are merged. The action of un-merging a ticket is then taken by removing the link between the tickets.
@MrGeneration, can you think of any errors that might arise by taking this course of action?