Translating phpBB2 permissions to SMF

[packman]

I started to look at how to translate phpBB2 permissions into SMF, but gave up when I realised I didn't understand either phpBB permissions or SMF permissions well enough.

I've now tried to document how phpBB works, so see if anyone can help with a translation into SMF-speak. At this point I'd like to try to explore the permissions functionality as seen by a user, e.g. the administrator. Once I understand the translation, I can try to work out how this maps into the phpBB/SMF database tables/fields (which I'm sure will create hours of detailed fun!)

Here's how I understand phpBB permissions to work...

1) Each forum (SMF board) has a set of default permissions controlling which types of (non-group member) users can carry out which operations on the forum.

2) Forum operation permissions exist for: View, Read, Post, Reply, Edit, Delete, Create Sticky Message, Create Announcement, Create Poll, Vote.

3) Each Forum operation permission can be set to one of: All, Reg, Private, Mod, Admin. This defines the level of access required to do the operation.

4) Forum operation permissions can be set in Simple or Advanced mode. Simple mode is really just a pre-defined set of advanced mode permissions. For example, Simple mode 'Registered' equates to All, All, Reg, Reg, Reg, Reg, Mod, Mod, Reg, Reg (respectively for each operation listed above).

5) Groups (SMF additionalGroups) add to forum access control in two ways.

5.1) A group can be selected as Moderator/Not Moderator for each forum.

5.2) In addition if a forum has any 'Private' operation permissions set, the group can also control further levels of access (Simple/Advance mode).

5.2.1) In Simple mode, there is an Access Allowed/Disallowed option.

5.2.2) In Advanced mode, each forum operation permission that is set as 'Private' can be set on/off. So if 'Read' and 'Post' operations are set to 'Private', a Group can be set to allow (ON) reading and disallow (OFF) posting.

Translations
----------------

In (3) I think that the access levels equate to:

All = SMF Unregistered Guests
Reg = SMF Ungrouped Members
Mod = SMF Moderator
Admin = SMF Administrator.

I'm not sure yet how Private fits into this, but I think it means access is controlled by group membership.

Comments are welcomed on my description of the permissions and also any suggested translations between phpBB-speak and SMF-speak.

[[Unknown]]

View, Read = memberGroups on boards table. (all others in board_permissions...)
Post = post_new.
Reply = post_reply_any.
Edit = edit_own
Delete = delete_own and remote_own
Create Sticky Message = make sticky
Create Announcement = announce_topic. (RC2 only)
Create Poll = poll_post
Vote = poll_vote

All = every group in forum, including -1, 0, 2, 3, etc.
Reg = every group except -1, as above.
Private = not clear, I assume everything but -1 and 0.
Mod = 2,3
Admin = none at all, 1 always has access.

> A group can be selected as Moderator/Not Moderator for each forum.
Currently not an option, although it has been considered and may be again.  Currently, this would mean making all members of the group to moderators individually, or giving them permissions without listing them as moderators. (in other words, creating a special group for them and giving it moderation permissions...)

So, for private it's not all groups, it's those listed....

-[Unknown]

[Grudge]

I'll just chip in here that when I wrote the phpBB converter I tried *really really really* hard to do permissions. I managed it (roughly) on Invision and I spent several hours pondering phpBB. I just simply couldn't see how their permissions system translated to SMF in any comparable way, so didn't do it. I'm not saying it's not possible but just it's not easy to get your head round!

[packman]

I'm not saying it's not possible but just it's not easy to get your head round!

I know exactly what you mean. I keep on looking at it and then going to think about something simpler. I'm running out of simple things to do now though 

[packman]

I'm getting there. Phase 1 is done...the converter now translates the board level permissions. It takes a lot of switch statements and INSERTs onto the smf_board_permissions table, but the end result seems to be right 

Phase 2 is to do the same for group level permissions. I think this should be easier as I can re-use a lot of the board level permission code/mechanisms.

Phase 3 is to consider how to handle phpBB moderators.

Finally, if anyone has an unmodded phpBB forum, can you let me know if the phpbb_forums table has a column called auth_attachments in it? I thought my forum was unmodded, but my table includes this field. I can't see anything in the standard phpBB administration section that allows this field to be set/rest though. At the moment I'm ignoring ths field, unless someone can suggest how to handle it.

[packman]

> A group can be selected as Moderator/Not Moderator for each forum.
Currently not an option, although it has been considered and may be again.  Currently, this would mean making all members of the group to moderators individually, or giving them permissions without listing them as moderators. (in other words, creating a special group for them and giving it moderation permissions...)

There's a 'Moderate Board' permissions setting for a group/forum combination that adds 'moderate_board' to smf_board_permissions. Does this give the members of the group the same privileges as being named individually as a moderator, i.e. having an entry in smf_moderators?

[[Unknown]]

No, not exactly.  There are other permissions needed to moderate - if you look under ID_GROUP = 2 in the board_permissions table (by default) you should see them.

-[Unknown]

[packman]

