yes, i'm with you 100%
This is my dream too. a Merge function be great!
Because often customers start a new email and not answer with ticket number...than be great to "merge" this answer to a existig ticket.

Yeah.
Even the problem is that there is no "public ticket link" which could be added.
So even this would help if u can close a ticket and say "See ticket number: #12345",
which will link a staff AND a user to the ticket.
This could be on one hand help if merge isn't possible, on the other hand if u have tickets,
which following to another, u can create a kind of "logical way".

But let's see what the devs think about this ;)

CHEERS!

I like the idea of the auto-link (see #12345683)

@greezybacon

Should I open another thread for this?

So the idea behind this is "just" just a button u hit and u can type a ticket number (or select, but this is heavy).
After this a link will be added to the ticket.

Again the problem isn't adding the link itself, it's that only staff OR a user can view this.
Like I said the following of problems and changes u do, would be great to handle from begin to end, without searching.

But also u can't for example create a link to a ticket in knowledge base, which maybe could explain something better, too.

I would like to add my support for this feature request. My users are really good at sending multiple emails about the same issue without including the ticket number, and I quickly loose track of all the neccesary information needed to solve the issue.

Merging tickets would be awesome! Even if it is just by entering a ticket #.

Dupe of https://github.com/osTicket/osTicket-1.8/issues/1068?

Please search before submitting a new issue!

Well in generally it's quote the same.
But on the other hand it separate with my explanation as an auto link is another feature than merging tickets.

So no idea how to handle this now.

In my opinion the first "more easy" step would be to add an option to link to a ticket which can be viewed by staff and/or user.
So u can create a kind of process/history when trying to find solutions or understand something.

But at all it would be cool in future to have a kind of "main ticket" which just can be added new/same/double tickets.
So that u get a to one ticket and see all different solutions, users ways in a list of tickets which were merged.

That my idea of this, but I don't know if anyone can understand and see this as sensefull as I see.

CHEERS

Referencing / Linking is the original suggestion by @greezybacon which they are actually working on and its called 'Issues'. Grouping together similar tickets makes a lot of sense, but its different from merging. With a merge you only have to 'move' all ticket entries to the new ticket, linking / grouping would require a new table.
So yeah, its pritty much the same thing you are talking about @Hannibal226

i will programming this in the next days/weeks. and plublish it as pull request.

i think it's not so hard to "merge tickets" if the messages are sort by time. and in the most case, if you merge a ticket, you have only "one" message. Because its maybe a new ticket that the end-user answered wrong/write new email and not used the answer button.

My idea is:

• you have a "Merge to other Ticket" button.
• if you press it, its open a pop up and you write/search the ticket where you want merge this ticket.
• than you been asked to add the sender as collaborator (if is not the same email like from owner)
• than you been asked for close the "new ticket" on the end or delete it.
  if you close it, than a note added with all informations like:
  who sent it (email/name) time/date and the ticketnumber from closed ticket
  OR
  who sent it (email/name) time/date

final.
I think it's a really needed function. I have often customer that write a new email and not use answer button. than i manually close the new ticket and add the ticket number to the "main ticket". But this is not so cool if you need to switch from ticket to ticket to understand what happen.

@mrsaw12 might I suggest that you try to implement it as a plugin?

@Mrsaw12

This sounds gr8 and I'll really like to test this ;)
And like u said it isn't such complicated at all, but anyway I'm not to much into PHP and MySQL and so to hard for myself.

So much success and let us know when it's done ;)

CHEERS buddy!

@kordianbruck

So anyway I'm not sure.
It's two ways if u get from one ticket saying that it should be merged and/or linked to anything OR u choose various tickets and group them.

Again this is to deep and at all any of this function is missing and I'm happy we have so active guys like @mrsaw12 who r spending a bit time to help quick out here.

For sure the main devs like @greezybacon or all the guys beside r doing more than enough and this shouldn't be meant as any pressure or something like that.

Anyway thanks to u for getting thinks together and maybe with a solution both parts r happy with the result, so that we can say "yes it's the same" ;)

CHEERS

In the coming months we are adding the ability for a ticket to have multiple threads (via "tasks"). It would be interesting to see if that would aid in ticket merging

@greezybacon Cool, good to hear!

hi! im wondering if there are any updates to this enhancement? badly needed. thanks!

+1

@greezybacon Good to hear & thanks!

also looking for an update on this. Merging tickets is essential for our workflow, thanks.

Hi guys,

I've used a lot of ticketing systems, and they all do merge via the same basic methodology (Ceberus, Zendesk, RT, etc.)

I would love to see merge in osTicket consistent with what most other ticketing systems offer.

1) Allow the Agent to select multiple tickets from any view (search result list, my tickets list, other lists) and to hit a MERGE button.

2) Once the MERGE button is hit

• ALL data is merged into one ticket thread, ordered by date
• The OLDEST ticket number is the ticket number of the merged ticket
• ALL collaborators and agents are on the new ticket

It's a merge - you take everything and put it into one thing that is represented by the ORIGINAL (oldest) thing.

Merging and reducing duplicates are the most critical features in a high volume environment to reduce mindless and unnecessary work in ticketing. They are, IMHO, gaping feature holes in osTicket.

+1 richbodo

+1 !!!

despite lots of requests for a merge function, no progress ???

