User roles and permissions

Roles and Permissions

L2Board uses a Role-Based Access Control (RBAC) system for its authentication and authorization system. This provides enough granularity and flexibility for most situations, though may not be suitable for every website.

Stock Roles

L2Board ships with 4 roles by default. They are Administrator, Developer, Moderator, and User. Each of these roles has some basic access provided, though you will need to ensure that they all have the appropriate permissions for your site. While their names assume certain capabilities within the site, they can all be changed as needed, though we do highly suggest that Administrator remains unchanged.

Administrator

The Administrator is the highest level user of the site. This is often the client that you are creating the site for. This is the ‘owner’ of the site and, as such, is typically given the most power of the site operators. By default, L2Board provides this role with permissions over the entire site.

Developer

While the Administrator is the owner of the site, there are still some tools that L2Board provides that they will never need, like the Module install, Translation tools, etc. The Developer role was created to keep the dangerous tools away from the other users of the site, while still providing powerful tools for the development and maintenance process.

User

This is the player default role that anyone registering to the site is given. As such, it will typically have very limited rights to most of the site.

Creating New Roles

New roles are easily created within the admin panel by navigating to Settings / Roles and then selecting New Role in the navigation bar. The elements of the form are:

Role Name - The name of the role as you want it to appear to users. It should be one word, with no spaces, though you can use underscores in their place. Description - This field is primarily used on the Roles overview page, but can be used by yourself throughout your template when needed. Login Destination - This is the relative path that a user is directed to when they login. For example, you can force all admins to be directed to the main admin page by setting this value to /admin. Alternatively, you could have Users be directed to their own dashboard or account management page by entering the appropriate relative URL here. Default Admin Context - When a user logs into the admin area, this allows you to set the context they are directed to, like /admin/content The Settings and Developer contexts are unavailable for selection here. Default Role - The role assigned to new users when they register at the site. By selecting it here, it will be removed from any other role that currently has it. Removable? - Allows you to provide access to roles other than the Admistrator, while not giving them the power to delete certain roles, keeping them safe from accidents or malicious actions. If this is set to ‘Yes’, then anyone with the L2Board.Roles.Delete permission can delete this role.

When you first create a role, no permissions will be shown. You can go back and edit the permissions available to the role by selecting the Role from the Role overview page, or by editing through the Permission Matrix.

Permissions in L2Board

Permissions in L2Board are modeled after the excellent and easily-understandable permission naming system in Vanilla Forums. Permissions are described in 3-part, human-readable formats that allow for nearly any type of permission to be created. This allows both the admin screens and your code to maintain a high degree of readability.

Creating Permissions

New permissions can easily be created through the Admin UI by navigating to Settings / Permissions. This screen will provide a list of all existing permissions as well as the option to create new ones.

Each permission has the following three properties…

Name is the permission itself, following the naming scheme outlined above.

Description is a short string describing the permission and it’s use. This is only used for display in the Permissions overview page.

Status allows permissions to still be available in the system, but not to actually be used. This can be used as a placeholder for in-development features.