Question

I understand the reasoning behind not wanting to allow users to alter-history by modifying old entries, but the most common reason for wanting the edit cases in my experience is the "ooops scenario" where I notice a typo immediately after I save a case and don't want my illiteracy memorialized for all time.

Would FogCreek be willing to consider a compromise where an entry could be edited with the following constraints?

• Fixed and short time window: Say 1 hour
• Only by the person who created the entry.
• Only the last entry on a case ever be edited
• Only the body of the case or attachments can be edited, not status/assignee/etc.

What do you think?

Perhaps the same logic could be applied to allow limited deletes, too.

Update: Just thought of another situation that makes this limited timeframe editing/deleting a good idea. Our help desk instance of FB has gotten cluttered over time with customers responding after a case is closed with a final "Thank you" e-mail. It would be nice to be able to delete those when they come in.

Case FC1838001

Answer 1

Case event editing is available as of FogBugz 7.3. There's no time constraint.

Here's a link to the FogBugz Case Event Edit plugin:

http://www.fogcreek.com/FogBugz/plugins/plugin.aspx?ixPlugin=36

Answer 2

Another idea, which I think I posted on the old board some time ago, is to shift the paradigm to a StackExchange type Wiki. The core issue would be treated like SE handles Questions, and the case updates would be handled like SE treats answers.

Both would be wiki-ized with a revision history to protect us from revisionists.

A hybrid of StackExchange and FogBugz would be really awesome particularly with regard to the wiki nature of entries and the voting capabilities.

Answer 3

One problem with this is that email notifications need to be sent out in a timely manner. You probably don't want your incorrect text to get sent out to everyone subscribed to the case, but you also don't want to wait an hour for people to get the notification. Even waiting 5 minutes can put a damper on the conversation and make you walk down the hall to talk to the person rather than putting the data in FogBugz.

Answer 4

It seems to me that this is laden with too many gotchas to implement in a standard way.

In our shop, we've just come to expect that this will happen. If its really problematic, like someone just plain posted to the wrong case or if its bad/mis-information;

We run our own local instance of FB so I usually...

Just connect to the database and fix it.

UPDATE   BugEvent
SET      ixCase = @NewCase
WHERE    ixBugEvent = @BugEvent

or

DELETE   BugEvent
WHERE    ixBugEvent = @BugEvent

You can get a list of Events from

SELECT   *
FROM     BugEvent
WHERE    ixCase = @CaseNum

Answer 5

One way to do it could be to replace the text in the last bug event, somehow highlight it as "modified" and still be able to see the original text before it was edited.

This should take care of those cases when you just want to fix a typo in the last message. Also if you received a notification with the original text of the message, when visiting the case in Fogbugz it would be clearly visible that the text was modified after the notification was sent.

Answer 6

Hello, I have a solution for that problem :

I added the plug-in "custom field" and I have created a custom field named "Description" with "type = long text" and put it Top (not left).

Then I can have the description of the case and edit it if I need and still keep the comments (that I sort by newest with is better in my case).

If I edit the description (I restrain myself to only change it for spelling mistake only), a new comment is added with Old and New version so I can even see the history of the modification :)