Related to this issue, if a ticket with a separate subject is merged, a reply to the lost subject will be created as a new ticket.

Consolidating related merging issues. CHD-678 is about comments not merging when tickets are merged.

Dupe... Please watch CHD-174

Consolidating Merge issues. CHD-435 is about Audit Logs needing to be merged, and how that merge should take place. See: http://www.cerb4.com/forums/showthread.php?t=401

Comments:
=======================
  Comment by Steven Van Ingelgem [03/Jan/08 01:06 PM] Delete
[ Permlink ]
In fact what I meant in that thread is that when you merge 2 tickets, you loose the audit log of 1 of the tickets.
It's better to also merge the audit logs (maybe with the ticket ID so you can see which ticket had what ID before & after).

example:
* ABC received
* ABC replied
* ABC new message
* DEF received
* ABC merged with DEF

Comment by Dan Hildebrandt [03/Jan/08 01:32 PM] Delete
[ Permlink ]
Yeah, that's what I was trying to convey, Steven, I just failed miserably at it... ;-)

The actual bug to fix is that the audit logs need merged, and it's a possibility that we may want to indicate which original ticket id each log entry was referring to.

Comment by Jeff Standen [03/Jan/08 11:47 PM] Delete
[ Permlink ]
Since the audit log is a plugin, and 'merge' is in core, we just need to create an event point for merge that the logging plugin can observe. I've added this to my usability list.

Comment by Mike Fogg [21/Feb/08 03:00 PM] Delete
[ Permlink ]
We might want to update the ticket updated date and include the fact a merge took place in the audit log when we perform the merge as well. Mirko pointed out that the updated date doesn't change in this forum thread: http://www.cerb4.com/forums/showthread.php?p=3237

Comment by Mike Fogg [28/Feb/08 03:01 PM] Delete
[ Permlink ]
Mirko (from forum link mentioned above) would prefer that the ticket update date be changed to the most recent update date of the tickets being merged, rather than the time the merge actually took place.

I would like to suggest that this be escalated above minor, now that this ticket is a combination of merge-related issues. This particular item was originally a minor issue. Unless you are trying to rate bugs relative to one another, this seems relatively important. Especially to those of us using 4 in production now who are losing comments and audit log entries when merging tickets.

-Lawrence

I agree with Lawrence. This is equivalent to merging being broken. Its totally unusable as all record of one of the merged ticket numbers totally dissappears with not trace

Bumped the priority and assigned to myself.

Just to highlight a piece of this - when 2 tickets are merged - it's not just the audit log that needs to be patched up. The "last action" and other status indicators need to be cleaned up as well.

For instance - ticket A is "waiting for reply" and "last message was sent 3 days ago"
Suppose ticket B is customer's reply that didn't get linked up. You merge B into A, but the status/state of A never changes - so unless you notice this, it could go into never-never land. I don't think last activity gets updated on A either, so it's not obvious that something has happened.

Instead of automatically merging into the earliest ticket.

DBowsky in the forums preferred the 3x method of being able to select a single ticket and tell it to merge into a given ticket number.

http://www.cerb4.com/forums/showthread.php?p=5482#post5482

This is implicit in the request to merge the Audit logs, but I wanted to explicitly state the need for a ticket.merge event point

DAO.class.php
// Tasks [TODO] This could use a ticket.merge event point later

:)

Where is this at in the development phase?

I ask because in the event of a 'breakdown' and a lot of customers mailing in, it would be nice to create one ticket and as 'more' reports come in, merge them in cleanly to the master ticket.

I'm also experiencing this problems, my coworkers are reporting that comments on one message are not being merged in when they merge tickets, and I've confirmed it myself by testing, when merging tickets, all information should be merged, not just have information that is no longer accessible to anyone.

The comments not merging was reported again by CHD-978. This is a reminder that people may be losing comments inadvertently without knowing it.

When this is fixed notify this thread:
http://www.cerb4.com/forums/showthread.php?p=7755#post7755

Alright, this is resolved for Build 834 (4.1).

The reason this was delayed so long was because most message threading on reply happens from the message headers. The old messages are merged to a new master ticket, and replies happen at the message level and not the ticket level. Headers are favored compared to ticket subjects in the subject line, even if they exist. There are some oddball situations (some mobile e-mail clients; and *cough* Microsoft) where a reply doesn't contain the standard headers about what it's responding to, and this is the situation where the lack of ticket mask forwarding would crop up (at least in the automated e-mail parser).

We have the tendency to not want to add clutter to work around other components which violate standards; however, I can definitely see how not being able to follow any ticket links to masks that were merged elsewhere is annoying, and it's the main reason we ultimately implemented this.

The upside is this is implemented low-level -- you should now be able to type "/display/XXX-XXXXX-XXX" in your browser (or from clicking an old URL) and end up on the new merged ticket. This will also happen on replies with subject line info. And the system should now never reuse a mask for a ticket that was forwarded in the past and then deleted (although it will reuse masks on deleted tickets from spam once they leave the DB).