No, not exactly.  There are other permissions needed to moderate - if you look under ID_GROUP = 2 in the board_permissions table (by default) you should see them.

-[Unknown]

Thanks for that. I've added the extra permissions to the code migrating group with auth_mod permissions. I'm in the process of testing the most recent batch of mods...

1) I've fixed a problem that didn't convert [SIZE=xx] where xx ended in 0
2) Fix the incorrect inversion of the hideEmail flag
3) Censored words list is now migrated
4) Disallowed usernames are now migrated
5) Banned users, emails and IP addresses are now migrated
6) Board level permissions are migrated (groups -1, 0, 2, and 3)
7) Group permissions are migrated (other non-post based groups)
Moderator permission given to groups with phpBB auth_mod permission

Got a few other mods to put in before I send you another copy. There isn't much more left to migrate now, so I'll have to give up soon 

[packman]

Permissions are proving to be tricky to get right 

I think that more of the phpBB permissions might translate into multiple SMF permissions, but I'm not sure which to use. Is there a list of the valid board_permissions anywhere and what they mean? For example, what is the difference between :

• edit_own and modify_own? edit_own was suggested as a replacement for auth_edit, but I now suspect that modify_own might be what's needed, or perhaps both are required?
• delete_own and remove_own which also sound similar

I could try to find out by trial and error, but that's going to be slow!

[Grudge]

Look in ManagePermissions.php, I think there is a rough list of what each of them do. I believe delete means "Delete topic" and remove means "remove post", in SMF speak (or vice versa)

[packman]

Thanks for the pointer. It does contain a number of lists of permissions, but I can't see anything obvious describing what the permissions mean. At least I've discovered that 'edit_own' doesn't exist as a permission which makes it obvious why my migrated users can't edit their own posts 

[[Unknown]]

Sorry, that was a typo.  It's modify_own.  And, remove_own is for posts, delete_own is for topics.

-[Unknown]

[packman]

I guessed it was a typo, but it was an easy problem to fix once I'd figured that out!

I've extracted what I think is a complete list of all the permissions from ManagePermissions.php. I'm now trying to work out which are board level permissions and which are site level and what the implications are of setting global/local board permissions for the board level permissions.

For example, pm_send and pm_read are site level permissions, i.e. they can't be set differently within SMF for each board. So I assume these are set in smf_board_permissions for the appropriate ID_GROUP with ID_BOARD = 0? If so, then I guess it doesn't matter if the user tries to use PM in a group with local permissions defined? This appears to be different for board level permissions, where if a group has the permission at site (ID_BOARD=0) level, then if they don't also have the permission in a board that has local permissions set then they lose the permission.

Does that question make sense?

I'm letting permissions sink in for a day or two before going back to look at them again. I'm working on migrating some of the site level parameters stored in phpbb_config/smf_settings. Is there any standard code available to make changes to Settings.php? Some parameters in phpbb_config are stored in there, e.g. site name, and I don't want to invent a text file update facility if there is already something available to be included.

[[Unknown]]

No, "site level" permissions are set in the prefix_permissions table.  This is because you can't be allowed to read your pms if you're on one board, but not another.

The prefix_board_permissions table is used ONLY for board specific permissions.  Permissions that don't logically apply by board are simply not stored there.

Remember that if use_local_permissions is 1, the global board permissions (ID_BOARD = 0) are not used.  They always lose permissions in board_permissions with ID_BOARD = 0 when use_local_permissions is 1.

There's one in Admin.php.

-[Unknown]

[packman]

Hey...who put smf_permissions in my DB? For some reason I'd never noticed it before    Now that I know it's there I'm more convinced I'm converting the permissions correctly.

Thanks for the pointer to Admin.php. The ModifySettings function in there looks like it's assuming userpic_width and userpic_height are in Settings.php. I think they're now maxWidth and maxHeight in smf_settings?

[[Unknown]]

Hmm, that's interesting.  Those are very very old from a very very old beta.

! Removed some unused settings - no visual difference. (Admin.php)

-[Unknown]

[packman]

I'm having problems with Unregistered Guests now. They can't view any of the boards, but I'm sure they used to be able to.

The conversion process effectively switches all boards to local permissions and then adds permissions for users who have an equivalent permission on phpBB. This seems to work OK for all groups apart from Guests. If I look at the permissions for one of my boards, Guests have 'Access', i.e. group -1 is listed in smf_boards.memberGroups, but no specific permissions for the board in smf_board_permissions.

I've also got 'Allow guests to browse the forum' ticked.

What do I need to do to let them read the posts in some/all boards?

[packman]

What do I need to do to let them read the posts in some/all boards?

* packman Can't count

I've worked it out. The values in smf_members.memberGroups have to be in ascending order, but for some strange reason I'd used '0, -1, 2'.

[packman]

I'm still checking that permissions are translating OK and I think they're pretty much there.

One thing that's amazed me is that I've ended up with loads of board_permission records...1488 of them to be precise. I think that's because SMF permissions work in a different way than other permission systems I've come across in the past. The biggest difference is that there are global and local permissions, but when used local permissions are used they completely override the global permissions.

