Wedge

I can see the arguments both ways, though. I'm not entirely convinced it is for the best at this stage :/That's not exactly setting a high bar, though, is it?See, that's where it gets complicated as a bunch of that stuff is also admin discretion (e.g custom fields). I can see the argument of that but it's complicated. I would imagine it is difficult to configure for admins and for users, to a point.It's already at admin discretion, own vs any. Doing more than that is very complex but if we bolt a bunch more stuff in it, it would be a valid and major consideration.I dunno. There is more stuff in the profile than just the profile; there is access to a user's contributions, the warning system - you'd have to essentially override user choice for anyone who has any kind of moderation power.

Been busy today and I need to just check they haven't cancelled the account since I got an email saying 'we couldn't find a website'

I guess I need to install that to understand how it works... screenshots would have been nice :P

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.

Actually it's *always* done that, even going back to Dannii's version before vbgamer took it over. And it's always done so for a reason: SEO (and legitimately so)

If you use the username, you're pretty much guaranteed to have a permalink since only admins[1] can change usernames of users, while almost anyone can change display names at will.

Now, that's a separate issue we may or may not have to deal with so much because if profiles aren't visible to users, the link gets stripped anyway - so if profile links aren't visible to guests, there's no SEO impact (because there's no permalinks that have to be maintained for search engines)... SMF even with Pretty URLs does not do this, the link is still there regardless.

Now, as far as solving the problem goes, seems to me that we probably need to keep a log of changes of display names (beyond the profile edit log) that we can refer to in the event of a PURL calling a name that isn't the user's current name. That gets messy if two users previously had the same display name (though we can prevent that, I guess)

I dunno. It's a complex issue that can't just be solved with a simple change.

1.	It may be admin only, it may be people with manage-members but you get the idea.

Oh, I wouldn't be surprised. Some of the things I've learned from staring at the code and thinking 'wut?'...

With WC, I wouldn't be surprised if you're being literal in terms of it changing with the season, or sarcastic. It's on at least the fourth theme I've seen on it.

I have lost count of the number of people that equate 'good with computers' with 'good with A/V equipment' for example. Competence is a curse because it dooms you to appearing competent in any vaguely related field and thus the de-facto go-to person for support.