Question

I have a scenario where I would like users to be able to submit a case, but only be able to edit it to respond to the engineering team. For example, I don't want some users to be able to file a feature request directly to an engineer, but I would like them to be able to communicate details about the feature request. Here's the workflow I'm envisioning:

1. Maggie from Marketing requests a change to the website.
2. The project manager for the website approves the change and assigns the case to an engineer.
3. Once an engineer completes the work, he assigns the case back to Maggie to request feedback.
4. If more work needs to be done, Maggie assigns the case back to the engineer.
5. Once work is complete, the case is ready for production.

How can I achieve this type of Workflow in FogBugz?

Answer 1

While this particular workflow comes up from time to time, it runs a bit against the grain of how FogBugz was designed. FogBugz was designed to trust the user, so if a user can submit cases, FogBugz trusts that user to edit the case as well. That being said, there are ways to emulate the requested workflow using FogBugz.

To start, I would recommend reading Setting up access for clients/non-developers in FogBugz to understand different types of users. See FogBugz Groups and Permissions to understand Permissions. If you want to automate part of your workflow, see Options to change and customize FogBugz.

Set up two related projects with different permissions

The first option we're going to look at will use Normal Users. You're going to want to set up two projects with different permissions. Here's an example, assuming you have a Website project:

• Project: Website
  • This is the default engineering project for the Website. Allow all website engineers to modify this project but only allow other users read-only access to this project. This allows engineers to work on cases but other users to see what's going on.
• Project: Website (Requests)
  • This project is used to receive requests for the Website. All engineers and other users are able to modify cases in this project. This is where cases get submitted and are reviewed.

Using the above projects, here's what a workflow might look like:

1. Maggie from Marketing opens a new case in the Website (Requests) project for a change on the website.
2. The product manager approves the change and assigns the case to an engineer, changing the project in FogBugz to Website.
3. The engineer finishes the work. He changes the project to Website (Requests), resolves the case as implemented, and assigns the case to Maggie for review.
4. If Maggie requests additional work, the engineer will pull the case back into the Website project (step 2) and iterate until work is approved.
5. Once Maggie approves the case, the case can be marked in whatever way is appropriate (changing the status, tagging, etc.) to identify that it is ready for production.

In the above workflow, the Project Manager would need to set up a filter to be able to identify cases in Website (Requests) that need to be triaged

Use Community Users to Submit Cases

Since Community Users can't change any of the details about a case and can only view email replies, they can be a good option when you want a Submit-only type of workflow. You only need one project in this case, Website, where engineers can modify cases and community users can submit cases. Here's an example workflow:

1. Maggie from Marketing logs in as a community user and submits a request to the Website project.
2. Project Manager approves the case and assigns it to an engineer.
3. Engineer finishes the work. Since he can't assign the case to Maggie because she's a community user, he "Replies" the case from within FogBugz.
4. Maggies simply replies to her email to either approve the case or request additional work.
5. When work is completed, the case can be marked in whatever way is appropriate (changing the status, tagging, etc.) to identify that it is ready for production.

In the above workflow, you're probably going to want to have all cases for the mailbox manually sorted into a "requests" area. At step 3, when the engineer responds to Maggie, he'll probably want to get the case out of his filter. The simplest way would be to have him simply "Send & Close" when replying to Maggie. The Project Manager would then need a filter to look for closed email replies in that project to make sure completed work doesn't fall through the cracks.

Other Options

In both of the above examples, filtering and searching are your best friend because they give you an insight into cases at various stages in the workflow. See also Searching In FogBugz: Syntax and the search axis.

Another method is to use one of the options above and spawn new cases for the actual engineering work. This is what we prefer at Fog Creek. You can easily link the cases together simply by typing e.g. see case 123 while editing a case.