:( will take long time? Merge ticket is very useful.

Merge is not particularly high on the to do as there are more important features/functionality above it.
I wouldn't expect a Merge feature for a while.

Sad for that :) but I can understand you have a lot of work.
In this days I had used a lot merge function in other open source ticket so.. it's really missed in OsTicket.

Well, I hope to see this Merge project not forgot.

For me OsTicket has thee things to implement/fix:

• Merge tickets (This Issue)
• Topic edit in the ticket (already done and will released soon, great!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Correct the wrong time in user registration page https://github.com/osTicket/osTicket-1.8/issues/1842
• Fix a bug in link on ticket https://github.com/osTicket/osTicket-1.8/issues/2024
• Maybe responsive theme https://github.com/osTicket/osTicket-1.8/issues/2030
• Auto close ticket on certain statues https://github.com/osTicket/osTicket-1.8/issues/2036
  And OsTicket will be the best open source

Wow lot of people is following this :-) Merge tickets, great!

Awaiting merging with eager anticipation!

Am adding the code in myself for now so will not be updating beyond 1.9.4 until Merge is one of the added featuers.

If stable code for merging tickets exist, why not add it to the main branch ?
There seems to be a demand for it ...
Merging would be a huge improvement for us !

Yes, merge tickets very user full.

Inviato da dispositivo mobile. | Sended by mobile device
Il 13/Mag/2015 07:03, "Eddie-BS" [email protected] ha scritto:

If stable code for merging tickets exist, why not add it to the main
branch ?
There seems to be a demand for it ...
Merging would be a huge improvement for us !

—
Reply to this email directly or view it on GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment-101513518
.

The ticket merge would be a huge benefit for us as we have run into the case many times where a user has created tickets under two email addresses and we want to merge them all to one account and currently it has to be done one at a time using the change owner (or you have to write a query to do it from the back end but that's always dangerous because you may miss something that the software would have normally handled).

Will be userfull also merge also same user ticket but different ticket so if user A make two different ticket ability to merge in one.

+1 for this too. Really wish that OSTicket will have this function one day.

+1 for this function, would be perfect if this will be possible

+1

Imagine if Github didn't have a merge feature...

+1

Merging tickets would be a very useful addition. I love the way things are going with 1.10rc1, but there have been so many changes to the code that the old merge tweaks are not as easy to implement. I wish I was more PHP-savvy.

+1

+1 It's very necessary!

The awesomely detailed Internationalization feature implemented on 1.10 is done and now the other feature left is Merging Tickets, which is quiet essential to high-volume support centers. I hope this gets some attention for 1.10 or 1.11 for osTicket to shoot ahead of other solutions.

+1

Yes i Agree

+1

What would it take for someone to develop this feature and have it merged with OSTicket?

Despite the comment by ntozier of "Merge is not particularly high on the to do as there are more important features/functionality above it. I wouldn't expect a Merge feature for a while." based on the sheer quantity of +1's and duplicate opened tickets, I'd say the demand is pretty high.

I've been writing PHP for 16 years. I could write a merge method. I'd want to talk to the lead devs on the DB schema and their thoughts on the best way to implement the merge. Or I can review the schema and suggest an implementation. But before I do any of that, I'd like to make sure that my work could make it into OSTicket Trunk.

Is that a possibility?

:+1: for @ooglek

@ooglek
Sounds good and reasonable to me. :)

Developers, what do you think?
@protich
@greezybacon
@nfebuary

Yeah!

:+1:

@ooglek
Cool that u show this initiative!

I'm quite sure @greezybacon is thankful, too but for sure I don't know what their rules about adding someone to github.
Maybe u can create merge function beside?

But we have to wait for the devs and see.

THANKS again.

Re: "but for sure I don't know what their rules about adding someone to github."
Anyone can join github and make a pull request.
The devs will review the changes and accept or decline them.

@ntozier
OK sorry I meant 'the osticket' github part not github generally, sorry :P

But seems like it's possible for @ooglek then ;)

This is definitely something that I would love to see added to osticket. This feature would definitely help me sell this to management in adopting this over another ticketing system we are using.

+1

Throwing my own +1 into the mix.

We're looking to migrate away from another ticketing solution, and merge is essential. We get a lot of new tickets that should be replies to existing ones, and since we need to keep accurate track of ticket usage we end up merging a lot.

I've been thinking about this for the past few days. I'll work on the UI, and I talked with @greezybacon and he mentioned putting some energy into it as well.(his schedule is a little crazy so keep that in mind) @ooglek any assist is welcome, you and I can discuss the UI and you can discuss the backend with @greezybacon. I think we can get this going. oh and +1

Could someone perhaps put together a more formal RFC on the merge process so we could entertain issues with the merging process and work out some definitions on how to accomplish this in osTicket? I think some of the issues raised thus far:

• How are the threads merged? Are the items from the disparate tickets:
  
  
  
  • Intertwined in chronological order
  
  
  • The thread from the collapsed ticket(s) are added to the end of the merged ticket's thread
  
  
  • Separate threads shown in the UI via separate tabs
  
  
  • No thread merging is performed. Instead, tickets are closed and "related ticket" links added to the merged ticket
  
  
• How is the meta data merged? Specificly
  
  
  
  • The due date
  
  
  • Assignees (staff and team), as well as routed deparment
  
  
  • Custom data and forms added to the respective tickets
  
  
