Setting up and understanding permissions in The Bug Genie  ⇑ top

How are permissions defined?  ⇑ top

Permissions are defined on a 4-level basis, in the following order:

1. Global permissions - applies to all users, groups and teams
2. Group-specific permissions - applies only to members in that usergroup
3. Team-specific permissions - applies to any member of that team, and you can be a member of multiple teams
4. User-specific permissions - applies to the user it's specified for
Each new level in the above list overrides the previous one. That means if you've set "Report issues" to "Allowed" for "Everyone" and "Denied" for the "Guest group", then the group permission will override the global permission for all users in the guest group. In addition to this, The Bug Genie has a "Permissive" or "Restrictive" security setting which means if you trust all your users you can set this setting to "Permissive" and everyone will be able to do pretty much anything unless specifically denied. The only exception here is access to the configuration pages, where you must have explicit "Allowed" access. This gives you fine-grained control over what users, groups and teams can do.



Permissions hierarchy  ⇑ top

Many settings are grouped, and most specific settings (ex: "Can set issue priority") are only available as sub-permissions of more general groups. An example is the "Can edit basic information on your own issues" permission. This has three sub-settings, "Can edit title", "Can edit descrition" and "Can edit reproductions steps". Using "Everyone" as an example, if you set the top setting to "Allowed", everyone can edit basic information (title, description and reproduction steps) for issues they create. If you want to modify this, say you only want them to change the title, then you can do this two ways:
5. Set "Can edit description" and "Can edit reproduction steps" to "Denied". They will still have the basic "Can edit basic information (...)" setting, which means the title is editable, but the "Denied" settings for editing description and reproduction steps has higher priority, which means they will not be editable.
6. Unset the "Can edit basic information (...)" permission, and only set "Can edit title" to "Allowed".
This grouping is used several places, and is indicated by a little list icon next to the permission icon in the permissions overview. Clicking the list icon brings up all permissions in that group and lets you specify a more fine-grained permission in the group if desired.



Project-specific permissions  ⇑ top

Adding to all this, many permissions can be set on a project-specific basis. You might want to only let people report issues for a certain project, or restrict people from doing something on a specific project. The "Project-specific permissions"-tab in the permissions overview lets you define this. The same rules apply as above, but if a project-specific permission is set, then it will take presedence over the global permission.



Page access permissions  ⇑ top

You can limit access to certain pages if you want to restrict users from accessing them. Some of these settings are available as both global and project-specific settings - such as the project-specific pages. This setting is "Permissive" by default and cannot be changed.



Datatype permissions  ⇑ top

Every datatype (status, priority, category, etc) also have their own permissions available for each defined value. This setting is permissive by default (and cannot be changed), but lets you control who can set which field to a certain value. Even if you set a datatype field permission to "Denied" the user will still be able to see the field value, but they cannot set it to that value if the permission is "Denied". This can be useful in a workflow setting where you only want certain users to be able to mark issues as "Fixed", "Closed", etc. These permissions are also available for all custom datatypes.



Nice to know about the permissions handling  ⇑ top

7. There is one important exception in effect when you're reporting an issue: If a field is set to "Required" in the reporting process, then the user will have access to this field, even if it set in the permissions manager that they are not allowed to change it. This is to stop the reporting wizard from failing if you're missing access to a required field. They still need access to a field value to set it, so if all field values are set to "Denied" then they won't have any options to choose from. They will also not be able to change it after the issue has been reported if they don't have access to do so.
8. If a user has read or write access to any of the configuration pages, they will automatically see the "Configure" link in the menu. If they don't have access to any configuration page, this link will be hidden.
9. The permissions setting dialog will always show if a setting is permissive or restrictive by default, by showing a faded out "Denied" or faded out "Allowed" icon.