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

Feature request: default assignee when resolving cases

The current workflow of FogBugz where it assigns a case back to the originator when it's resolved doesn't always seem appropriate to me. I can see that for customer support incidents but for bugs in a product development context, every process I've seen would always send next to a QA lead for testing.

I would very much like to see the ability to specify a user per project that is the default assignee for cases marked resolved. Right now, when I see a bug come back to my inbox because it's marked resolved, I have to go through the motions of assigning it over to someone else. After doing this enough times, I start to think that taking care of this grunt work for me is what computers are good for. ;-)
Dave Burns Send private email
Thursday, December 1, 2005
Yes, there does seem to be a need for a "ready for test" stage in the workflow.  The simplest solution is to train your developers to not resolve the case but assign it to QA.
Denis Howe Send private email
Thursday, December 1, 2005
This is the same issue that we have found trying to incorporate the testing cycle into fogbugz. Most of our cases will be coming from e-mail to a generic mailbox that auto-sorts them. This makes all the new cases to be created by the Administrator and therefore reassigned to the administrator when they are resolved.

Is there anyway fogbugz could take into account the workflow steps that an organization like ours has?

More specifically, are Case goes through the following steps:

1. Unreviewed
2. Development
3. Testing
4. Verified
5. Testing (Post-deploy)
6. Production

We would love it to be able to specify the movement of a Case from one step to the next and the step contain an auto-assign person that could be set. (ie. If mark for Testing our Q/A Lead for that project would automatically get assigned the task.)

Thanks for the consideration.
Richard Adleta Send private email
Thursday, December 1, 2005
>>The simplest solution is to train your developers to not resolve the case but assign it to QA.

True, but it becomes extremely problematic to distinguish cases which need work from cases which are being worked on from cases which are ready-to-test from cases which are ready-to-ship when the status of all of them is "active" and you rely on whether the case is assigned to Bob, Joe, or Dave to determine what its status really is.

In a workflow environment, there really are more than two states for a case (active or resolved).  The "Resolve" action implies a resolution which may not be true when the case is simply moving through other states of the workflow. But "Resolve" is the only way to change the status even when you've edited the Status table in the database to include the various workflow states.
Steve Troxell Send private email
Thursday, December 1, 2005
I fully second this feature request. We have only been trying out the system for a week or so now, and already I am spending a lot of time assigning cases en-masse to QA, as often the cases have arisen outside of QA.

Given that Joel himself heavily evangelises on the benefits of a test team I am surprised that the Fogbugz process doesn't support such an obvious step in the flow.

I love the product in general and am keen to use it, but I am finding during our eval that I am spending time defending it from several complaints, all of which appear trivial to address.

Having a default assignee for Resolved cases for a project would be a great improvement.
Mike Llewellyn Send private email
Friday, December 2, 2005
We would also like to see this, since our product manager wants to stay in the loop for all Feature cases on the roadmap, so he can track the overall progress on his Excel timeline.
Thomas Stache Send private email
Monday, December 5, 2005

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.