• What's the process for merging?
  
  
  
  • Multi-select action from the ticket listing queue
  
  
  • Action from the more drop-down in ticket view
  
  

I might try and type something up, but I don't have a strong use case for the feature, so I think others would likely have greater feelings and direction on how things should work

Somewhat busy at the moment, but my immediate thoughts are:

• Case-by-case choice of chronological merge or append of threads
• Per-item decisions for due date, assignees, etc.
• Action from the "More" drop-down

Our current issue (and this might be somewhat mitigated by having a portal as opposed to email only) is that a user will open a ticket, not receive a reply within a few hours (they might have opened a ticket outside of our office hours or we could be on holiday) and then open another asking if we got the first. We either have to close one which throws off our accounting, or merge.

The other case is where people will open a ticket, then send in more information in a separate email that, because of a different subject line, will be registered as a new ticket. This would also be potentially mitigated by using the portal, but we want to retain the ability to allow email-based tickets.

@greezybacon
I think first it would be good to see two options:

1)
From Ticket A and Ticket B to merge (as linked note) to the Ticket C.
With this step automatically an info about merge should send to user and
close A and B.

• Mean now, when u see under 'open' the Ticket C, u can see older or
  further options by just going over to the linked ones.

2)
From Ticket A and Ticket B merge to a NEW Ticket C.
Same functions as above, but Ticket C will be created new with implement
the existing ones.

In my opinion this r the major need things to keep ticket system clean.

AFTERWARDS an option to toggle Ticket A or Ticket B directly in the Ticket
C would be nice, but I think this needs some time (theming etc.) and isn't
so important for the main merge atm.

CHEERS!

I don't think merging tickets should result in creating a new ticket

I won't name names, but the way our current solution works is that you choose the ID of the ticket you want to merge into, then the other one has all its content replaced by a message to the effect of "Ticket ID XXX has been merged into ID YYY". This preserves the fact that there was a merge performed without creating a new ticket. However, since we bill based on ticket usage this still leaves two tickets when there should effectively be only one.

So it's important to maintain a record of what went on, but it's also important to do so in a clean and intuitive way.

One way that OTRS did it was to "link" tickets. For example, one ticket would be deemed "the master" and other tickets would be merged to it.

In the display, all correspondence would be "unionized" and displayed chronologically, regardless of which linked tickets the correspondence came from.

This allows a parent-child relationship. You could also "link" tickets in such a way that they were related, but still two separate tickets.

Tickets that were deemed children would not show up in the "Open/Closed/Resolved" display or counts.

I agree with @greezybacon that merging should NOT create a new ticket.

In my wholehearted opinion, once the tickets are created, they should not be modified in the DB structure, but use software to "merge" them. This way "unmerging" is possible, though new correspondence would only be added to the "master" ticket, even if the old ticket received new correspondence. Though that's not really necessary, but I think it would be cleaner to "freeze" child tickets when they are linked to a parent/master.

Not in first way, correct.

But often u need this option while cleaning up the tickets.
So u recognized new things updates or connections.

Now u can add it to an existing ticket, but don't know to which one or u create first a new and then merge them.

Why no option to directly merge to new?

Again I understand that the "merge" in first way means to to put things together, but in last option u create maybe a new ticket to exactly do this.

PS: Only my two cents on this for sure :P

CHEERS

@Hannibal226 -- Creating a new ticket -- how does a customer reply to the old ticket? How is that handled? At least with keeping the data structure the same, and creating a link between two tickets, a customer can reply to either ticket, and the reply-handling code doesn't need to change -- it can go into either ticket (yes, this isn't what I suggested with freezing the child ticket, I'm throwing out options). All you need to do when you pull up a ticket is:

• Does this ticket have children? If so, get all the responses from that ticket and merge them together with this ticket for display.
• Does this ticket have a parent? If so, redirect and display the parent instead of the child
• In the "open/closed/resolved" ticket count and displays, ignore and do not count tickets that are linked as a child to another parent/master ticket.

The modifications are much more simple, because you do not have to change the logic for handling an incoming reply... much. I just thought of a few things.

• Status Changes: Does Closing the Master close the child/children? Or does the child/children status get ignored?
• A customer response to the Child Ticket should re-open the Master ticket.
• Should status be synchronized between master/child?

I think keeping the structure of the existing system as similar as possible, only adding complexity where absolutely necessary, and not copying data around or running updates on IDs, will serve best and likely reduce the challenge of making it work.

Personally I like the idea of "linked" tickets and I think of a merge more like as a "group of tickets". So when user Alice, Bob and Charlie report the same issue, these tickets are then linked to each other and an agent can (think on email "reply" vs. "reply all" feature) then update, reply, etc. to all end users (Alice Bob Charlie) via that linked / merged tickets or to just a single user (Bob).

I think if doing it that way with linked tickets the hardest part is to make the UI so intuitive that it's easy and clearly understandable wether you as an agent update / reply / etc. to a "group of tickets" (how I'd call this) or to a single ticket.

From an end user perspective I think it would make sense to get the info that other users reported the same and all or only me (as a single end user) get now a response from the agent based on sense & facts like the importance of the message from an agent.

Merging tickets is really hard to realize I think since there are many ways how this could be implemented and also many different use cases for ticket merging approaches.

Cheers,
Michael

