Two support-desk problems look similar on the surface and need completely different handling: a customer accidentally files the same issue twice, versus a ticket that was filed under the wrong ticket type and needs to become a different kind of request entirely. ThickGrass treats these as two distinct operations, on purpose, because collapsing them into one “combine tickets” button causes real data problems.
Merging: for actual duplicates
When two tickets are really the same issue, merge folds one into the other — comments, attachments, worklogs, and tags all move onto the target ticket, and the source is flagged as merged and left as an empty, permanently-linked husk. It’s never deleted, so the history stays intact and auditable.
Two rules protect this from going wrong: you can’t merge a ticket into itself, and you can’t chain merges — a ticket that’s already been merged can’t be merged again, and you can’t merge something into a ticket that’s already someone else’s merge target. Without that second rule, you could end up with a tangle of tickets pointing at tickets pointing at tickets, and no clean answer to “which one is actually the real record now.”
Transferring: for the wrong ticket type
Transfer is a different operation for a different problem: a ticket was filed as, say, a “General Support” request but it’s actually an “IT Equipment” request, and equipment requests have their own SLA rules, checklist templates, and custom fields that only apply if the ticket is actually of that type from the start.
Transfer creates a brand-new ticket of the target type and copies the relevant data across — comments (work notes included, with original authorship and timestamps preserved), attachments, tags, worklogs, and custom field values. The original ticket gets force-closed, but it stays independently readable — a real, complete historical record, not an empty shell like a merge source.
The detail that actually matters: attachments aren’t just re-pointed
Here’s the part that’s easy to get wrong and expensive to get wrong quietly: when a ticket transfer copies attachments, ThickGrass physically duplicates the underlying file on disk rather than pointing two database rows at the same file. Why it matters: if two tickets both “own” the same physical file and either one later deletes its attachment, deleting the file breaks the other ticket’s download link too — silently, and probably not until someone actually clicks it months later. Duplicating the file costs a little extra disk space; it costs nothing in “why is this six-month-old ticket’s attachment gone.”
What this looks like for you
You get one clean action for “these are duplicates” (merge) and a separate, clean action for “this needs to become a different kind of ticket” (transfer) — each with the data-integrity guarantees that operation actually needs, not a single button trying to do both jobs and getting the edge cases wrong.
