Permissions

FogBugz allows you to set up permissions, restricting users to areas they're allowed to access. Rather than setting each user's permission individually, FogBugz uses groups. For example:

1. Bob and Alice are in the "Mail Department" group
2. The Mail Department has two projects: Shipping and Handling
3. Therefore, FogBugz concludes that Bob and Alice can access both Shipping and Handling.

Now, when you add new users or projects to the group, all the permissions are granted automatically. And when someone leaves a group, they automatically lose permissions to all of that group's projects.

Setting Up Permissions

Before setting up permissions, ensure that FogBugz is configured to require passwords (Admin | Site | Authentication | Log on Method). Next, determine how you will group your users as described in Groups.

Projects

Access to cases is controlled at the project level. Every project is assigned one (and only one) group which determines which normal users can see and edit cases. Non-logged-in users and community users can never see and edit cases. Site administrators can see and edit all cases.

To setup project permissions:

1. Create groups.
2. Edit each group, giving each user appropriate access levels (see below).
3. Edit each project under Admin | Projects, assigning it to the appropriate group.

Note: If you want to allow a user only to submit cases and view the current status of their own cases, you don't need to give them a FogBugz account. Have them send email to a FogBugz mailbox, or set a project to allow public submissions.

Wikis and discussion groups

Wikis and discussion groups can be open to all FogBugz users or be assigned a group to set which users can read and write them. Groups can contain community users, meaning you can open up a wiki or discussion group to select external users without having to let anyone with the URL see it. For more details, see Managing a community wiki.

If a wiki is not assigned a group (and is therefore editable by all normal and administrator users), you can specify whether all registered community users can read and write, and whether anonymous visitors can read and write.

To setup wiki or discussion group permissions by type of user:

1. To give access to community users, first make sure the feature is turned on in Admin | Site | Authentication.
2. Edit the wiki or discussion group under Wiki | Customize or Discuss | Customize.
3. Set Internal users to "All users..."
4. Under External users, set whether registered community users can read and edit
5. Under External users, set whether anonymous users can read and edit

To control which individual users can view and edit a wiki or discussion group:

1. If any of the users are community users, make sure the feature is turned on in Admin | Site | Authentication.
2. Create a group if necessary.
3. Edit the group, giving each user appropriate access levels (see below)
4. Edit the wiki or discussion group under Wiki | Customize or Discuss | Customize
5. Under Internal users choose the appropriate group.

Editing groups

When you are editing a group in FogBugz, you can set permissions for normal users and external community users.

Normal Users

You have three choices for normal users under Permissions.

Note: The site administrators' permissions cannot be set, because they always have access to all parts of FogBugz.

1. You can give everyone access (default).
2. You can give everyone read access to the group, and customize who has modify access to edit cases.
3. You can customize access on a per-user basis, deciding individually what each user can do:
1. None
2. Read only
3. Modify
4. Group administrator (see Administrators, below).

If you choose option #1 or #2 for any group, you will not be able to completely, hermetically isolate groups of users from each other, because they can meet each other in that group. (See Isolating users from one another, below.)

Community Users

FogBugz allows you to set which individual community users can read and write your wikis and discussion groups.

To do so, click Add Community Users to Group.

In the resulting dialog, you can check the boxes next to the users you would like to add. If you have a large number of users, type the name or email in the first box to filter the list. You can also add all users from a given domain by using the * wildcard in the second box. When you click OK, you can then set read and write access for each.

Assigning Projects, Wikis, and Discussion Groups to Clients or Departments

Projects are always associated with a group. To configure it, choose Admin | Projects, edit the project, and select the group from the dropdown. If there are community users in the group, they will not have access to cases in the project. Only normal and administrator user types can see and edit cases.

Wikis can be associated with a group, or they can be open to everyone. Choose Wiki | Customize, configure the wiki, and choose the permissions level you want:

Note: Wikis also can allow access to Community Users. See Managing a community wiki for more details.

Discussion groups can be associated with a group, or they can be open to everyone. Choose Discuss | Customize, configure the discussion group, and choose the permissions level you want:

Note: Discussion groups can also allow access to Community Users.

Administrators

There are three types of administrators: Site-wide, Group and Project, wiki or discussion group-level administrators. Site administrators are a special type of FogBugz user designated in Admin | Users. They have full control over all areas of FogBugz. The remaining types are set in their respective areas, described below. When editing a wiki, discussion group or project, you will see a list of all users with administrative privileges over it (under Admins), including ones set there, ones determines by the assigned group, and site-level administrators. The example below of a discussion group shows one of each type:

Groups

Group Administrators can't edit FogBugz site configuration settings, but they do have full control over projects, wikis, and discussion groups which are set to their group, including the ability to:

• create, edit, and delete projects, wikis, and discussion groups
• create, edit, and delete areas
• create, edit, and delete milestones
• modify wiki templates
• modify discussion group layouts
• modify group settings
• create, edit, and delete administrators within their projects, wikis, and discussion groups

To modify group administrators, edit the group, and check the appropriate box next to each user's name.

Projects

Project Administrators can't create or delete projects, but they do have full control over their own projects, including the ability to:

• create, edit, and delete areas
• create, edit, and delete milestones
• modify project settings

To modify project administrators, edit the project, and click Edit Project Admins.

Wikis

Wiki administrators can't create or delete wikis, but they do have full control over their own wikis, including the ability to:

• create, edit, and delete templates
• modify wiki settings

To modify wiki administrators, configure the wiki, and click Edit Wiki Admins.

Discussion groups

Discussion Group Administrators can't create or delete discussion groups, but they do have full control over their own discussion groups, including the ability to:

• moderate discussions (deleting and undeleting posts)
• see the email address and IP address of a poster
• modify discussion group settings
• modify discussion group layouts

To modify discussion group administrators, configure the discussion group, and click Edit Discussion Group Admins.

Read more about Discussion group moderator features.

Isolating users from one another

In various parts of the FogBugz user interface, you can see a list of users in a dropdown list. FogBugz will only show each user the names of people who have some project in common.

For example, Alice and Bob will not see each other's names in any dropdown lists with the following group setup:

• Development group: Alice has read privileges, Bob has none.
• Administration group: Bob has read privileges, Alice has none.

If you also set up a Common group and allow anyone to access it, suddenly Alice and Bob will see each others' names in the user interface.

If you need to isolate users from one another, for example, if you have multiple clients you do not want users from one to see those in another, you can't set up any groups that are open to everyone.