We've chatted about adding the concept of an "Issue". Issues are like the relationship between tickets and tasks. However, tickets are stapled to issues as a parent/child relationship. The use case I've often used is a datacenter outage. The IT group will likely receive several notifications of tickets rooted in the datacenter outage "issue". Therefore a new issue could be created, and all the tickets could be associated with the issue. Responses to the issue are broadcasted out to the respective ticket owners. When the issue is closed, then so are all the child tickets.

I think merging is something completely different. We've often thought of merging as more of a replacement operation. When merging tickets, all except the last ticket is effectively deleted. The threads are only accessible from the one remaining, merged ticket. Responses via email in v1.10 are no longer associated with the ticket; they are instead associated with the thread. Therefore, if the ticket is removed when merged and the thread is somehow associated with the merged ticket, then responses on the collapsed / deleted tickets would be continued in the merged ticket via its thread(s).

@ooglek

But what u have from a merged Ticket C when user answering to Ticket A and B?
I think with the "parents/childrens" stuff it's more complicated than just have links tickets which just closed.

So for sure all Users and Collaborators have to be merged in my opinion...

To stay on example of new ticket (which is not the main function we talking about) we always have to go ahead from one ticket:

So u r in Ticket B and create a new Ticket C, which means all users and collaborator will used as in B.
Then u have to merge Ticket A, which will only include the Collaborators if not already exists to C.

CHEERS

@Chefkeks I can't agree with grouping tickets from the user's perspective. That's too close to mixing potentially private information from separate customers' tickets, and would make it too easy for cross-contamination to occur.

I do think this is where Issues would be handy. As an example workflow:

Three separate organizations/users are reporting the same bug in the update process, so we create an Issue like "Error received when updating" then link those tickets to that Issue. Then create a Task to resolve the bug, and link that Task to that Issue, and by association the tickets.

-sorry hit the wrong button in new app-

I'm very interested in this however it seems rather complex. my requirements - (and those might be only mine) are much simpler.

customer a creates a ticket, customer b (or customer a with a different email address) writes regarding this ticket but not answering in the original thread. Now I copy the contents of the mail as an internal note and add the the second email address as a collaborator.

This works but the problem is that attachments cannot be transferred via copy&paste.
so for me a very simple merge or attach message to existing ticket would be sufficient.

@snizzleorg
This not simpler what u mean, what u do is just more manually :P

So we talking to make a link to a whole ticket, u r talking about getting texted out of the ticket.
At least we all need the same, but there r several ways and now there is the question of the most handy/useful ones.

Or u wanna tell me one button wouldn't be better that copy and close all manually? :P
(even attachment copy would be possible)

CHEERS

Ok, well I think "issues" as @greezybacon explained is what I had in mind with "group of tickets".

Regarding the end user perspective and the data security / private information from separate tickets you may got me a bit wrong.
My idea was more like a normal response that is broadcasted to all ticket owners so they all get the info from the agent and may also, based on organization the ticket owners are belonging to, what other users have reported. So keeping the tickets individual for the end users, but with some possibilities for agents to easier handle tickets with the same issue.

That said and read what Jared wrote about "issues" and how he thinks about merging tickets as something completely different, I have to admit that I'm more a "fan" of the "issues" and feel it may be kinda better way of merging or lets say handling/managing tickets.

Michael

@chefkeks

But don't u think it becoming confusing and complicated (in coding) to have one ticket/broadcast for staff, but separate for users?

I think then it's a lot easier to replace existing tickets from users to or better said against one.
So this should be automatically happened, when "old" tickets get closed and the same user/collaborator r in the new ticket.

The user can now also see that something is happening in this case which maybe is just a part, as it's stuff from second ticket (a bit theoretically now xD)

CHEERS

There is a need for both. There is a need to handle multiple requests from a single user which should be consolidated or "merged". There is a separate need for consolidating several different requests together which are related via a common "issue". The issue grouping does not imply granting users access to each other's tickets. However, it does imply the concept of "public tickets" where a issue might be posted to the client portal indicating something like "We are aware of datacenter issues at this time..."

The two should become separate features. They should not be combined.

I totally agree on that!

The two should become separate features. They should not be combined.

So I think with your last post in mind Jared, there should be 2 RFC issues here at github to discuss both independently from each other, but with a reference to each other, so people are discussing either only merging tickets or issues/groups of tickets.

Cheers
Michael

PS: Since the osTicket team is really experienced in coding and UI design I don't worry about it may be too confusing for neither agents nor end users.

@greezybacon

But why so "complicated"?

The users only can access tickets they r allowed to.
So why not concluding what u want, as users can't access for example a ticket of another one, if they aren't collaborator?
I think, if the privileges working well, there don't have to be a separation of that.

U even could name the "issue" - "project" or "task" or "group", but person x only can access the main(merged) ticket and tickets inside, as far as he in creator or collaborator of that.

Maybe I think a bit to small in this case, but I'm not sure if this becomes to big if u began to separate as there maybe coming new cases and requests for cases between, or?

PS: I'm just thinking in way of user and most nearly implementation, sorry if sounds so easily and isn't for sure xD xD

CHEERS

"Issue" implies a whole new paradigm for OST users to understand and manage. Like @snizzleorg said, When Customer A emails and Customer B emails (or Customer A emails from a different address), these are 90% of my merge cases.

