Jump to content
Josh
 Share


IP.Board 3: Global Permissions

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!

 Share

Comments

Recommended Comments

They map to columns in the database table, the table has perm_view, perm_2, perm_3, perm_4, perm_5, perm_6, and perm_7, so that's where the limit comes in. It would be trivial to add another column of course, but we think that 7 permissions should cover almost all cases.

Link to comment
Share on other sites

[quote name='Alεx' date='Aug 19 2008, 10:40 PM']Sounds good :) Just a query, is there a reason for a limit of 7, I don't think I'd exceed 7, but just wondering :)

Yes, I also have this question.

Link to comment
Share on other sites

[quote name='Trialgan' date='Aug 19 2008, 11:08 AM']If there's a 'view' permission and 7 custom permissions, then do you mean perm_view, perm_1, perm_2, etc. ? Just wanted to clarify :)

It should be 'view' permission + 6 custom permissions, that was a typo on my part, will fix that :)

Link to comment
Share on other sites

Sweet! :D This was one of the most painful parts of development we had when we did Ineo.

Question though, how are you guys handling the cascading permissions for forums using this? Do you just get the permissions for each of the forums above the one you're trying to check, and handle the cascade there, or does this system help you in some way?

Link to comment
Share on other sites

A few concerns:

I'm hoping you guys remember not to hard code language bits in the code like "Show Forum" and use the language system. Not only that, but it would be good to encourage that in the documentation.

Since the limit is primarily based on the number of columns, would it be possible to support for more if further columns were added? Many require SQL to be executed for their own data tables. One could make a query to extend this table... If there was a value in the configuration to extend it, then if a mod needed more it wouldn't have to modify important files. It's hard for me to foresee the need more more, but you never know.

I'm assuming that the system loads all the relevant setting data prior to the component being loaded? So when you do this:

$this->registry->class_permissions->check( 'read', $perm_row );

You're not running another query?

Link to comment
Share on other sites

Here's hoping that upgrading existing modifications will be painless. I'm cringing at the thought of what will need to be done to convert the old 2.3 style permissions into these new 3.0 style permissions.

Link to comment
Share on other sites

[quote name='Μichael' date='Aug 19 2008, 11:29 AM']Here's hoping that upgrading existing modifications will be painless. I'm cringing at the thought of what will need to be done to convert the old 2.3 style permissions into these new 3.0 style permissions.

To me it seems it would be easier this way. I guess it also depends on exactly how it is set up though. I usually use permissions in the way that a tutorial on your site show (the multi select) so it's an array of member group numbers. I haven't looked at this closely, so maybe this would be harder to change becuase it could mean coding changes in files too. :( Hopefully it ends up being easy though.

Link to comment
Share on other sites

[quote name='Mert' date='Aug 19 2008, 03:02 PM']I doubt 7 permission settings would be enough. How will you handle editting/deleting type of things? Are moderation type of things handled seperately?

We have the forum, blog, gallery, and download manager running on this system and haven't had need of any more than 7 permissions yet. If it did become necessary, you could just add another perm column and update your permission mapping file. As far as what it handles, it's pretty much the same as old: View forum, view topic, can reply, can moderate, can download, for forums. A lot of individual moderation permissions are part of the group settings.

Link to comment
Share on other sites

[quote name='Μichael' date='Aug 19 2008, 12:29 PM']Here's hoping that upgrading existing modifications will be painless. I'm cringing at the thought of what will need to be done to convert the old 2.3 style permissions into these new 3.0 style permissions.

We're going to be providing tutorials on updating your modifications, hopefully that will help out. It was relatively easy to update IPB and all of it's applications to use the new system, mostly involves a global search for the old permission function and then updating all occurrences. Depending on how your modification stores it's date, cached or not, you may need to add a join to your existing query so that the permission is row is included.

Link to comment
Share on other sites

Awesome, it'll definitely help streamline settings so each mod doesn't need to have its own screen for it :P
By the way, is this a typo or do I just have bad reading skills...?
, you would simply do this:, $perm_row );
Shouldn't 'read' be 'reply'? :P

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

$this->registry->class_permissions->check(

'read'

Link to comment
Share on other sites

[quote name='Master_Odin' date='Aug 20 2008, 02:39 PM']Awesome, it'll definitely help streamline settings so each mod doesn't need to have its own screen for it :P
By the way, is this a typo or do I just have bad reading skills...?

Shouldn't 'read' be 'reply'? :P

Another typo, fixed it :)

Link to comment
Share on other sites

I hope there will be a permission setting as to whether or not a member of a particular group can post links or can include links in their profile. This would help a lot in terms of dealing with new members that merely join up the forum to post spammy links. They are the biggest threat to a happy forum and I hope IPB3 will focus closely on stopping spammers at every turn!

Thanks again, :)

Link to comment
Share on other sites

[quote name='squidfish' date='Oct 22 2008, 11:50 PM']I hope there will be a permission setting as to whether or not a member of a particular group can post links or can include links in their profile. This would help a lot in terms of dealing with new members that merely join up the forum to post spammy links. They are the biggest threat to a happy forum and I hope IPB3 will focus closely on stopping spammers at every turn!

Thanks again, :)

You can control which groups can use each bbcode individually in IPB3. :) So this is possible, but not through the permission system (through the bbcode system instead).

Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...