Culmination of Permissions Ruminations

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Culmination of Permissions Ruminations
« on June 2nd, 2013, 06:02 PM »
So this has been bugging me, and given the intimation of just dropping everything we have and building something from scratch - which I'm not afraid of doing - so I spent time thinking about what we have, what we don't have, what everyone else is doing and why they are doing it.

This is a mighty post. For each section, there is the tl:dr; version for you. It's marked in bold.



First up, post count permissions... actually no, let's start with post counts as a whole.

SMF/Wedge is in the minority in actually assigning physical groups to post counts, and even more so in actually being able to hand out permissions for the same. In most of the forum systems, you can't even set permissions by post count directly, some not even indirectly. (Some of the forum systems allow for a promotion system, so that users get bumped into a new group when they go above a certain number of posts and permissions are granted on that new group, but it's not intrinsically a post count group if that makes sense)

In other words in most systems, post counts are pretty much a display matter rather than an organisational one. This certainly seems consistent with most forums I've seen, and it's even consistent with how most people use SMF; permissions for post counts are disabled by default, and most people only seem to need to turn it on to do things like moderation of the first few posts - of course, that's no longer an issue for us since moderation isn't a 'permission' any more.

tl:dr; do we actually *need* or *want* post count permissions? It seems like it has served to confuse people more than it has helped them.



Even if we do keep post count permissions, I'm also inclined to suggest a change to the way it is handled. Right now it is handled by virtue of a physical group attached to the user's account - primarily for being easy to get their post group's group data, but we don't need that so much any more.

In fact, the whole concept of primary group and secondary groups doesn't actually make any sense any more. Previously it used to be that the primary group was for showing a badge but since we ditched that concept some time ago to allow for any badges to be displayed, perhaps it's time to ditch the primary group/secondary groups concept and just have 'groups'. I'd probably even take the opportunity to move user->group association into its own table. This would solve some issues in terms of limitations (systems with crazy numbers of groups have had problems with exceeding the size of the varchar field), and for lookups from groups->users, it'd get faster, while performance of user->groups should be largely unaffected.

Post counts would receive a similar setup, though I'd drop the post count entirely from the user's account, and apply them at the point where the user's account/data is loaded. (I'd have a subcache of groups->posts, so I just have to use that). There would be a tiny performance hit on loading that information, but it would also save 1-2 queries for every post.[1]

Assuming we do keep post count permissions and so on, this has another interesting side twist. We can easily then do hierarchical groupings. Right now if you have the classical groups, they are 0, 50, 100, 250, 500. What that means is 0-49, 50-99, 100-249, 250-499. 500+. They're explicitly exclusive to each other.

What I'm getting at is that we'd be able to make it truly 0+, 50+, 100+, 250+, 500+ - so someone in that topmost group implicitly would be in all the lesser groups too. You could display all their badges if you wanted.

Depending on we do with permissions, this may or may not be an issue - one thing that always bugged me in SMF is that if you wanted to assign a permission by post count, you'd have to do it to each group over and above the one you wanted. But I'm thinking I wouldn't do it that way either. I'd actually just assign a post minimum/maximum count for each permission that was post count related and do it that way.

There is also a fringe benefit that if people somehow manage to remove the 0 post count group, it won't suddenly fuck everything up like it will in SMF every time.

tl:dr; The idea of primary/secondary groups is obsolete, I want to move them to a separate table, and I have funky ideas about changing post count groups including their permissions if we still want them.

Also tl:dr; I would explicitly add *everyone* to 'Regular Members' if they are logged in. This seems more logical to me that the current situation which is a by-product of the primary/secondary group antics.



Permissions themselves are complicated. It's also not like I can just repurpose SimpleDesk here either.

For those wondering what I did with SimpleDesk, I did several very strange things - in hindsight - that worked modestly well. Firstly, groups didn't have any permissions whatsoever. You created roles, e.g. a staff role or a user role, attached one or more groups to it, attached it to one or more departments.

