Managing FogBugz Permissions

Plugin developers can use the FogBugz permissions framework to make sure that only a desired subset of plugin users can view and manipulate FogBugz data.

For more information on Permissions in the Plugin API, see FogBugz Permissions in Plugins.

FogBugz Site Permission Levels

FogBugz users are assigned an overall site permission level, described by the enumeration FogCreek.FogBugz.PermissionLevel. The permission level enumerations, in order of increasing site access:

0-Public Users have not logged into the FogBugz site. They can:

Create an "inquiry" case within a project that has been configured to "allow public submissions"
Read/edit a wiki configured to grant read/edit rights to "anonymous users"
Read/edit a discussion group configured to grant read/edit rights to "anonymous users"

1-Community Users are authenticated users with a free license granting them partial access to FogBugz functionality. They can:

Read/edit a wiki configured to grant read/edit rights to community users
Read/edit a discussion group configured to grant read/edit rights to community users

2-Normal Users are authenticated users with a paid license granting them complete access to all FogBugz functionality (subject to ACL permissions, see next section). They can:

Create and edit FogBugz cases (subject to ACL permissions)
Read/Edit a wiki configured to only grant access to internal users (subject to ACL permissions)
Read/Edit a discussion group configured to only grant access to internal users (subject to ACL permissions)

3-Site Administrators have access to all FogBugz site configuration and all site content. This means they can:

Create, modify, and delete FogBugz projects, wikis, and discussion groups
Grant public and community users access to wikis and discussion groups
Configure ACL permissions for projects, wikis, and discussion groups

ACL ("Access Control List") Permissions

The FogBugz functionality available to normal users can be be considered to be split into "sections" (individual projects, groups, discussion groups, mailboxes, and wikis) each of which can be configured to grant or deny access to a particular set of normal FogBugz users. For example, a single project is considered a section, as is an individual discussion group.

In the FogBugz database, each section is considered to have its own "access control list" (ACL) which specifes a level of permission for each FogBugz user using the following enumeration:

0-None: The user cannot see any data relating to the section, and thus has no indication that it exists.
1-Read Only: The user can only view data regarding the section and section contents.
2-Read/Write: The user can view and modify data regarding the section and section contents.
3-Admin: The user can configure section permissions and other important settings.

Why Permissions are Important for FogBugz Plugins

Most plugins will require some attention to FogBugz permissions because:

Plugins displaying data from a FogBugz object need to make sure that the current user has permissions to view that information FogBugz enforces the permissions of the current user by default, so if a different type of user logs in, your plugin may crash with a FogBugzSecurityException. See Entity Member Security for more information.

Plugins modifying data in a FogBugz object need to make sure that the current user has permissions to modify that object. Similarly to above, if the current user does not have permission a FogBugzSecurityException is thrown, which may crash your plugin if it is not expected. See Entity Member Security for more information.

Site navigation (menu options and links) generated by a plugin should not be available to public and community users if the plugin requires the current user to have a site permission level of "Normal" or above.

Plugin configuration should be left to site administrators. Your plugin configuration page (generated by the IPluginConfigPageDisplay interface, and usually linked to via an admin menu option courtesy of the IPluginAdminMenu) can only viewed by administrators. Any links to the plugin configuration page should only be displayed if the current user is a site admin.

Virtual Users

FogBugz "Virtual Users" don't log into the site, they simply allow users to assign a case to abstract entity such as "Up for Grabs" or "Backlog" instead of an actual person. Thus, plugins don't have to worry if the current user is virtual (it should never happen), but they can check if any user is virtual by seeing if FogCreek.FogBugz.CPerson.fVirtual returns true.

Wiki