Merging Custom Fields

[BigDawgRob]

Hi,

Further to bug report 271: Merge Ticket A with B: retain A's Custom Fields which has now been implemented, I would like to suggest some improvements to merging of custom fields.

With the introduction of this new bug fix, custom field values for both tickets being merged are kept in the database. So if there are no custom field values for the target parent ticket, then the custom field values for the child ticket being merged are displayed on-screen.

However with the current approach, there are some issues:

a) All custom field values are stored in the database against the single ticket id. This is because the custom field values of the ticket being merged are given the same ticket id as the ticket they are being merged into.
Anyone like me who has a number of reports running off custom field values for each ticket will find these reports break, as it's assumed that there's only one set of custom fields per ticket.

b) When one of the tickets being merged has no value set in a custom field (as rationale for the bug report) things are good. However, should there be a custom field value for both tickets being merged it becomes confusing as to what data is displayed.
Each Kayako ticket is only capable of displaying one set of custom field values. Now that Kayako stores multiple sets of custom field values, it is never clear to the user what data will be 'kept' and what data 'lost'. I have found this particularly true if you start merging three or more tickets together.

So my proposal would be that.
1. There is only ever one set of custom field values per ticket (in the database as well as displayed on the ticket).
2. When merging tickets, the custom field values of the target ticket take precedent over any values in the source ticket. This rule is already true of other ticket values such as subject, user, status, priority etc. So it would in my mind make sense to extend this rule to custom fields. The only exception being is the target ticket does not have a custom field value. In which case the source ticket custom field value takes precedent (as per the bug report).

Phew! Thank you for reading my post, this is not such a simple subject as I first thought! Please let me know if you would like me to explain this all further.

Thanks,

Rob