I had sm.org in mind when I designed it. You have one group who is 'users' (Charter Members) and you declare all the permissions that users need to have, like posting tickets. You have multiple groups who are staff (the various team groups), and you declare - once - all the permissions that staff need to have like replying to tickets, seeing everyone's tickets, etc. and then attach it to all those multiple groups.

Conceptually for the main part of the permissions, that'd work quite well and as I posted originally about it in http://www.simpledesk.net/community/index.php?topic=709.0 it worked well for '1.1' when we didn't have this whole multi-department thing going on. But in 2.0 it actually didn't work all that well once I'd bastardised department (board) support into it... in essence, what ended up happening was not how I originally envisaged it but I forget why.

If you had multiple departments with common groups and rights and stuff it wasn't a problem. You define the user role, the staff role and just attach it to all departments. Worked quite well. But if you had two departments with no common groups, it sort of fell flat.

You'd have Dept A, with User Role A and Staff Role A, pulling from groups A1 and A2 with Dept B/Users B/Staff B/groups B1 & B2. It got ugly fast.

Fortunately, I don't think that's so much of a problem. There are three principle levels of management in a forum: administrator, global moderator (aka super moderator) and board moderator, as well as the regular members. These translate quite well to roles, actually.

The problem with the concept is not getting users to understand the group->role->permission setup. It is the interface for managing roles to boards/departments/whatever you call them and for the cases where you want things like moderators only in one board and whatnot and to give them powers for it.

The problem, ultimately, is that you get a difficulty curve that is exponential compared to complexity; simple setups are simple, complex setups get extremely complex to setup. This seems to me to be related to the way the different systems actually seem to intentionally try to simplify things - IPB et al don't have deny permissions. It's just not an option. Which makes me wonder whether it just requires more careful allow setup rather than using deny.

I'm resigned to the fact that any permission system is going to generate questions on how to configure it, but I think I can make something that will make sense to people, but still doing the setup of groups->roles.

tl:dr; I want to move away from this groups->permissions setup to groups->roles->permissions. Other forum systems use it and it works for them. I see no reason it shouldn't work for us and should be more sensible for most users.



Admin permissions have always been a problem. Too many admins give out full admin permissions then ask how to remove them afterwards. IPB in particular takes the opposite approach: the only permission granted by the admin group is to be able to go to the ACP homepage. But unless you have other permissions on top of that - which, I might add, are user specific (not even group specific) - you just get a 'no permission' page.

I wonder if we should approach things in much the same way for Wedge, that admins don't have power because they're in the admin group but because they have select powers over and above because of who they are. That would generally require more specific admin level permissions than we currently have, but that would make it easier to manage in the long run, I think. It would certainly limit the folks who add people to the admin group who suddenly worry about being removed again (because the notion of 'if you don't trust them, don't make them admins' is too exotic for these people)

Note that if we do this, admins don't magically get the same power they currently have, they would pretty much explicitly have to lose 'admins have every power'. Alternatively we approach it as a series of deny permissions so that the admin group does have full powers except for the powers you don't want them to have. Or even just give them all regular powers and then make adminly powers granted rather than explicit. It's complicated and I'm open to discussion on the idea.

tl:dr; We could reformulate admin powers to be less overarching and more granular. This has consequences for management too.



phew. Imma go play a game now and let this sink in with everyone and see what people think.
 1. Which has impacts especially for MyISAM tables.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

spoogs

  • Posts: 417
