Want to be able to merge tickets

[dcrosta]

Rather than marking ticket A as closed and a duplicate of ticket B, it should be possible to mark ticket A as a duplicate of another without closing it; then when B is closed, A is closed as well, and the resolution message appended to both.

[ThurnerRupert]

i'd prefer the current solution as it is clear where a comment or a patch has to go. having 5 open tickets to the same topic would probably cause a maintenance fiasko.

[cboos]

Rupert, thanks for voicing your opinion, but in general it's best to let the Trac developers themselves decide what they won't fix or not...

It's a kind of hard earned priviledge :)

[cboos]

Anyway back to the topic of this ticket: I believe such a need can arise when different customers are reporting the same problem.

In general, you wouldn't like to redirect a customer to the ticket opened by another customer, but rather keep the ticket dedicated to the customer who opened it.

See also #886 and #475 (not duplicates, though).

[Volte]

Nothing wrong with providing the option and giving the administrators the option of performing actions they wish to perform. I work with a group of developers, and some tickets overlap each-other, condensing related tickets into one would be helpful, while perhaps keeping the original ticket open should it be linked directly too, but not necessarily returned in a SQL query.

[mgood]

In order to implement this we need to decide on what it means to "merge" several tickets. Where do the description, milestone, etc. of the merged ticket go? Are the comments interspersed in chronological order, or somehow separated based on the original ticket?

Volte: it sounds like you actually want to keep the tickets separate, but link them so that they are both closed at once and counted as 1 ticket. It seems like this would cause confusion since there are now 2 or more open tickets where comments can continue, so users following the issue must watch all the duplicate tickets. It'd be helpful if you could explain what shortcomings you see with closing tickets as duplicates that you could address by "merging" the tickets.

[anonymous]

As someone who administers response systems that support merge, I agree that option behaviour customised in config files is good:-)

We are using Trac as both a design support tool and, with email2trac, as a "response centre" for product and facility maintenance. We are in the process of moving some of our older systems to Trac and undertaking data migration.

In our existing systems that support email submission we often have instances where email issues are raised and then the reporter fails to reply to their previous contribution opening another ticket. For this merge is invaluable. Some users do this repeatedly.

To be easy to follow, both suggested merge mechanisms may be ok, however:

• If appending the ticket to be merged at the end of the remaining ticket with a clear token comment or rendering style indicating what was merged, then new comments on the ticket are added after the merged block in the normal style;

• If interspersed in date-time order merged content should be visually different to the original ticket. It is then possible to determine which comments have been merged in and which were present in the original ticket.

I agree that keeping the original ticket open will only confuse people. Most response systems I've used would changed a merged ticket to a status of closed and a resolution value of "merged" rather than "duplicate". I see no reason why merge and duplicate should not remain as for some cases you have a duplicate but may not be decided if it should be merged.

Also, if possible, a statement to the effect of "merged into #xyz" on the ticket to be merged would be helpful.

[cboos]

The new ticket comment threading feature recently introduced in trunk could help here (see #2703 and r3364):

The description of the ticket to be merged (A) can be merged as a new toplevel comment in the remaining ticket (B), and the toplevel comments from ticket (A) can then be made child comments of that new toplevel comment in (B), therefore keeping the information of where they came from.

Just in case the above was not clear enough, here's a picture :) The number in parentheses after the comment indicate the time sequence in which the comments were made:

Ticket A:                      Ticket B:
 DescriptionA                   DescriptionB
  commentA 1     (1)             commentB1    (2)
  commentA 1.1   (3)             commentB2    (4)
  commentA 2     (5)             commentB2.1  (7)
  commentA 1.2   (6)             commentB2.2  (8)

now A is merged into B:

Ticket B:
 DescriptionB
  commentA 3.1   (1)
  commentB 1     (2)
  commentA 3.1.1 (3)
  commentB 2     (4)
  commentA 3.2   (5)
  commentA 3.2.1 (6)
  commentB 2.1   (7)
  commentB 2.2   (8)
  comment 3 
  (containing something like: "Merged from Ticket A" 
   followed by DescriptionA)

Note that the above solution make it possible to merge many tickets in one, while retaining the possibility to always know from where each comment comes, without the need of making each of those visually different.

[lschiere@…]

I and the other developers at www.pidgin.im would also like to see a way to merge ticket items. I prefer the method described at 06/07/2006 06:36:03 AM, but either would be just fine really.

[igor sviridov <sia@…>]

I'm used to the way RT merges tickets, where:

- references to merged ticket would bring you to ticket it was merged into - all merged updates retain references to original ticket number

it would be nice to support view which would show only specific ticket in the merged "super-ticket", but this was rarely needed.

--igor

[cboos]

#475 and #6530 were closed as duplicate.