A forum for technical support discussion related to Fogbugz.
They reopen them on a different topic....
Issue: Users use the email system such that cases are messed up with muck.
A case related to issue 1 is emailed in by a user, is fixed, user is notified, case is closed.
Then two months later, the user emails in with that case # in the subject, asking a completely unrelated question. This is now a problem because:
a) A closed case has been reopened... which is a mess.
b) We have no control over this. Any user can reopen any case... (heck, could even guess at a case number!)
c) I cannot remove this users new, unrelated question from the case. It is there forever.
d) I cannot easily push this new unrelated question into a new case (I can do it, of course, but it takes some clicking around).
Thar's the issue, mate!
Monday, December 25, 2006
Sam: could you tell me about how often this has been happening to you so I can suggest a good fix?
Tuesday, December 26, 2006
I have had exactly the same type of thing arise from time to time. I wouldn't call it frequent. But it is one of the reasons why I really want some kind of "merge cases" feature to more-or-less peel off the most recent entry of a case into a new case (or perhaps append it to another existing case if a target case number is provided).
Basically remove the BugEvent entry from the original case and add it to another case, creating a new one if necessary. With a bit of automatic cleanup (i.e., log a BugEvent something like "entry moved to case 1234"; if the original case was closed before the new entry came in, close it again with the same resolved status--restore it's previous state).
Yeah, this is definitely an issue with FogBugz. We experience the same thing here in FogBugz tech support. We just do the copy-and-paste workaround, but it would be nice to make it a one-button action in both directions (taking an incoming email that created a new case and attach it to an existing case, and taking an email that was attached to an existing case and splitting it off into a new case). All I can tell you is that it's on the wishlist, and I'll continue to push for it.
How often it happens... Look, enough that it is messing up our system. FB is great because it allows the public to easily feed issues into the dev group.
But this great ness starts to be mitigated when the cleanliness of our case data (both case status and case contents) are getting mucked up.
Frankly, this issue is one of those things that can make FB a liability rather than an asset:
a) Cases are getting mucked up
b) FB has no tool to clean up the muck, and I don't have time to fiddle with the FB DB. So with time, the muck increases.
c) As our FB data quality declines, FB is less and less able to perform its core function for our team.
When you get down to it, this is a category one problem. The entire FB mission is compromised by this issue.
Steps to resolve (as seen from my chair):
1) When we close a case internally, it is closed. Joe user with the FB email address should not be able to reopen it.
2) If such an email was sent in, it should create a new case, linked to the original case.
3) I, as the FB user, should be able to MERGE those two cases, IF I want to.
4) In general, I should be able to 'peel' a bugitem off a case into a new case (as mentioned by Mr. Troxell above). This feature relates both to this issue and to FB generally.
That is it!
I am with Sam. It's annoying when a user reopen old case. I think sam's solution is the best. Do not allow user to re-open case, but automatically create new case if they reply to a closed case. Admin like us should be able to decide if we want to merge with the old case or let it be as a new case.
On the other hand, if it is a new update to a closed case, reopening the case is the correct action. I think that is still the best default action.
An alternative would be an option which would make the last update a new case, and close the current case.
Tuesday, January 2, 2007
I'm on the fence as to which "direction" of this feature is the best default behavior.
I'll often Send & Close when making a final response to an inquiry because, as far as I am concerned, the inquiry was answered and I'm not expecting the need for any follow-up. My job is done UNLESS the customer has additional comments/questions. But what happens is I'll get a "thank you" reply which reopens the case. I don't need a new case for those. Or sometimes the answer stirs an unexpected follow-up question in the mind of the customer, and a reply re-opens the case. Whether that creates a new case may or may not be important.
So overall, I still lean towards the "email to a closed case should open a new case" behavior, but I recognize scenarios where that might not always be desired.
Under the proposal that email into a closed case creates a new case, that "thank you" scenario wouldn't be a big deal if there was also a streamlined way to delete cases (even if that's just a one-click transfer to a Trash project). I could just delete that new case as unnecessary trash.
Whether email into a closed case reopens the case (current behavior) or creates a new case (proposed behavior), I think it's apparent that either way, some kind of "peel off the last BugEvent and move it to a new/existing case" feature is necessary to let the FogBugz user easily alter whatever the default action is. Central to this is convenience in cleaning-up whatever undesired effects (opening cases which should be closed) occur in the case when the default action is not the desired one.
Proposal for this feature: after removal of the case's most recent BugEvent:
1. Add an "edit" to the original case which documents the transfer of a new email "from (sender email address) on (date)" to the target case number,
2. If the previous most recent event was a "close" event, or if the moved BugEvent was the opening event, then silently close the case. Any other conditions, do nothing more with the original case...leave it as-is (except for the act of moving the BugEvent of course).
3. Leave the FogBug user in the target case ready to operate on it.
If silently closing the case is uncomfortable, then here's an alternative: On the "Transfer" screen, or whatever this is called...coming up with a name for this could be, um, interesting...the user supposedly has an option to specify an existing case number to transfer to, or let it create a new case. Just add a checkbox there that asks "Close this case after transfer?" That lets the user control the closing behavior if they so choose. You could even use the above logic to define the default checked/unchecked state of this control.
If a clean way to delete cases ever becomes a feature, then "Delete this case after transfer?" could be an additional choice here...if the transfered BugEvent was the opening event for the case.
Finally, as for whether the default action for a new email to a closed case should be "create a new case" or "reopen the closed case", one solution is a site configuration option:
Emails to a closed case should (*) reopen the case or ( ) create a new case.
Food for thought.
Thanks for all of the great suggestions in this thread - I've included a link to the thread in our internal FogBugz case so that the developers can read your ideas.
I think the default should be settable. Here at Fog Creek, our default is to send-and-close whenever we respond to a customer support email so that it isn't in the Inbox any more. However, we want incoming emails to be added to the same case so that the email thread is preserved. So our default sounds like it would be different than other people in this thread.
This topic is archived. No further replies will be accepted.Other recent topics