Question

Hi,

I need to have a defect tracking system that is under very strict control. I need several new statuses (found how to add them using the plugin). Some examples are CodeComplete, ReadyToBuild and BuildAssigned.

I need to apply permissions such that only certain groups of users (e.g. Roles as in "Developer", "Dev Lead" or "Build Master") are allowed to move the case from one state to the next. For example, only Dev Leads are allowed to move a case from CodeComplete to ReadyToBuild and only a Build Master is allowed to move from ReadyToBuild to BuildAssigned.

1) Is this possible to do? 2) If so, is there a wiki page or other doc that explains how?

TIA! john

Answer 1

You could write a plugin to enforce your desired workflow.

Update: Be careful with workflow, however. The actual custom workflows are a core FogBugz feature. The Workflow plugin merely provides an interface to change them, and helps with some of the execution. If you want to write a plugin which will counter-act workflow rules, feel free to contact us for help with understanding the FogBugz code.

The plugin api doesn't allow you to prevent a case edit to be commited, but it can check whatever conditions you want when an edit is committed, then display an error / warning to the user and perform it's own edit to undo the change.

For example, in the IPluginBugCommit interface, you would implement the BugCommitBefore method. You would check the CBug object passed in and look at the changes and the user who made them. If the user wasn't authorized, you could then commit your own change to the CBug to correct it.

Plugin docs are here, and full class libraries are here. If you need any help with plugin development, please email us.

Answer 2

No, FogBugz cannot do what you are looking for.

The FogBugz permission model only provides restrictions for each project, wiki and discussion group. You can control permissions by individual user, but not per-category, per-status, etc.

It is important to remember that FogBugz is primarily intended for use by what I would term peers, each of whom has the ability to do anything any other user can do. The ability to move a case from one state to another for a given workflow is not restricted in any way for any member of the project's underlying group with read/modify permission.

In my experience, the fact that FogBugz presents an audit trail indicating which user did what to a given case, restricting the ability to perform certain actions is a management issue rather than a technological one, and should be treated as such. Users who find themselves unable to play by the rules can be called to order as required.

Answer 3

A few more related questions:

1) Is it possible for us to write a plug-in to enforce our workflow? 2) Is a possible solution to: a) have the Status field as Active/Resolved only b) to have a new "State" field that the plugin could check permissions against?