We often get duplicative cases entries and we'd like to be able to combine them.
UPDATE: Check out the Case Event Merge Plugin
|
107
12
|
|
|
|
closed as no longer relevant by Rich Armstrong♦♦ Jan 17 at 19:20 |
|
9
|
My company's frustrations are similar to Sebastian's. FogBugz is very particular about how it keeps track of email threads. Sometimes, we don't add the proper (Case xx) tags when responding to a message from a client, sometimes our clients respond to older emails without these tags... As a result, we frequently end up with a large number of new cases in the Inbox, most of which are actually from the same email thread. This gets messy very quickly, and even if we manually make each of the response emails a subtask of the original email, we can not see the entire conversation on a single page. While I understand the complexities of merging cases generally, I believe that cases generated from emails should be much more straight-forward to merge. Essentially, the message and any attachments would simply be joined into an existing thread based on its timestamp. Any FogBugz attributes in the message would be replaced by those of the thread into which it is being merged. To avoid having to address the greater challenges posed by general merging, you could limit this functionality to just the Inbox, or just cases that consist of nothing but email messages. As a correlary, our clients sometimes respond to old emails when in fact they are making a new request. It would be very helpful if we could split an email thread into a separate case, and move all messages past a certain point into the new case. In general, email messages could be treated more fluidly than other types of cases. It should be possible to group several email messages together into a single case, and to move email messages from one case to another where appropriate. Rather than each email message being a FogBugz case, FogBugz cases would contain email messages. |
|||
|
|
|
7
|
re: compelling use cases/scenarios we use FB as a project management tool - bug tracking is only a tiny bit of the scope.
in all situation i dont really care so much how the exact ordering/joining to be done. i only wish there would be a simple way to have all related information on the same page again. |
|||
|
4
|
We really need this. We're having the exact same problem everyone's mentioning. Clients reply to an old email without the case number and a new case gets added. We just had a case opened 3 times because people kept replying to an email without the case ID. I ended up doing the resolve as duplicate for the latter two cases, but each case had separate important information. I ended up just copying the message from the last case into the first one (the 'real' one) and closing it. Since they're all opened as email messages, you'd just have to add the replies in timestamp order to the main case. You wouldn't have to worry about merging and resolving properties and all that, keep the main case exactly the way it is, and just add the messages from the 'duplicate' cases. You say you have no use case for this, but everyone's saying the exact same thing, just add the messages from the latter cases to the original one. To get to your points: 1) Yes, just interlace them. No, it wouldn't destroy any coherence as most of the time the emails just add more info. 2) The merged case looks just like the original only with the messages from the others added in. It would have the properties of the original. It is different than closing as duplicate since the messages of the 'duplicates' are now in the original. 3) It is really inconsequential how the user is notified. The important thing is that all the messages are in one place. If you really think the users need to be notified, then ask yourself how the correspondents of the duplicate cases are notified when their cases are closed as such; and how the correspondent of the original case gets notified in such a case... Just do the same thing, except instead of emailing them with "your case XX has been closed as a duplicate of case YY", say "your case XX has been merged into case YY". 4) Yes, it absolutely would be worth figuring out how to do it, in fact I just did. Either that, or just have your email system be smarter and not rely on the case ID being there to figure out which case an email is for. Usually the original text is quoted in the new emails. |
|||
|
|
|
3
|
We hear this feature request a lot, but we haven't found a compelling use case or design that would add value. Here's some of the questions:
|
|||
|
3
|
Now that FogBugz has subcases, we resolve as duplicate and add as a subcase of the duplicate. |
|||
|
1
|
another frustration with the above mentioned "resolve as duplicate" situation: the then-fragmented case history is persistent and will add noise infinitely to all future searches. so *every person" doing a future full text search will be confronted again and again with the cases CLOSED (duplicate) while it completely makes sense to have CLOSED cases as a future reference, under which condition the existence of errorneous duplicates contains useful information? |
|||
|
|
|
1
|
We suffer from customers that include others on emails to our Support Project and in essence start a discussion that should be tracked by time and threaded together, but because they were copied on the original email none of them is aware of the Case Number or even that they should be responding to a case. While closing the case as a duplicate and creating a sub case to the main case is an option it is still not a manageable way to manage threads like this...Right now we manually forward the email into the originating case and close the others as duplicates. This manual process is very cumbersome. We have been FogCreek FogBugz customers for 5 years and this has been an issue from the beginning. It seems as though from the number of requests for this enhancement that as a company you would want to take a hard look at getting this into your product. It is easy to look at case merges as a complicated task and turn it into something that seems unmanageable as an enhancement. Instead of thinking about automating the merges, why not start with a way for us to clean house...meaning allow us to select cases to be merged and if they should be merged chronologically or by user comments etc. Allow your user to select how they want to merge the cases and then it is on us if it goes wrong. Any new emails coming into any of the merged cases should then be forwarded into the new merged all inclusive case. Thanks for considering the input. Regards, Rich Platt |
|||
|
|
|
1
|
everything is said above, for illustration a picture of our current inbox filled up with a sediment of creative misspellings of the case (xxxx) syntax. i agree its easy to get, but people constantly dont get it. what i am supposed to do with it? i dont want to waste 30+ seconds of my time with any of these.
|
|||
|
|
|
1
|
Can someone from FogCreek address our request as it relates to upcoming releases? This is a feature that is really needed in order to make it reasonable to use FogBugz in Cases where many people are responding to emails on Cases. |
|||
|
|
|
1
|
I am a little surprised this still has not been handled after two years! I think there is a lot of over engineering in many of the discussions above. Rich Armstrong's original question "how exactly would this work" has not been really answered here in detail as far as I can see. Although Christian123 I think commented on that post similarly but with less detail than I am here. This is to resolve a specific issue that many seem to face as I do, but I guess Fog Creek still doesn't get it? Issue: Almost exclusively caused by a new case being created when an email is received that is not linked by Fogbugz to an existing case, even though it is indeed an email regarding an existing case. Recommended Solution: At the very least, when you have a case that is in the Inbox/Undecided, have a button "Belongs in case..." (name this button whatever you feel works best). If the user presses this button, the user must enter an existing case number, and press enter or "OK" button. At this, the email (contents of this Inbox case) becomes an entry in the real case (as if the email filter had been able to make this connection and the email just arrived). I don't really care if it is in chronological order, it should be pretty close, anyway, if you process your new Inbox/Undecided messages regularly. I would simply delete this new case permanently, as it is really just noise - a case created when it was not required or wanted. If it leaves a hole in the continuity of case numbers, I'm ok with that. I would prefer it simply go away, especially if you do add this new "activity" and it has that case number assigned to the email in the Inbox project, then at least you could find this activity comment if you had to... But I really don't think anyone cares about it... As a matter of fact, getting rid of it altogether would prevent searches from returning these "noise" cases, also prevent them from being counted in statistical analysis. They are not "cases". They are emails related to other cases that generated a case number in error... I hope you find this detailed description helpful, and I hope this feature is added soon. It is SOOOoooooo annoying when an email goes out to a bunch of folks without the case number in the comment, and fogbugz is cc'ed, and then they all reply all, and I get half-dozen or more "new" cases. All of these emails I usually want right in the activity of that case, certainly not as a bunch of sub cases or related cases closed as duplicates. They are not duplicates. They are not subcases. They are not cases at all. They are simply mishandled emails. I would really appreciate it if someone from Fog Creek would comment on this and say, after two years, and so many votes it is at the top of the list, what is the plan? If FC has another way than I have described, please let us know so we can comment on it. My suggestion does not seem to me terribly difficult to implement, is straight forward, and leaves little or no ambiguity. Another thing... Some people in their answers above want to "merge" any two cases. Well, that is harder to comprehend. If one really has two cases, with activities, and one is a duplicate of the other, mark it as such and close one of them. If you want the contents in the original case, well, I would cut and paste them with a comment that they came from that duplicate case... If the thought of merging any two cases is making your head spin regarding how/why - skip all that. Let's stick to the issue that is 99% of the problem we all want addressed - emails that go to Inbox/Undecided that really belong in other existing cases. And one final comment: Paul Sweeney above indicated that this other case: http://fogbugz.stackexchange.com/questions/2961/fogbugz-should-match-references-header-to-existing-case-message-id-when-no-case/7665#7665 Was the "real" issue. I must strongly disagree. While that case would be great to see implemented, this is not a problem cause only when the mail processor does not recognize what case it is related to. Someone could send a brand new email to fogbugz about an existing open case, and simply not put the case number on it, and use any subject they choose. We, the users, need to reclassify it as simply an email activity in another existing case, without all the difficulty we face now. |
|||
|
0
|
I concur - I want to do this very thing for the very same reason. It's a real requirement which has a common sense implementation. |
|||
|
|
|
0
|
Just want to add that we could use this as well. We have more than a few email case threads that need to be merged into one thread. Very frustrating that we can't do this. |
|||
|
|
|
0
|
Not having merging on email-based cases is a major pain in the rear. This also can't look good when people are shopping around for bug tracking/support systems, because almost every other viable system out there supports merging. Please implement this feature! Everyone is begging you to! |
|||
|
|
|
0
|
In my opinion, this only goes half way. The ability to merge duplicate email cases to tie together emails that are actually from the same 'thread' or 'chain', is really just a fix to a separate issue. If FogBugz could make use of the email headers it stores, using the references: or in-reply-to: headers to match against message-id headers, they could avoid this scenario altogether. In the feature request below, I've added a snippet from the IMAP Thread Protocol, which explains how any email tool can properly identify and chain together separate emails, and determine correct ancestry using the simple headers. Yes, merging the duplicates tidies things up in the inbox and groups things logically, manually, when FogBugz does it wrong - great. Still a manual task though. Wouldn't it be better if any replies or forwards, without case-numbers, were linked automatically to the right, initial case, without any manual intervention, so long as FogBugz can see the references/in-reply-to headers and match to a known message-id? If it can't it would then fallback on this manual merge process to allow a user to correct it. |
|||
|
0
|
Agreed, another vote for the same functionality for all the same reasons listed by others here. EDIT APRIL 2011: Since my original posting, this has become a critical issue - it is easily the single largest problem we face in our processes for managing customer facing support issues. In the longer running issues that are coming up, we are now creating a parent case, subcasing all the "sub-threads" to that case and manually copy and pasting content from the sub-cases into the parent case to create a readable thread. This has all sorts of issues (timestamps are the edit/copy/paste timestamps, not the real timestamps, material gets missed and can get out of order if the edits are not performed in the right order, etc) but at least we can actually make some sense of what's going on for our customer and hence have a chance at dealing with it. The current behaviour has caused many customer miscommunications on our behalf, which in turn causes more issues - and more threads which we can't merge. In short, this at least needs acknowledgement from FogCreek that it is an issue. I appreciate the complexities that finding a solution raise - we build software that has similar requirements and situations - but this is a fundamental use case, IMO. |
|||
|
|
|
0
|
We really need this, too. It's the most frustating thing about FogBugz! I already was thinking of writing me a small .NET program which uses SQL to rip out a bug event with an email and moves it to an existing case. But I never came around to implement it and was a little (but only a little) bit scared it would leave no clue behind where it was taken from. Just move the bugevent into the correct case and leave a tiny stub pointing to the new bug event in the correct case! |
|||
|
|
|
0
|
We need something similar to this. We might get a single bug into the database, and then 5 other users submit the same bug. It is important to know that there is now 6 submissions for this one bug, and it is important to be able to reference all of that history. Is there an easy way to "link" new submissions to an existing case like that? |
|||
|
0
|
I will add another vote for merging. We get a lot of customers that keep sending "new" emails to us with more info on the first email they sent. For some reason they don't think to reply to the original case. This happens a lot when they are sending in screenshots etc - a new case for each little screenshot. Would really like to merge them into one case so I can see all the context in one place. |
|||
|
|
|
0
|
Any word from FogBugz on when this will be addressed? As we rely more and more on FogBugz for Customer Case Management it is becoming a bigger issue. We are forwarding emails from one case into another, copying and pasting from other cases into another...It is becoming a very manual process to use FogBugz. Some insight from FogCreek would be great as to when they can address this issue. |
|||
|
|
|
0
|
I add another vote for merging. Even if a manual move option were provided for spurious e-mails where I had to decide which e-mail to delete from a case and then decide where to insert that into a related case, this would be a great improvement. If delete and insert are not possible, then how about the ability to mark an e-mail in a case as not relevant and hidden. For such e-mails, they could also be excluded from searches. As it is currently, spurious data persists under wrong case numbers and only serves to create confusion rather than clarity. |
|||
|
|
|
0
|
I'd like to add yet another voice in the chaos advocating for merging. As a developer I understand the potential for problems here with the history and such (DVCS has relaly raised the expectations for how people expect merging to work), but an over-engineered solution isn't required here. From a UX perspective:
These two additions are very straightforward from both a UX and a database point of view (no-need to re-architect anything, specify six parents for cases, etc) and may even be implementable with a plugin. This will solve 99% of my use case. |
|||
|
|
|
0
|
We could use merging too. Happy customer so far, mannually merging the issues is a real bummer. |
|||
|
|
|
0
|
We really need to be able to make a case with one entry (like an incoming email) move over into an existing case. All the problems with this basically don't matter as long as we can move the mail over to the correct case. This is really important!!! |
|||
|
|
|
0
|
We'd like this as well and not just for emails but a general merge for cases. New cases are often submitted via email with dozens of people CCed in. Each response to all from the CC group then spawns a new case. This gets boring very quickly and makes the case difficult to manage. These emails are coming from customers who have no access to fogbugz and may not even be familiar with our product, so treating it as an end-user education problem isn't a workable solution. From this thread it doesn't look like we are the only one facing this problem. It would also be nice to have an auto-merge feature that makes suggestions based on the email subject line which may only be missing the (Case:xxxx). |
|||
|
|
|
0
|
Another request here for Fogbugz to having a merge-inbox-case-into-existing-case function - I went looking for it today , quite suprised that it was not there and found this thread. Please consider it, FogCreek! |
|||
|
|
|
0
|
+1 for Merging - everyone else sees a compelling reason for it.. why not listen. And this Stackexchange thread is not the first time this has come up - it was also on the old fogbugz forum. |
|||
|
|
|
0
|
I am sure that if FC dont want to implement it someone could implement it using their API (although they dont currently support inserting HTML into case events). Seems a shame though that we would have to work out a hack to get an otherwise market leading product to do something that seems quite simple. |
|||
|
|
|
0
|
I'm really ashamed that this isn't a standard basic feature of FogBugz. It is incredible a company is thinking that an automatism on something so random can work by itself. FogCreek you should add it as the next feature instead of concentrating in redesigning the product UI |
|||
|
|
|
0
|
Agree with Jamie Hunter and others that a far better solution to the problem rather than allowing the symptoms to be more easily addressed is Please upvote the case above rather than this one. |
|||
|
0
|
I was so desparate to reduce emailed duplicates that I have added an Outlook script to the fogbugz mailbox that strips RE: and FW:. In my environment this has reduced the problem of duplicates created by replying to emails without the case number to zero. The downside is I need to keep the Outlook profile open all the time which means finding a spare machine for it. So, a really simple short term fix that would really help everyone is for the email code in FogBugz to strip RE: and FW: (and any other locale-specific versions that could be entered by the user in the web.config). How about that as a very quick major improvement FogBugz Development Team? You could do it in a few minutes for the next release. Go on! You know we are all about to dump FB because of this issue. |
|||||
|