Re: Culmination of Permissions Ruminations
« Reply #1, on June 2nd, 2013, 07:35 PM »
Quote
tl:dr; do we actually *need* or *want* post count permissions? It seems like it has served to confuse people more than it has helped them.
*Need* I would say no but many people seem to *want* them. For me having rules to post counts is more beneficial, such that @ x number of post cannot or can now do this action. An example: Board is accessible but a users in Membergroup 1, User A has 60 posts User B has 1300 I'm more likely to allow user B to lock/unlock their own topics or say mark other users topics solved or unsolved (you get my drift) or whatever.
Quote
tl:dr; The idea of primary/secondary groups is obsolete, I want to move them to a separate table, and I have funky ideas about changing post count groups including their permissions if we still want them.
I'm curious to see what anyone else has to say as far as keeping posy count permissions but as I eluded to above I think I'd be happier with a rule based system for post counts.
Quote
Also tl:dr; I would explicitly add *everyone* to 'Regular Members' if they are logged in. This seems more logical to me that the current situation which is a by-product of the primary/secondary group antics.
Makes sense to me.
Quote
tl:dr; I want to move away from this groups->permissions setup to groups->roles->permissions. Other forum systems use it and it works for them. I see no reason it shouldn't work for us and should be more sensible for most users.
I'd be quite fine with whicher direction things go here, I'm quite comfy with how things were done in SD as far as roles and so on.
Quote
tl:dr; We could reformulate admin powers to be less overarching and more granular. This has consequences for management too.
This is something I have taken to task a few times. Odd as it may sound to some people, I personally do NOT like the admin knows all sees all does all approach. I do not get to hide too many things from myself, for example there are boards I do not want to see because the subject matter is of no importance to me, I only made the board because enough users asked for it. I would just rather be the admin as far as getting things up and running and maintaining the site then add myself to add myself to the necessary groups to enjoy the forum from a user perspective. To achieve this in SMF I had to praise the Subaccounts mod which allowed me to post and interact as a normal user and just check into my admin account to ensure that things are as they should be, and post any news/announcements I deemed necessary to be voiced by admin.

Stick a fork in it SMF

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #2, on June 2nd, 2013, 07:57 PM »
Without getting into it too much, the admin sees all approach does have some repercussions beyond the technical: admins are, by definition, liable for content. What I would suggest for that is to be able to not just ignore boards but hide them too if they do not interest you.

spoogs

  • Posts: 417
Re: Culmination of Permissions Ruminations
« Reply #3, on June 2nd, 2013, 08:14 PM »
I get the liability part of it. I do however find it extremely hard to believe that every admin reads every topic to ensure all posts are according to the agreement. We all depend on our moderating staff to help out as much as possible and even then things can go missed, we allow users to report other users, and not everything always gets reported, which is why I generally do not mind being able to NOT see everything all the time as far as the board index goes.

In the admin panel there is a list of all the boards, so 1 could easily (well after jumping through a small hoop) access any board anyway. I was just thinking as far as the board index goes do not display the board to admin unless admin is checked to be able to view that board (something of the sort if it doesn't get too complicated)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #4, on June 2nd, 2013, 08:47 PM »
The thing about the board index is that admins have explicit rules to override everything - and there is so much more than board visibility that is tied into it. Recent posts, unread posts, reported posts in those boards etc.

I still reckon improving the ignore feature to also allow users to selectively hide boards would be better in that regard ;)

I get the feeling, though, that some of this stuff I'll just have to go do it and see what happens.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Culmination of Permissions Ruminations
« Reply #5, on June 2nd, 2013, 11:31 PM »
I have thoughts however busy today so might have to wait till late or tomorrow. I will say I like the idea of moving to a groups -> roles -> permissions. Not only does it work as a good base for a forum it will be useful for general content management and could be used to re-tweak media.
Thank you,
Boko

xrunner

  • Posts: 192
Re: Culmination of Permissions Ruminations
« Reply #6, on June 4th, 2013, 01:35 AM »
Quote from Arantor on June 2nd, 2013, 06:02 PM
... and most people only seem to need to turn it on to do things like moderation of the first few posts - of course, that's no longer an issue for us since moderation isn't a 'permission' any more.
All I would add is an affirmative to that. All I've ever used them for is to control new users; for example to not allow them to send PMs or something else. So it was more of a "new user control" than an overall need to do different things to different post count groups.

MultiformeIngegno

  • Posts: 1,337