For a while it was nice to have one ticket and be able to communicate with Person A about an issue, and then communicate with Vendor B about the same issue, but excluding Person A, but all still on the same ticket, in OTRS. But I don't need that, just was nice.

I really personally dislike the idea of an "Issue" being created because I told the system these two tickets are about the same issue really, regardless of who is on the ticket.

As @tmcnag mentioned, I think that "cross-contamination" is something the user should decide, not the tool. In some cases I may want to "cross-contaminate" in your opinion, but in mine it is a tool.

Why would a Ticket A and Ticket B, where a customer emailed once, then emailed again 5 minutes later to say "Oops nevermind" but didn't reply to the Ticket A, why that should become "an issue" -- they really are just one ticket that the customer failed to go through the process to make as one ticket. I just want to check the two (or three or four) tickets and "merge" them (IMO link them in case I mis-merge the wrong ones) and have a single, unified timeline of responses and conversations that allow me to manage everything in one ticket, as _I_ intended, even if the customer didn't "do the right thing" by replying to the right email.

I think adding "Issues" makes this all the more complex -- 90% of cases will be a customer emailed twice about the same thing and I want them in the same Ticket.

Agree with @greezybacon -- Issues are a useful concept. Merging tickets is a useful function. They should be separately developed and not co-opted.

I like the idea of a new type of ticket (issue) that would be sort of like a mega ticket. Which could be used for a combine multiple tickets into a single issue... or even opened by staff when/if something big happened that affected many. Personally I would rarely use this on either of my live sites. But I might want to use them for things like scheduled maintenance, large network outages, etc.

That being said I would probable use a merge feature more often. I would hope that it would be something like how we manually do it now. Which is to update one ticket (the later created one) saying there is already a ticket opened for this issue (reference ticket #) closing duplicate ticket. and then updating the original ticket with any additional information, and adding the opener of the second as a collaborator.

Im with @ooglek Issues and merging would be tow different things. The merging would be most useful for our company while the issues concept - not sure if we need that. It's nice though...

I feel like there's still some confusion.

Merging tickets, owners, threads, and data is:

• what causes "contamination"
• to help keep the same issue from the same person or group of persons in the same data and thread of communication
• (possibly) removes tickets when merged into another

Associating tickets via an issues

• keeps (every)things separate
• allows for separate communication, data, owners, collaborators, on "related" issues
• adds "related" tickets to a ticket view
• adds a new list of items to the system, "issues"
• allows for mass communication and closure

@greezybacon nice summing up. so basically two new features

@snizzleorg I'm suggesting that this is how the two features would work. I'm hoping to remove some confusion by suggesting to distinct purposes for two distinct features. My hope is to get everybody on the same page so we can work on moving forward with RFC and implementations for the features.

Nice. As said I'm more interested in the merging and think that at least this feature is nicely laid out. Question remains how to select the owner resulting ticket if the two initial tickets are different and hoot resolve conflicts in the ticket data itself.

I suggest:

1 +merge 2 = data/owner of ticket 1

2 +merge 1 = data/owner of ticket 2

I vote to give the user (agent) the choice what data the merged ticket will have.

So give the user a predefinition/suggestion of the data of the merged ticket which he can
A) accept and proceed with the merge or
B) change completely the merges' direction (so 2 +merge 1 = data/owner of ticket 1 instead of ticket 2) or
C) edit single fields (e.g. Help topic) before the merge of the tickets

@greezybacon On Merging Tickets, I think that there is some confusion about the effect of a merge to the user and the actual means of the merge in the backend.

• Contamination -- if both tickets are kept separate in the database, there is no contamination. Upon a "merge" action, a "link" between two tickets would be created, and a relationship type (Ticket 3 is a child of Ticket 4, Ticket 4 is the parent of Ticket 3). Software would keep linked Ticket Statuses in sync -- when a parent ticket status is changed, all child ticket statuses change. When a child ticket receives an email communication, that ticket communication is updated, and any status change of a child is then sync'ed across all linked tickets. Ticket 4 would display the communication updated in Ticket 3. In this case, there would be no contamination, and you could always unlink (unmerge) the two tickets with little to no affect (the only affect I can think of is if you added collaborators from Child Tickets to Parent Tickets when you merged, and you probably wouldn't want to undo that when you unmerge).
• Retaining Collaborators -- I believe 90% of merges will be from the same person, either from the same email or two different emails managed by the same person. The concern of that 10% is merely documenting heavily (and also in the UI at the time of merge) what will be done (Automatically adding collaborators to the Master ticket from child(ren) ticket(s)) and making sure the user knows that if that isn't what they want, to undo it. Or add a checkbox that is by default checked "Merge Ticket Owners to Collaborators in Parent/Master" and if you un-check, collaborators are not modified in the parent.
• Removing Tickets -- NO! Don't do it. That's bad.

Issues is a new feature, as of yet (to my knowledge) undesigned, unspecified, and amorphous. Could you use Issues to merge tickets? Totally! But is that really the intent of the Issues feature, to merge tickets? Or are you convoluting Issues to enable merging because that seems easier?

If Issues are common problems multiple customers are having, do users/admins of OST really want to see a bunch of "Merged Ticket" issues in the list? For many OST users, they might not need Issues, and I would be confused if merging tickets "created" an Issue. You lose the context of the Ticket when it becomes an issue -- now I have to handle "Merged Tickets" differently than regular tickets, and switch to a whole different area in OST to manage Merged Tickets, which then fall outside of the rules, escalation and operation in OST of Regular Tickets.

