Summarizing Redmine's permission system
As we'll be extending Redmine's access control layer with our own custom permissions, our first course of action should be to better understand this system.
Redmine doesn't apply permissions directly to users; instead, it encapsulates permissions within roles. These roles in turn can have one to many users associated with them and are used to control access to content areas within projects, modules, and plugins.
The following screenshot shows the Administration | Roles and permissions view where new roles can be created, or existing roles can be modified:
Each role contains a subset of the available permissions, which are further grouped by project module, which can be toggled on or off. The following screenshot shows the Manager role that is available as a default in Redmine along with the available Project Permissions all toggled:
As Redmine is a project-oriented system, a project association must be made in order for the role to be applied. This is...
