FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Case Descriptions

This has been said many times before it looks like, but I wanted to throw my 2 cents in:

Not being able to edit case descriptions completely ruins what would be an otherwise great product.  Especially when it comes to using it like an agile planning tool, which is what I was hoping to do.

I understand the need to store history - every bug system I've used forever has stored history.  But there are smoother ways to do this.  I suggest you take a "wikipedia" approach and store diffs with history so that someone can go back and easily see what was originally entered two months ago.

Its one thing for it to be annoying for spelling or formatting errors, its another thing entirely when you are trying to do case testing.  If a QA / Test person has to read through an entire history and try to figure out what the heck they are supposed to test, and whether the case passes / fails, you are going to have a high amount of recidivism.  I don't understand how anyone can actually use this system for testing... it must be being done, but it seems to me like it would create massive communication failures in a dynamic environment.

OR, you'd need to make sure that everytime someone updates the item that they write "These are the REAL requirements" and restate the entire case again.

I'd love to hear how people are getting around this limitation - but until FB changes how they handle the cases, I'm sad to say I need to pick a different tool.
Dave Sanders
Wednesday, December 12, 2007
I hate to say it, but I agree completely on this one. After 3-4 edits, the page just looks jumbled and cluttered.

It would be much nicer to have the ability to simply edit the description of a case instead of 'adding a note' to the case (as it is currently).
Ryan Scott Send private email
Wednesday, December 12, 2007
Me too. The previous system I used had:

Description - intended to be visible to client

Notes - internal, not visible to client

Both these were editable.

Comment.  Appended chronological, only editable by Admin.  Also included a "To:" which allowed a UserID to be included, so that they could be targeted.  (Particularly where multiple people might be associated with an issue.)

I commented in an earlier thread:

Quote: Its probably complicating things, but you could add a "workflow" step to require a Description to be Vetted whenever a new Comment is added.  That way it would be "known" whether a Description was potentially out of date, or current.
Krispy Send private email
Wednesday, December 12, 2007
+1 for editing events + keeping change history ( )
Andrew Davies Send private email
Thursday, December 13, 2007
Just wanted to chime in from Fog Creek and say that we're paying attention and listening here.  We've got a feature request open for both the case description idea and the revision history of cases, and we're adding notes to each case as we hear from our customers.  Those notes will be reviewed when we start examining new features for the next release of FogBugz.
Eric Nehrlich Send private email
Friday, December 14, 2007
So I've been having a parallel discussion with someone in Help about the need for editable cases, some parent case records, etc.

In this post Eric indicates that this is being considered for the next version.  The person I'm talking to has never indicated that, and has never seem to provide support for the idea. 

Am I supposed to be happy with an otherwise very strong case tracking system that sports this glaring deficiency?
Doug Coates Send private email
Wednesday, December 19, 2007
I very much want to be able to edit my comments on a case and the original case text as well.

This same problem has been a "bug" for Trac for a while too, and there's a lot of hot and bothered users there as well. At least with Trac you can edit the original case text.

I think  'edit case comment' and 'edit original case text' could be an assignable right, or just an on-off switch in the site settings.

If a site wants to allow case editing, and you don't want to worry about tracking edit history for case comments right now, then just adding a configuration option to enable or disable it would be a good start.

You could support case editing w/o audit trail in a point release, and save the fancy stuff for "the next version".

brad clements Send private email
Monday, January 7, 2008
>> You could support case editing w/o audit trail in a point release, and save the fancy stuff for "the next version".

Good idea.

I'd hate to NOT have auditing, but given the option I would much prefer to get my descriptions and comments cleaned up.

That said, a simple database trigger could stuff any changed Comment record into an audit table, and that could become display-able in the next release. (i.e. stuff the BEFORE data  into the Audit table when a record is changed/deleted;  the CURRENT data is in the DB anyway!)
Krispy Send private email
Tuesday, January 8, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.