When we began planning IP.Board 3, the global search system was one of the first features that we decided would be essential. We've already talked about the global search, now we're going to tell you about the permissions system that makes the global search and other features possible.
In previous versions of IP.Board, every application had to maintain it's own permission tables and database information. This created many different permission systems that all had to be separately maintained. When you added a new permission set, you would have to go to the forums section, the gallery section, the calendar, and so on to set up permissions. This system has quickly grown cumbersome to use from a user standpoint, and difficult to integrate with from a developer stand point.
IP.Board 3 will introduce a new global permission system that every application can use, including modifications. Rather than maintaining separate permissions, all permissions are now stored in a permission index table. This table is generic enough to be used by any application. Each application will include a simple configuration class that will tell IP.Board how to use the permission index for that particular application. The system currently supports a 'view' permission and 6 'custom' permissions, the custom permissions are defined by the configuration class for each application. The view permissions is what we use for permission checking during a global search, or any other feature that uses the search index.
Currently the permission configuration looks something like this:
private $mapping = array( 'view' => 'perm_view', 'read' => 'perm_2', 'reply' => 'perm_3', 'start' => 'perm_4', 'upload' => 'perm_5', 'download' => 'perm_6' ); private $perm_names = array( 'view' => 'Show Forum', 'read' => 'Read Topics', 'reply' => 'Reply Topics', 'start' => 'Start Topics', 'upload' => 'Upload', 'download' => 'Download', );
All your application will need to do is edit these values and IP.Board will know how to handle permissions for your application. If you wanted to check the reply permission, you would simply do this:
$this->registry->class_permissions->check( 'reply', $perm_row );
In the Admin CP, if you want to show a permission editor, all you need is this:
$permissions->adminPermMatrix( 'type_of_permission', $perm_row);
This will return the full HTML for a permission editing matrix, to save that matrix you would do this:
$permissions->savePermMatrix( $this->request['perms'], $perm_type_id, 'type_of_permission' );
In that example, if you were editing a forum, then the perm_type_id would be the id of that forum.
We hope that this system is going to make integration much easier for mod authors, as well saving them from having to develop their own systems for managing permissions. We will be providing documentation and example code for this system via the resources site later in development.
While developers will receive most of the benefits from this new system, it does allow for an important user level feature as well, the ability to manage all permissions from one screen. Now when you edit or add a permission set, you will see Forums, Gallery, Downloads, and any modification that uses the system all on one screen. This saves you from having to jump all over the system to edit permissions for any one set, which we think is going to be a great time saver.
This new permission system is a very important step in one of our primary goals, integrating all applications as closely as possible. In our next blog post we're going to tell you about even more of the integration features you can expect from IP.Board 3!