I really, really feel strongly that using Issues to implement Merge Tickets will cause way more problems and challenges, both for OST development and OST users, than to figure out a way to non-destructively implement Merging Tickets within the existing framework of Tickets as they exist today, with the addition of a table or two in the DB and some code and triggers to handle actions on tickets that are linked.

@snizzleorg I think you misunderstood @greezybacon comment -- he wasn't saying "two different features" he was saying "Issues solves everything cleanly." To which I disagree above.

@ooglek You're combining the concepts of issues (linked tickets) and merging. How can you merge two things and end up with two things which are linked? The idea of merging implies collapsing multiple things into one thing; hence removal of merged items.

@greezybacon @ooglek

MY opinion on this is, on database view ooglek is right and tickets shouldn't be just deleted.
On usage/interface site greezy is correct and u have to hide/replace the old stuff, otherwise merging is senseless.

BUT again, why so complicated?
Why the tickets just get closed with merging (maybe a specific merge status)?

This means tickets still reachable or better viewable via the main ticket/issue, but can't be changed anymore.
Or maybe a kind of snapshot will be implemented, so u can toggle it etc... (but this is design afterwards)

And that is the point where merge and issue can separate (MY opinion), so in merge the tickets closed and in issue it's an listing of 'open' tickets.

CHEERS

@greezybacon Merging is a UI concept, not a backend concept. From the user's perspective, the ticket looks merged, because once they take the Merge action, they see the Master ticket has all of the correspondence in chrono order in their view, and replying goes to all parties merged (or excluded at the time of merge). So the user sees a Merged ticket.

On the backend, you want to make things as clean and undo-able as possible. By creating a relationship between 2+ tickets, you can:

• Accept replies to child tickets via email because that ticket still exists -- no additional code or DB structure is needed to handle incoming emails with tickets that no longer exist.
• Unmerge -- replies will stick with their respective tickets -- the only lingering issue is the merged collaborators -- which could potentially also be handled in unmerging
• History -- The ticket history still exists, and you can view it directly, no new software changes
• Open/Resolved/Closed view -- since the child tickets are, from the user's standpoint, merged, child tickets are not listed in these views.

To implement Merge in this non-destructive way, I see three major changes and one minor feature/function addition:

• Relationship table. Links a ticket to another ticket with a relationship type.
• Modify Open/Resolved/Closed view of tickets. Exclude tickets that are children.
• Modify View Ticket. Merge correspondence from Parent and Children tickets, in real time -- e.g. select * from correspondence where ticket in (ticketA, ticketB) order by receivedDate desc. And when viewing a Child ticket, make it clear that it is actively labeled as a child and is read-only and you can't respond to it. Add a link to the master ticket.
• New Code: Merge adds the relationship, and copies (optional checkbox, or even better, a multi-select box with all the customer and collaborator info) customer and collaborators as collaborators on the Master ticket.

This simplifies merging greatly, allows you to not modify large swaths of code to handle "merged" tickets, leaves a trail of history behind so you can investigate when a ticket was "merged" or "unmerged", and is almost completely non-destructive (the modification in the Master ticket of collaborators could be construed as destructive; I don't think it is, but I don't want to discount that point of view).

@Hannibal226 and I seem to agree on most points. I don't think the merged child(ren) ticket(s) should be closed though -- I think when the master status changes, the child status changes, and vice versa.

For example, if the Master ticket is "Resolved" and a customer with the child ticket replies via email, then child ticket should go back to "Open" and thusly the Master and all other children tickets should also go back to "Open."