Re: Culmination of Permissions Ruminations
« Reply #7, on June 4th, 2013, 02:43 AM »
Quote from Arantor on June 2nd, 2013, 06:02 PM
tl:dr; do we actually *need* or *want* post count permissions? It seems like it has served to confuse people more than it has helped them.
I'm ok for not having physical groups.. but I think it's needed the ability to have some badges or specific permissions when users reach X posts (was thinking about stackoverflow).
Quote from Arantor on June 2nd, 2013, 06:02 PM
tl:dr; The idea of primary/secondary groups is obsolete, I want to move them to a separate table, and I have funky ideas about changing post count groups including their permissions if we still want them.

Also tl:dr; I would explicitly add *everyone* to 'Regular Members' if they are logged in. This seems more logical to me that the current situation which is a by-product of the primary/secondary group antics.
Absolutely fine with ditching primary/secondary groups. Always confused me
Quote from Arantor on June 2nd, 2013, 06:02 PM
tl:dr; I want to move away from this groups->permissions setup to groups->roles->permissions. Other forum systems use it and it works for them. I see no reason it shouldn't work for us and should be more sensible for most users.
Don't know on this. I leave comments to others on this :)
Quote from Arantor on June 2nd, 2013, 06:02 PM
tl:dr; We could reformulate admin powers to be less overarching and more granular. This has consequences for management too.
I think the solution that makes more sense is: when creating other admins, the first admin has a screen with deny permissions. By default they have all permissions, but before creating them the "first" admin removes specific permissions.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #8, on June 4th, 2013, 02:50 AM »
Thing is, physical groups is actually the sanest way to handle post count badges. The difference is they're just not attached as if they were real groups. Sort of virtual physical groups. Or physical virtual groups.

Other software doesn't even do the virtual group business, half the time there's not even the option for distinct badges per group, but simply 'number of pips for this level of posts' and a new title if you're lucky.

For me it's a tough one to balance flexibility with ease of setup.

The whole primary/secondary thing made sense in SMF when primary dictated what badge you would see in the boards (except when you're a local moderator but that's another shitfest entirely). It's also handled as such in the DB, but since it's not something we use (multiple badges, yo) it's a legacy concept.

As far as creating other admins goes, it gets messy because you have to do something with the inherent notion of 'admins have every permission' which would have to essentially go (or be reformulated) to support admin permissions being handled this way.

MultiformeIngegno

  • Posts: 1,337
Re: Culmination of Permissions Ruminations
« Reply #9, on June 4th, 2013, 02:54 AM »
Quote from Arantor on June 4th, 2013, 02:50 AM
As far as creating other admins goes, it gets messy because you have to do something with the inherent notion of 'admins have every permission' which would have to essentially go (or be reformulated) to support admin permissions being handled this way.
I think that one user (super admin?) having more powers than all others (even other admins) is needed. Also to prevent a "night of the long knives" thing..

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #10, on June 4th, 2013, 02:55 AM »
Until that user wants to hand over the keys to the kingdom on retiring or whatever ;)

There are an awful lot of edge cases that need to be thought through on that stuff, and I might just leave it that part along for now.

MultiformeIngegno

  • Posts: 1,337

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Culmination of Permissions Ruminations
« Reply #13, on June 4th, 2013, 06:06 AM »
The lovely thing with roles is you could ship with the normal user/moderator/admin (or if Arantor doe the CMS user/contributor/moderator/admin) and then those who deem it needed could add any other number of levels.  Maybe have user/staff(think low lever moderators)/Supervisors(Think normal moderator)/Manager(Think admin light)/Owner/Admin. Yes I know kind of doable with groups and perms however roles ads a level of flexibility that can't be beat and witht he right UI may be even easier to use.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #14, on June 4th, 2013, 06:08 AM »
Quote from Godboko on June 4th, 2013, 06:06 AM
The lovely thing with roles is you could ship with the normal user/moderator/admin (or when Arantor doe the CMS user/contributor/moderator/admin) and then those who deem it needed could add any other number of levels.  Maybe have user/staff(think low lever moderators)/Supervisors(Think normal moderator)/Manager(Think admin light)/Owner/Admin. Yes I know kind of doable with groups and perms however roles ads a level of flexibility that can't be beat and witht he right UI may be even easier to use.
FTFY. There's no IF about it. It's only a matter of time and figuring out all the stuff that is needed.