For example, this means that if I want to have all unregistered users able to edit their own messages, I can set this at a global level. However, as soon as I want to give extra access to a couple of groups of admins who 'manage' different sections of the forum, I have to add a permission for unregistered users to edit their own messages in every affected board.  Multiply this up by the number of permissions users typically have and you see why there are so many records required.

I'm more used to permissions being additive/subtractive against a single global permission set, e.g. a global set of permissions are defined and you can then add or deny permissions for specific groups.

I don't want to rake over old ground, but I'm puzzled what the advantages are of doing permissions the SMF way does. I must admit that I've not really tried applying permissions from the UI, so perhaps all these masses of board_permissions being created is hidden in the background for most users and I've only really noticed because of what I'm doing with the converter.

[[Unknown]]

It complicates things, but part of the reason for it is that for a long time deny wasn't an option.

To avoid all the problems people are currently having with deny (it denies, it doesn't disallow...) it just wasn't an option.  In this system, you needed to be able to specify board-specific options that did not include the "global" set.

While now there is deny, this still has some use.  Again, deny is a "dangerous" thing to use for people who don't understand it, and everyone wants it to solve all their problems.  For example, if I go and deny Ungrouped Members from posting new topics in the News board... problem solved, right?

Well, no, not if I have someone who has additional groups which should allow him to post there.  But, if he's an ungrouped member... he's denied.  Period.  End of story.  This is incredibly useful for stopping people from posting attachments (as an example) but in this case, not at all what you want.

In that situation, having global and local permissions aggregate... is not helpful at all.  That represents an impossibility, unless they are kept separate.

A lot of people have argued that deny shouldn't affect things like it does.  I think these people don't understand deny.  They want some sort of complicated inheritance scheme, where post groups are the "least" affective, then additional, and then finally primary.  I'm sure that global would be "under" local.  This would mean that if you were allowed locally, but denied globally.. you would be allowed.  But this system also has its flaws; not only is it horribly complicated and arguably even worse to get a grip on, but it removes the intention of post groups, additional groups, and etc.  With it, you can't do any permissions based on the number of posts a person has, without using that for your only determining factor. (disallowing all "higher level" groups.)

And, it's not really like the rows are *that long* anyway.  Perhaps it is 1500, which seems like a lot (are you using moderators at all or just making them by group/board_permissions?) but it can do things that can't be done in other systems.

-[Unknown]

[packman]

I think I understand 

I don't think I have particularly complex permission requirements...I have two groups who 'moderate' two exclusive sets of boards, although all registered users can read/post to all the boards. The only way I can see of doing that is to set all of my boards to local and then give appropriate board permissions to each 'moderator' group...and finally give all the ungrouped users, Moderators and Global Mods the basic permissions they need to post, etc to the boards.

I think I concluded that making people moderators on boards didn't help, because you said they'd need the extra permissions given globally to Moderators (group 2). That meant adding board_permissions for the users who were moderators, which meant setting local permissions, which meant adding all the other board_permissions they'd need anyway and then giving the basic permissions to all the other groups!

I haven't come up with a better solution for you though. I can see how I can do what I need to do in a much easier way, but I'm lucky to have a well behaved set of users and have never needed anything like Deny 

[[Unknown]]

I think I understand 

I don't think I have particularly complex permission requirements...I have two groups who 'moderate' two exclusive sets of boards, although all registered users can read/post to all the boards. The only way I can see of doing that is to set all of my boards to local and then give appropriate board permissions to each 'moderator' group...and finally give all the ungrouped users, Moderators and Global Mods the basic permissions they need to post, etc to the boards.

I think I concluded that making people moderators on boards didn't help, because you said they'd need the extra permissions given globally to Moderators (group 2).

True, but that's like having the board local.  Meaning, if I'm in group 2 (a moderator) my permissiions ONLY apply locally to THE BOARD I MODERATE.  This means that if I am on the list of moderators for a board, I will only have moderation powers inside it and no others.  This can be done, however, without using any local permissions whatsoever, because it's using the global set of moderator (2) permissions.

That meant adding board_permissions for the users who were moderators, which meant setting local permissions, which meant adding all the other board_permissions they'd need anyway and then giving the basic permissions to all the other groups!

I haven't come up with a better solution for you though. I can see how I can do what I need to do in a much easier way, but I'm lucky to have a well behaved set of users and have never needed anything like Deny 

You can use disallow on those misbehaving ones.

-[Unknown]

[packman]

Ahhh...I understand how mods work now! I think the permission conversion process I've used is still valid, because it pretty much maps phpBB permission to SMF permission. Trying to work out whether a set of phpBB permissions add up to SMF moderator is too messy. The converter leaves the converted forum with the same effective permissions as it had before, which is what's really needed and keeps the code relatively simple. I suspect that with some human intervention I'll be able to simplify the permissions (using moderator permissions) once I've converted my forum.