If you close all the child tickets as "Merged" then you have to modify more heavily the logic of handling new incoming emails. The ticket is status "Merged?" Do you still add the correspondence to the original child ticket? Or now do you modify the Master (which I think could lead to a giant mess if the merge was a mistake made last night, the customer(s) replied three different times, then I went to unmerge them -- and now customer A correspondence is in customer B's ticket.

@ooglek

So in ur way u want to open Ticket A, B and the "master" C as far as a mail going into ticket A.

But without knowing the code I would say this it at least at difficult/easy when mail coming into A, which is a merged one from C.
Which means only C change to online.
So here only one routine is needed (flag or via relationship table [like unmentioned]).

The sense of merge is cleaning up. So opening tickets, which also merged is unnecessary as keeping them open, when merged. (in MY opinion)
So ticket A and B just become invisible/replaced (for all user & collaborators) as soon as they got merged, so they can be closed (finish/forget).
In most cases u never need them again, so why keep status changing up?
Only in a few cases u maybe want to check something, so u can go to it via links and in last option to unmerge in.

So I see our agrees in:

• No ticket closing
• Issues not Merge, but merge can handle issues (at least I understand u like that)
• Merge/Unmerge function
• Merge mostly UI only less DB

but our actual different views maybe on:

• child - master (because more DB than UI in my opinion)
• status changed over all tickets, than just the "master"

CHEERS!

@Hannibal226

My scenario works like this:

• Customer A emails, creates Ticket A
• Customer A emails, same email address, creates Ticket B
• Customer A emails, different email address, creates Ticket C

OST User/Agent decides to use Ticket A as the "Master" and to Merge Ticket B and Ticket C to Ticket A.

• OST Creates a linked relationship, Ticket B is a child of Ticket A
• OST Creates a linked relationship, Ticket C is a child of Ticket A
• Since there are two different emails across these three tickets, the OST User/Agent decides to Merge other users other than the Master as collaborators; Customer A Email B becomes a collaborator on Ticket A

And now we're done.

If Customer A emails to Ticket C, that correspondence is added to Ticket C, just as it is now. If that correspondence triggers a state change (Resolved -> Open), Ticket C's state changes, as it does now, but also changes Ticket A and Ticket B state to match.

If Customer A emails to Ticket B, same thing happens.

If Customer A emails to Ticket A, same thing happens.

When the OST User/Agent loads Ticket A (Merged Master Ticket), they see all of the correspondence from Ticket A, B and C, inline. We could or may choose not to show that they are from the merged ticket in the Ticket View.

When the OST User/Agent loads Ticket B or C, they see a notice that this is a linked child ticket, with a URL Link to the Master Ticket, and that everything here is read-only, and replies must be done within the Master Ticket.

I'm not really sure what you mean in your 2nd paragraph. Can you rephrase?

Paragraph 3: I still disagree that Child Tickets (in your note, Ticket A and Ticket B) should be closed. What happens when a customer replies to that child ticket? Now you have to modify how to handle tickets that are in a new state (Closed Merged) or in a state plus relationship status (Closed + Child) and then add logic to change the state of the Master. And if the status is Closed, the correspondence shouldn't be added to that ticket but to the Master. But when you do that, you lose the ability to unmerge because now Correspondence that came in destined for Ticket A (child) is written in the DB to Ticket C (master) and if you un-merge, how do you pull the correspondence in Ticket C (master) meant for Ticket A (child) back into Ticket A?

I believe that customers hang on to tickets for a long time -- I've had customers email back on tickets opened 2 years in the past -- and I want to make sure those tickets get addressed.

I see our agreement here as:

• No ticket closing
• Offer a Merge and Unmerge Functionality
• Merge is mostly just UI changes, minimal DB changes and minimize code and process changes

And we disagree on:

• How to implement the child-master relationship
  ** me: Just a relationship table
  ** you: ??
• Issues
  ** me: Issues is a separate feature mentioned in this thread, but IMO unrelated to implementation of Merge features
  ** you: ??
• State of Master and Child Tickets
  ** me: I believe Master and Child Ticket state should remain in sync, so that customers can reply to any of the tickets, and that correspondence goes into the customer-intended ticket, so that during an Unmerge there is consistency and no mixing of unintended replies
  ** you: ??

I look forward to you sharing your thoughts on where we differ.

Is there an OST master group of developers? Any sort of process?

@ooglek

• How to implement the child-master relationship ** me: Just a relationship table ** you: ??
• State of Master and Child Tickets ** me: I believe Master and Child Ticket state should remain in sync, so that customers can reply to any of the tickets, and that correspondence goes into the customer-intended ticket, so that during an Unmerge there is consistency and no mixing of unintended replies ** you: ??
  
  
  
  • First of all we get close together with "master-child" relation and the relation table.
  
  
  • So I agree here, BUT not with managing statuses via multiple tickets.
    
    Reopen oder status changes should only have effekt on "master" (in ur example A) -- in my opinion.
  
  
  • All comunication should just be "redirect" to master, as far as it's merged. Because why u should use merge, when u want to add something to ticket B or C afterwards? [therefore unmerge]
  
  
• Issues ** me: Issues is a separate feature mentioned in this thread, but IMO unrelated to implementation of Merge features ** you: ??
  
  
  
  • Because Issues: U r right and we can discuss this sometime else :P
    
    I think only a different status handling (seperate from master) and new ticket creation could bring issue feature, without completly "redesign/-implement" things here.
  
  

I'm happy to the the interest and movement on this 'feature-request' ;)

CHEERS!

@Hannibal226

• Relationship -- agreed
• State of Tickets -- The reason I am suggesting that we keep the state in sync with Master and Child is due to the case where an email comes in destined for the Child.
  
  
  
  • If we "close" the children tickets, what do we do with this new email? If we add it to the correspondence of the Master, then we won't be able to "Unmerge" cleanly. If we add it to the correspondence of the Child to allow for a safe unmerge, now we have to undo existing status change code that would have made the Child "open" but now we have to suppress that and only change the Master to "open". That's some fundamental changes.
  
  
  • If we keep the child/master in sync, the new email goes into the child ticket, the child status is updated, and that (additive code, not modifying existing code) triggers an update of status on the other child and master tickets. It's one piece of added code, not a logic change in the new-email-handling code.
  
  
  • I think that the latter is cleaner, keeping the logic as is and simply adding one extra step for tickets that are part of the aforementioned Relationship table.
  
  
• Issues -- We agree! :-)

@greezybacon Would love to hear your thoughts. And is this one of those things that you'd like me to fork, modify, and then submit a pull request? Or do you want to implement?

@ooglek

• State of Ticket
  
  
  
  • Touché. I forgot the option of unmerge, which will be for sure easier and more structured, if mails going into that directly while it's merged.
  
  

Good to see we getting together here :P

CHEERS ;)

The merging UI could go along with the collapsable thread feature here:#2699

I think we should have an icon on the ticket listing indicating if a ticket has merged tickets. Then agents will know if they can un-merge from the ticket listing or from the actual ticket view.

There needs to be a system event of the merge and when it took place in the ticket view. Tickets that are being merged need to have a separate color indicator showing they are the merged tickets within the thread. like the colors for messages and notes.

At the bottom in the response dialogue it could list the email addresses of all the tickets merged and the agent can manually remove them when responding. Or use a dropdown on the send button to choose "Reply All" or "Reply Parent Ticket". Reply All could auto populate the senders addresses with option to remove manually. I'm thinking out loud here.

On the actual Merge after tickets are checked and the merge is selected a modal with options on what ticket is parent? What email addresses to keep for sending reply's? Options to close, claim, or transfer tickets after a merge is performed should be available. Possibly an option to append the merge or shuffle the merge by date? I'll think of other things later. This is purely UI thinking I'll let you guys discuss backend, I'll try to keep up. :smile:

+1

+1

Hello,

Any news about this wanted feature?

+1

+1

I've already done it for my version (v1.9.12). The function as below:

• User (guest) Foo use email [email protected] send to system, it create ticket X-1234.
• User Foo forget the email he use for ticket X-1234, then he use email [email protected] send to system. Now the email subject is new and does not have the ticket number. System create ticket X-2345.
• Staff (agent) will open ticket X-1234, choose Merge tickets. The form of ticket X-1234 and its threads will be remained. Threads of X-2345 will be merge into X-1234. Forms details of X-2345 will remain for further checking.

@cosmospham that sounds exactly like what I would need. do you have a branch or some way to download your code?

@snizzleorg Sorry because this is a private repo. Therefore I only can capture the commit changes for you. See changes in 03 screenshot files https://github.com/cosmospham/test-0

Firstly, add a menu.
Secondly, add a route rule.
Then create a ajax dialog.
Then write the merge function.
Notice: Only refresh the page after merging.

I think you can understand them.

My company currently uses the merge tickets feature for the following scenarios:

1. We have monitoring alerts go to our ticketing system. Lets say we get an alert that the firewall goes down. Then we get a ticket 30 minutes later that the firewall is back up. What we do then is merge the two tickets and close it. When the merge happens it merges the two tickets and the ticket that was created first stays as the ticket and the new ticket that came in, becomes part of the ticket history.
2. User emails in about an issue. Then emails again regarding the same issue but since they did not email in with the ticket number in the subject, the system makes another ticket for the same issue opened by the same user. Merging the two tickets together with the first ticket staying the ticket visible and the second ticket opened becomes part of the ticket history.

Being able to combine a bunch of related tickets into a parent "issue" is a really great idea but I think it should be seperate(as other people think) from the merging feature.

+1

+1, this feature would be so valuable to us. A very important part of our users answer to osticket email notifications using an email client which does not honor the headers expected by osticket

This is a great demand to have merge tickets feature since 2009 people discuss on osticket forum.
And I also check for any update from time to time, but sadly, there is only waiting again and again.

Why this feature so important (Within internal company)?

• If one of the services down, and 10 users feedback to you for the same issue, 10 tickets will be created.

• If service provider or vendor resolved a problem for you, and you would like to attach as a close ticket document, you cannot forward the message to osticket and merge existing ticket. You either have to copy the content or save as pdf to upload. But how about a message your service provider attach with many attachments? You will have many manual job to do.

• An user create a new ticket feedback some system issue, but actually we have already provided the solution one year ago. Why need to merge the old ticket with this new one? Because deal with office staff you will need to refresh their memory, let them to know they repeating asking the same question.

+1

+1

+1

+1

From working in MSPs, I understand how this would hinder your productivity as you would have to work on each ticket individually. It would be a great addition!!!

+1

+1

+1

We would really love to move our ticket system in-house (away from Zendesk). Ability to merge/split tickets are key factors in our decision. It's not uncommon to have 20+ tickets arrive from various sources (sales, resellers, vendors, shippers, automated systems, customer responses, etc.. etc..). The idea of manually merging all this stuff together would be nothing more than a nightmare.

We would be willing to chip in a few bucks financially to help get the process rolling. I have no idea how much it could cost but I would be happy to setup a GoFundMe Page. It seems we have enough "+1" here that a few bucks from everyone should fund the development time and save us a fortune on our Zendesk hosting.

+1 for version 1.10

+1

+1

Any news on if this is going to happen?

+1
This is so needed, I can even contribute with code to make this happen

I should note we already implemented this feature using ticket links and the code was posted online here:

http://osticket.com/forum/discussion/89699/osticket-v1-10-merge-duplicate-ticket-mods-attached

We included a link to a developer who can implement it for you if you are not comfortable doing it on your own.

Seems like something happened.... #3768
Thanks for sharing the work @Micke1101

I'm glad to see there's some work being done on this. +1

@Micke1101 Well done on that Pull request! Do hope it's merged into core soon! +1

3768 Needs more visibility.

Something new on this topic?

So, I guess 2020?

We want merging tickets too in osTicket 0.12.2! Vote for this functionality :)
No matter if it build as plugin or in core.
Thank you!

@antiuser

The official Ticket Merge feature is located at the link below. Follow that thread to keep up to date:

• https://github.com/osTicket/osTicket/pull/4990

Cheers.