A forum for technical support discussion related to Fogbugz.
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.
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.
+1 for editing events + keeping change history ( http://our.fogbugz.com/default.asp?fogbugz.4.21217 )
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.
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?
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".
>> You could support case editing w/o audit trail in a point release, and save the fancy stuff for "the next version".
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!)
This topic is archived. No further replies will be accepted.Other recent topics