RSS Feed

FogBugz Technical Support

I am evaluating FogBugz4, and I like it very much. However, there is one feature that FogBugz does not appear to have, and it is a showstopper for me: an editable description field.

I want to use FogBugz to submit, edit, and plan out a set of features for a product. After a feature is submitted, it is natural to want to edit its title and description until it is acceptable for implementation. But there is no way to edit the existing Description text; one can just add to it.

There are two ways to implement this, and both would be quite acceptable. One is to have a description field that is distinct from the comment/history field that is used today. The other way is to allow editing of any posted text.

A custom Description field would be fine, as long as it could be a large, multi-line text field. Is this possible using v4?

This is not supported in the current release. Thanks for the thoughtful feedback. It's always useful to hear what features our users want to see added. I’m passing your comments on to the development lead for consideration for future releases.

To be clear: the lack of an editable, multi-line Description field means that I cannot use your product, nor can I recommend it to others. This is a real shame, since I am deeply impressed with FogBugz and was looking forward to rolling it asap.

Adding a Description field would probably take one of your engineers several hours to do, and it would be incredibly valuable. If you are philophically opposed to a Description field, then you could make it an option, either at install time or runtime.

I doubt I am the only one who absolutely needs this capability. Please consider adding it to your very next rev.

Thanks for listening.

I agree - having an editable description field that would always appear at the top of the history would be a very useful feature. Then there is only one place where a person needs to go to find out the latest on what needs to be done. This does not take the place of the history field - both are necessary.

Add my vote for this as well.

I think I'd vote against this.

I've used bug systems to track work (I do that today), and being able to back-edit the history is generally a bad idea. You may find that the old history is actually more useful than you think, weeks or months later. Your condensed view of the issue has a lot of associated context, some of which was gleaned from the old history.

I think there's a difference between an edtiable description field and an editable history. A description field is just an extension of "title" with a bit more wiggle room. The history stays the history. The value of editing the description is when the description describes work details and through the history and discussion it is determined that some of those details are incorrect or have been changed.

Now, without an editable description, the developer implementing the work starts with incorrect details and must scan through the history to determine the correct details. The QA person checking the implementation starts with incorrect details and must scan through the history to determine the correct details. The closer starts with incorrect details and must scan through the history to determine the correct details.

Moreover, no one can ever assume that the description is accurate for ANY case, since it can't be edited. Everyone must ALWAYS scan EVERY case history to see if there are changes to the original uneditable work description.

A nice way to do this would be to have an editable description field, an save every old description field version in the database. In the reports, there would be an option to view the description history.

In the reports, first would come the editable Description. Then the old descriptions (normally hidden). Then the narrative (Opened by, Assigned To, etc).

This get's my vote too. But I wouldn't call it an description, I'd prefer "Current Status" or "Status Whiteboard" as in Bugzilla.

The major difference from an ordinary history entry would be the fixed position near the top of the page.

Background: We often deal with "Review Feedback"-type cases, which resemble a bulleted list of up to 10-15 items. It turns into a major annoyance to track the remaining issues. The status field could read "(1), (3), (9) left open".