The downside is this is an extra query (since it's low-level) in several high volume places, such as parsing incoming e-mail and generating masks. It's likely worth the slight performance tradeoff, but important to understand why we sometimes hold back if something isn't *absolutely* necessary. Seemingly trivial conveniences can have large performance tradeoffs.

Thanks for being patient!

(This also includes the "ticket.merge" event point, as well as fixing ticket comments not merging)

Also used the 'ticket.merge' event point to merge audit log entries.

Verified fixed as of dev build 836.

If you've been following the way Q/A usually handles JIRA issues with this much feedback, you'll know it's a long and drawn out process. Aside from verifying that Jeff's described fix went through, as detailed in the original description and his last comments, I'm also going to verify all the community feedback. Any still relevant issues will be transferred to new JIRA requests and I'll list the new tracking numbers below.

So look through each @user note below to see whether or not your feedback has been fixed, or has been moved to a new issue.

@Simon Manning

Your issue has been completely fixed. The "slave" ticket that is absorbed into the merged ticket and loses its subject, will properly attach new replies to the fully merged ticket as opposed to creating a brand new ticket.

@Dan Hildebrandt [WGM]

Regarding "CHD-678: Comments not merged when merging tickets" should now be fixed. In my simple test, comments from both individual tickets appeared in the merged ticket.

@Dan Hildebrandt [WGM]

Regarding "CHD-435: Merge Audit Logs when merging tickets". Now from what I can tell the audit logs of the individual tickets is definitely fusing together after the merge. However virtually none of the individual feedback has been implemented as part of this general audit log fix. Ironically this was originally a separate request and it seems odd to open a new request. But I want to actually separate all the individual feedback anyway and simplify things. Here are the new issues in JIRA:

[Audit Log] Label which log entries came from which ticket after a merge
http://www.wgmdev.com/jira/browse/CHD-1042

[Audit Log] Indicate in the log that a merge took place at a specific date and time
http://www.wgmdev.com/jira/browse/CHD-1043


Note this particular feedback on the CHD-435 issue:

Comment by Mike Fogg [28/Feb/08 03:01 PM] Delete
[ Permlink ]
Mirko (from forum link mentioned above) would prefer that the ticket update date be changed to the most recent update date of the tickets being merged, rather than the time the merge actually took place.

This actually works as described already (or may have been recently addressed). That is, the most recent updated date is carried over to the merged ticket.

@Lawrence Sharp

You guys should no longer be losing comments and audit log entries.

@Travis Swan

No individual messages, comments, sticky notes, or audit log entries are going to be lost anymore. As far as keeping track of exactly what pieces belonged to which tickets through the audit log that's still in the open. See the new JIRA issues I just listed above.

@Paul Kulp

(quote)
Just to highlight a piece of this - when 2 tickets are merged - it's not just the audit log that needs to be patched up. The "last action" and other status indicators need to be cleaned up as well.

For instance - ticket A is "waiting for reply" and "last message was sent 3 days ago"
Suppose ticket B is customer's reply that didn't get linked up. You merge B into A, but the status/state of A never changes - so unless you notice this, it could go into never-never land. I don't think last activity gets updated on A either, so it's not obvious that something has happened.
(end quote)

I'm not sure how to respond to this as I'm not sure exactly what you want to hear. As far as I understand just because one ticket merges into another, does not mean that every stat, property, action, or value is pulled entirely from ticket A or B. It will be a mixture of both, so for example 'updated' and 'last action' will be taken from the most recent values regardless of ticket age, on the other hand I believe fields such as the ticket mask, subject and 'next action' will be taken from the oldest values regardless of ticket age. In other words one ticket does not completely consume another ticket and the stats grabbed can be older or newer based on what information makes the most sense.

See CHD-744 comments for more details. Now it's possible you were seeing "merge" before it was patched up so this could be satisfactory to you.

@Joe Geck [WGM]

DBowsky's requested the 3x method of choosing a ticket to merge into via manually entering the ticket mask as opposed to checkmarking tickets from a worklist. This actually duplicates an open request currently scheduled for an upcoming release:

Merge arbitrary tickets from Display Ticket
http://www.wgmdev.com/jira/browse/CHD-720

@Paul Kulp

As Jeff responded in his last comment he is now using the 'ticket.merge' event point.

@Mike Horwath

"Where is this at in the development phase? "

The general fix has been verified and the new JIRA items handle the leftover suggestions. It's up to you to decide if we have a satisfactory merge system in place.

@Nicholas Moline

As I said at the top, CHD-678 is good to go and comments should not be lost on a merge.

@Joe Geck [WGM]

Thread http://www.cerb4.com/forums/showthread.php?p=7755#post7755 has been notified.

@Jeff Standen [WGM]

Everything Jeff said in his last comment is working, except this particular statement:

(quote)
The upside is this is implemented low-level -- you should now be able to type "/display/XXX-XXXXX-XXX" in your browser (or from clicking an old URL) and end up on the new merged ticket.
(end quote)

I'm going to play around with this some more and have another developer test it for me. If it is broken I'll file a new issue and let you guys know.

@Joe Geck [WGM]

In response to my last statement regarding the "/display/XXX-XXXXX-XXX" not working, well it's still not working correctly for me after a few more tries. To keep this issue closed, I filed it under a new separate issue which you can follow here:

CHD-1053
[Merge] Typing the ticket mask of the absorbed ticket does not forward you to the newly merged ticket

@Joe Geck [WGM]

CHD-1053
[Merge] Typing the ticket mask of the absorbed ticket does not forward you to the newly merged ticket

was a misunderstanding on my part and is actually working. Basically this works AFTER you purge the deleted (absorbed) ticket via Schedular -> Maintenance.

So basically everything in CHD-174 is accounted for! :)