More userfriendly and/or undoable merge process

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

b) make the merge “undoable”

Cheers

4 Likes

I think that would be helpful.

Let’s talk about this.
How long do you think this process should be revertable?
What do you think who should be able to revert this process?

What happens if your customer has been notified already or maybe read it on the WebApp already?

Don’t get me wrong, I just see like dozens of issues here that will arise if you go down that road.

By the way, I currently know of no ticket system that allows you to do so:

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 :slight_smile:

1 Like

No worries, really.
I might be the bad guy, but sometimes it helps. :smiley:

Still like the idea of enhancing the merge dialog itself!

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?

2 Likes

I’m no developer and can not outpoint “possible issues” on such behaviors.

+1 from me. A few days ago I accidentally merged two tickets I originally wanted only to be linked… :see_no_evil: