Feature #1624

Issue merging

Added by Nikolai Bochev almost 4 years ago. Updated 23 days ago.

Status:New Start date:2008-07-11
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:Issues
Target version:-
Resolution:

Description

I know i could add links to related issues, but what i'd really like to see is the possibility to merge 2 or more tickets into one.

History

#1 Updated by Paul Rivier almost 4 years ago

That makes sens.
Let's say B gets merged into A. Accessing to B sould :
  • lead to a 404 ?
  • redirect transparently to A
  • redirect verbosely to A

Issue discussions can be merged automatically on a timestamp basis, but what about description ? I think merging operation should prompt for the new description, including both parent descriptions surrounded by tags like conflict tags with subversion. The person doing the merge should do something about that before validating the merge operation.

WDYT ?

#2 Updated by Nikolai Bochev almost 4 years ago

I think trying to access the merged ticket should redirect with a notice.
As far as the description goes - i am using OTRS at work, and it merges tickets keeping the original description of the host ticket, and adds the guest ticket's description down along the topic one a timestamp basis. What you describe should work also ( manually merging both descriptions ). The whole point for me on merging is to be able to merge duplicate tickets, but when somehow the duplicate adds something new to the related issue. So having the guest ticket's description down below in the notes will work also, as if you follow the "conversation" it will be just like someone updated the original ticket with new info.

#3 Updated by Fredrik Liljegren over 2 years ago

I guess you could be given the choice of automatic merging of #X into #Y, or manual merging. With automatic merging, something like what's stated above would work: Title and decription of the issue merged into (#Y) is kept, while the title and description of #X is added as a comment as "Merged with issue #X: Title...".

Merging is always preferrable to deleting double issues; if nothing else, you get a new watcher (the author of issue #X) and everyone can see more people wants the same thing.

#4 Updated by Fredrik Liljegren over 2 years ago

Oh, I forgot to add: I also vote for a redirection woth a notice.

#5 Updated by anthony george about 2 years ago

Kind of reviving a semi old issue here, but I don't see any newer comments/issue pertaining to issue merging. I really wish I knew more ruby, but my background lies with perl.
I use request tracker(RT) from bestpractical.com(http://bestpractical.com/rt) on a daily basis for work, but chose redmine for personal and all code management because of its integration with subversion.
So.. I thought a little insight into how another system does this may be helpful.
Anyhoo, RT accomplishes issue merging by using a database column EffectiveID, that, under normal circumstances, would be equal to the issue ID, but when merged, the EffectiveID is equal to the issue it was merged into. The routine(s) that load issues for view, etc load up issues by id, but "overlay" it with the effectiveID, thereby giving the look that it is a single issue..

Again, if I knew ruby(at all) I'd be happy to dive in and at least hack something up, but I'm at a loss.
Hopefully this is helpful

#6 Updated by Igor Kalashnikov about 2 years ago

One more vote for manual merging :)

#7 Updated by Per Oja almost 2 years ago

Another vote!

#8 Updated by Sönke Noack over 1 year ago

Oh, dear. I thought merging tickets is already possible in Redmine, but only began searching for such a feature as I couldn't figure out how to do this.

I'm also fond of the idea that it's done like in OTRS, which I had let being installed at work for handling customer issues.
However, Redmine seemed much better suited for the task of bug/feature/issue resolving and thus will hopefully supercede our homegrown bug tracking system, chiefly because of its procedure management, overview & reporting facilities.

If merging tickets really still isn't possible right now, is there any suggested workaround I can follow?

TIA and regards, Sonny

#9 Updated by Walter Heck over 1 year ago

I could also really use this. We have all emails coming from auto-creating issues in a redmine project called "unassigned". From there we move the issues into their specific projects. When we receive multiple emails in a discussion for instance, that creates a whole bunch of new issues, which is pretty annoying to handle :)

#10 Updated by Félix Delval over 1 year ago

+1 for that feature.

#11 Updated by Roland Discein about 1 year ago

+1

#12 Updated by Jason B about 1 year ago

+1 for this feature

#13 Updated by Mats Andreassen 6 months ago

I was surprised to find out this was impossible in current. Consider this a +1.

#14 Updated by Brian Jacobi 6 months ago

+1 I'm surprised this still isn't implemented. Concept of locking or merging please :)

#15 Updated by Terence Mill 6 months ago

The you suing the email import the wrng way.
If an issue is created is gets an id which will be refernced in "topic" filed for all mail notification are created for this mail. If any new mail includes the (not 100% sure) "[#issuenumber" string the mail will be added to existing issue as comment.

Walter Heck wrote:

I could also really use this. We have all emails coming from auto-creating issues in a redmine project called "unassigned". From there we move the issues into their specific projects. When we receive multiple emails in a discussion for instance, that creates a whole bunch of new issues, which is pretty annoying to handle :)

#16 Updated by Jason B 3 months ago

I'd like at add a +1 for this feature as well.

#17 Updated by Paolo Sechi 2 months ago

absolute a must. so +1

#18 Updated by Vlad Tyschuk about 1 month ago

Also, +1 from me for this feature.

#19 Updated by Jarek Potiuk 23 days ago

And +1 from me.

Also available in: Atom PDF