Site Management Forum permissions

[Arantor]

So I'm currently knee-deep in designing this stuff and I thought I'd take a little tour through the various systems I currently have to hand to see how they do it and see if there are things I want to include but also things I want to avoid.

I'm not generally interested in how granular or coarse the permissions are; for the most part they're fairly comparable. Basically in my head, 'can see a board', 'can enter a board', 'can create a topic', 'can reply to topic' are the fundamentals, and everything else is just fluff around how you apply that and its friends. It's interesting how different platforms take this concept differently.

It's also interesting how different platforms handle the notion of moderators, but we'll get into that.

For the sake of readability, I'll try to do one platform per post and go into detail, can figure out getting some kind of index in after the fact.

List:
> SMF 2.1
> Wedge 1.0
> Flarum
> miniBB
> CBACK
> Vesta Athens 1.0
> Codoforum
> XenForo 2.2
> Invision Community 4.6
> Woltlab Suite 5.4
> vBulletin 3.8
> vBulletin 4.2

 

[Arantor]

So first up, SMF.

The first thing to note about SMF is that the ability to see a board is the same as the ability to see the content inside that board - you can't enter a board you can't see. (Caveat: if you have a board that's not visible, and a sub-board of it that is, you can enter that because it's not 'not visible' to you, it's just not visible. Permissions are not hierarchical.)

Board access is very simple - either a group can see it or they can't. Note here that it is on/off, and on a per-board basis, but you can actually deny access to boards. You just have to go to another screen (Admin > Forum > Boards and Categories > Settings) and turn on deny permissions, at which point the list of tick-boxes becomes something a bit different.

So here we see the classic 'Allow', 'Disallow', 'Deny' triple - other platforms call this 'Yes', 'No', 'Never', but it's the same basic idea. I think people who come to SMF get hung-up on the terminology based on discussions I've had.

Disallow doesn't mean 'can't', it means 'can't unless allowed', while deny means 'can't ever'.

Next up, let's take a quick look at general permissions. These are for permissions that aren't board-specific.

This is an interesting screen to me, mostly because it's quite confusing.

What we're saying here is: these are the groups that can have permissions. (Post count based permissions don't get a look in here, you have to go to Admin > Members > Permissions > Settings to enable them)

The first problem with this screen are all the groups that have (?) icons by them, because they're immediately confusing, and this is absolutely one of the reasons people have trouble with SMF permissions.

Specifically: Regular Members, Administrators and Moderators are complicated. Regular Members in this context doesn't mean 'registered members', it means 'registered members' who have no defined *primary* member group. (You can have a primary membergroup, this is what will be used in the in-post profile, and you can have secondary groups. Regular Members are everyone who have no defined primary group, but will still be in any secondary groups you give them. Most people don't get why there is a distinction.)

Administrators are here despite the fact there's no real reason for them to be here: they have all permissions all the time - as it says. I'd be more sympathetic to the idea of spelling it out but it's not consistent; the board access listing doesn't show admins (because they always have access) but this does.

Moderators are also complicated because the moderator group isn't really a group. Well, it is but it's not an assignable group as such. Basically, the Moderator group is one that you get given if you are assigned as a board-level moderator through the board configuration (you get listed on the board index and everything), and it will be added to your groups... while you are in that board. Which means the listing here confusing because this is for 'general permissions' and initially that doesn't parse because... general permissions generally are for outside boards.

What it's actually doing is saying 'this is the list of general permissions around the forum PLUS the default profile for permissions that we expect most boards to use'. In fairness this is sort of explained actually in the permissions page itself but before we get to that I just want to touch on the bottom part of the page first.

The second problem with this screen are the three options at the bottom. First glance you wouldn't realise they're three separate options that are completely independent from each other, or indeed how they work.

The first option is 'for the groups you have ticked above, apply a set default list of permissions'. Basically, wired into the code of SMF are pre-set lists of permissions under the headings of 'restrictive', 'standard', 'moderator', 'maintenance'. I don't think it's *ever* explained anywhere what the permissions under those headings are and you have to go into the code itself to check. I also don't think anyone ever used this intentionally.

The second option is 'for the groups you have ticked above, copy the permissions from this group to all of those groups'. Useful if you have a lot of groups whose existence is for display purposes (e.g. different badges for different things) and you want to align the permissions, but honestly... there are better ways to do that.

The third option is for 'for the groups you have ticked above, (add or remove) (single specific permission)'. I'm also fairly sure no-one's ever used this.

And if we actually go into the permissions for a group we see the following.

That's a lot of permissions.

The first thing that's interesting is that SMF separates out admin level permissions - there's no 'user is admin' permission in the conventional sense. (Internally there is. Membergroup 1 is special; you can give out all the permissions but you can't give out group 1 unless you're in group 1. And group 1 has magic rules around 'always has all permissions' and 'bans do not affect group 1', something not true for other groups.)

Here we also see the permissions attached to the 'default profile' in this case, the normal permissions in a normal board for Regular Members.

The idea of profiles makes sense - you can then keep your permissions consistent between boards. But SMF's setup is confusing.

So, it comes by default with 4 profiles: Default, No Polls, Reply Only, Read Only. The last three are minor variations, whereby no polls just is the same as the above but with the polls permissions removed; Reply Only is so admins can make new topics but users can't; Read Only is what it says.

BUT... the Default profile is editable, you can click on it in the list of profiles and go edit it for each group. The others are *not* editable, you can only look up what permissions are available in them for each group (which if you make your own groups or add add-ons with permissions renders this somewhat useless), and what you have to do is *copy* them to a new profile, edit *that* profile, then apply that profile in the boards you want to be different.

But wait, there's more. SMF also has post moderation. It's off in the above screen, but if you enable it, you get new permissions that show up, plus a whole new screen.

In the SMF world of post moderation, permissions have a sort of cascade effect. There is the standard permission for 'can create new topic' (plus new reply), but post moderation also adds a permission for 'can create new topic but requires approval' and 'can create new reply but requires approval'.

This is confusing because... the 'can create new topic' and 'can create new reply' permissions automatically override the '...but requires approval' permission. Which means if you ever want to set up post moderation, you're in for a game I once described thusly:

Let me explain the problem of doing this on a fresh SMF install, and you're welcome to join in at home. Today's challenge: configure it so that regular users don't have moderation but new users with up to and including 5 posts are moderated.

There are, in fact, two ways to do this, both of which are convoluted.

1. Turn on post moderation in Core Features.
2. Making sure that the 0-post count group is left alone, create a new post count group that requires 5 posts, so that once a user has successfully posted 5 posts (and until they're approved, it won't affect their post count), they can have different permissions attached.
3. Admin > Members > Permissions > Settings > Enable permissions for post count based groups (tick) > save

Here's where the paths diverge. Here's path A:
A4: On the same page as above (Admin > Members > Permissions > Settings) also enable Enable the option to deny permissions
A5: Go to Admin > Members > Permissions > Board Permissions and for each profile (that allows posting) set the permissions up as follows: Regular members should have "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval" enabled, while the 0-post count group should have those permissions *denied* and "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" in their place. Once the user leaves the 0-post count group for the 5-post count group, the other permissions are no longer denied.[3]

Or, path B. It doesn't require deny permissions but it does things another way.
B4: Go to Admin > Members > Permissions > Board Permissions. For Regular Members, set all the posting permissions to disallow. Then in the 0-post count group, give them "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" and for every other post count group, give them "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval".[4]

Either way, banal and frustrating (and in fact, you still have to do the same thing using the other interface but it's actually slightly *more* confusing, not less there).


Footnotes:
3. But now we have an extra membergroup that does absolutely nothing other than allow another group's permissions to expire.
4. This means you still have the extra group, but at least the extra group is now doing something. This is also very fractionally faster, but harder to maintain as you have to set the new permission up on any new post count group you create.

(This was in the 2.0 era; 2.1 doesn't have the Core Features page. Instead you go to Admin > Members > Permissions > Post moderation and turn it on.)

This is still a logical problem one has to wrap their head around.

And just to help you out, post moderation gets its own special permissions screen.

This does (somewhat) mitigate the concept of 'create' vs 'create but with approval' in that you can't accidentally set the same group to have create *and* create-but-approve permissions (in the way you can in the other UI), but it's not obvious that if a user has two groups, create without requiring approval supersedes.

Anyway. That's SMF's permissions. Comprehensive enough but convoluted how to do things is really my hot take on this.

 

[Arantor]

While we're on the subject, let's talk Wedge.

It's a direct descendant of SMF so it will have a lot of common DNA. It also has a lot of changes, so let's get into that. First we looked at board access.

First obvious thing, we have the Yes/No/Never terminology going on. I was quite insistent about this back in the day. I also made sure we had see/enter as separate concepts, and that denying access was logical and easy to do.

The default is to have see/enter be aligned, and that deny is off, but it's selectable per board - and it's *right there*. And if you don't need it on a board, you can toggle it and the UI updates there and then.

The main permissions UI will look fairly familiar.

The main permissions UI looks pretty similar. I don't remember why we didn't put Yes/No/Never here too because I was so insistent about it on the boards config.

Note that Deny here is enabled by default and can't be turned off. You'll also note that there's no permissions here for post moderation. That's because I did something pretty radical over there. But we'll get to that.

One thing I want to draw attention to here is something I never solved in Wedge and is still there in SMF: the concept of the 'moderate board' permission.

Conceptually this doesn't really make sense, but I've never quite known what to do with it. It doesn't grant any ability to moderate; if you want moderators to moderate and do things like move/delete/lock/etc. you have to give those out normally. Moderate board in this context does one thing, and one thing only: it lets you see the reported posts for that board. Everything else is driven by other permissions. Maybe this is as simple as 'See reported posts for this board' as a rename. Hmm.

Post moderation got a lot of love and attention, and I bring it up here because it's sort of a permission related item but Wedge went out of its way to not be permissions based about it. It is, instead, wizard based. Every single case I ever found for post moderation, it could always be phrased in a rule. So instead of defining it with a collection of tickboxes, I tried to create a way to phrase the rules out.

This says 'if you're posting in General Discussion, you're not in Admin or GM and you're making a new post, send it for moderation'. It's that simple. You can add all sorts of conditions to it - based on board type, post count, membergroups, user warnings, how many links in the post, or even base it on whether the subject or post contain certain words. Instant profanity filter right there.

I thought this was a really interesting take on the concept of applying permissions to users - to reframe it around the outcome rather than the method. But yeah, mostly it has the same thoughts as SMF even though we definitely tried to improve it. I think on the whole we succeeded more than we didn't.

 

[Tracy]

I'm not generally interested in how granular or coarse the permissions are; for the most part they're fairly comparable. Basically in my head, 'can see a board', 'can enter a board', 'can create a topic', 'can reply to topic' are the fundamentals,

That's a pretty limited to a "forum only" aspect. But simply, in todays age, a product needs to offer well more than a "simple forum"... and permissions for those extensions follow. You aren't going to be able to replicate FB/Twitter(or whatever Elon is deciding to call it this week).

An issue with even social media is it is becoming fragmented.

The ironic thing... apparently the script you are commenting on "pushes" permission abilities/functions that have been in "paid" software script for over a decade in many cases. And one wonders why the "free software" scripts are getting left behind?

 

[Arantor]

Right, let's do something a little bit different. I have a copy of Flarum installed; it's not the most recent version but I don't believe this has radically changed since then.

First up, Flarum doesn't strictly have the view that things are 'boards', instead we have 'primary tags' and 'secondary tags' that are for categorisation. For example, you could tag a topic as 'Meta' if it's rules or an announcement, but you might tag it Meta/Blog such that it's technically in Meta, but sub-classified as Blog for specificity.

You'll see that you mostly focus on the tags themselves and how things can be classified and in different ways, rather than the permissions for that. That's set elsewhere.

Flarum does something interesting, it's essentially a single unified view of permissions.

What's really interesting is that here you're essentially defining the membergroups as well as the permission sets for them in one place.

Out of the box, the groups are Admins and Mods, as you see above. Here, I've added a third group (Special Folks), and added some tag restrictions for example.

There's a lot to unpack here, interestingly.

First up, 'view board' as we think of it is explicitly a permission - in a way that it's not in SMF. Secondly, we're clearly delineating between 'global' permissions and everything else, and we're not actively trying to create permission sets here. (This matches closer to what SMF 1.x did with the idea of 'global' and 'local' permissions rather than a profile-based approach, as that works better on much larger forums to keep permissions sets consistent.)

What's more interesting to me, though, is the fact that we're getting to visualise all the permissions at once across the site. There's 'global' and then for each tag where there's a specific ruleset, there's the ability to see it in relation to others. That's very convenient, and if you don't have masses of tag-specific exceptions it's very convenient. (The implication is that it subtly encourages you to not do that in general.)

What's also interesting is how the group selector works. You can set 'everyone', 'members' or some combination of groups - there's no option for 'everyone except x' and that also apparently follows that you couldn't lock someone out easily if they're already in another group. Of course, that's the pain of multiple groups vs deny permissions, and in particular what happens if you don't have them, but this just encourages you down a specific path rather than leaving too many paths open to you.

I'm personally in one of two minds about whether this is a good philosophy; I've certainly seen it throughout the ages that some communities need the ability to restrict users rather than allowing everything to be stackable additively. The obvious example is a 'troublemaker' group where you want to do something that isn't a ban in the strictest sense but that you want to curb them from being amongst the general populace. A sin bin, or similar concept perhaps, or somewhere to discuss corrective behaviour in lieu of just slamming the ban hammer down.

Thing is, though, Flarum's target demographic is the mobile-first audience; that's evident from how things like attachments are not a core feature (because file management on mobile is annoying), and the otherwise minimalist UI. It makes sense that they're not going for deep granularity because they'll likely just ban people rather than trying to work around the things - and likely as not they'll have fewer groups because the combinations of purely aesthetic groups that you saw on classic desktop forums are simply less relevant here; pretty much all groups will be permissions groups rather than aesthetic groups. I suspect in practice the apparent lack of deny permissions is not a huge problem for them.

 

[Arantor]

That's a pretty limited to a "forum only" aspect.

You can readily extrapolate for all other content types to 'can see content', 'can add content'. But since the collection of packages I have doesn't all have that option, I'm trying to look at what common ground they do have and that cluster of permissions is the minimal viable collection of permissions anyway.

 

[Tracy]

You can readily extrapolate for all other content types to 'can see content', 'can add content'. But since the collection of packages I have doesn't all have that option, I'm trying to look at what common ground they do have and that cluster of permissions is the minimal viable collection of permissions anyway.

The basic problem that those "free" scripts have... is simply their limitation on what they offer. To be successful in todays era, they are going to have to offer (either by 1st party add-ons or 3rd party) WELL beyond simple posting ability in many aspects. It's MUCH easier if a person can not only post text, but various media directly to the site and in cases it be able to be reused ( a SEVERE lacking in Xenforo for the past decade - and a massive ignoring of such by it's developers, but I can't comment to the other major paid scripts as I no longer use them) in additional posts instead of having to either upload it again or link to it in a previous post or to the remote site..

 

[Arantor]

The basic problem that those "free" scripts have...

...is that when I cover XF, IPS, vB etc. I'm only going to be looking at the exact same part of it because setting permissions is broadly the same regardless of content type, and it's the 'how do I set permissions' part that's the interesting part here, not generally what the permissions are. There's a few specific things I get at, like the one software that bothers to break admin permissions up, or how complex post moderation is despite notionally being just a permission.

You're so desperate to keep making your point, you ignore what the topic is actually about.

 

[Cedric]

This is really great. Kudos Pete.

I’ll come back to this when my health is a little better.

 

[Tracy]

You're so desperate to keep making your point, you ignore what the topic is actually about.

No, you simply prefer to ignore input that is vital to maintaining a "qualified" site in todays standards.
Sorry.. simple posting of crap equals crap. You are going to have to offer the users MUCH more than the ability to make a simple post to attract them.. shit, they can already do that on Twitter/FB/multitude of other social sites. You have to offer them MORE than that ability.

and it's the 'how do I set permissions' part that's the interesting part here, not generally what the permissions are.

You don't... THEY (the admins) do. You simply offer yes/no options to the functions of the script you are providing.
You offer a "function"... it's either available or not. It's not exactly rocket science. You don't have to push down to the macro level as most base features for unregistered users are at one level..... then you add to it. You want a good example... simply look at how XF does it. Their permission sets are VERY difficult for new users to comprehend... but when one actually starts looking at them, you realize the power of it. It's not the "you are in this group so you only have these permissions" closed minded aspect... permissions are cumulative Yes, it can get confusing... but if you can't grasp the ability offered.. maybe one shouldn't be "administering" a site.

 

[Arantor]

Back on topic, here's a demonstration of why Tracy is wrong. Let's take a look at a different forum package most people will never have seen in the wild but that is freely available: miniBB.

I do own all the paid plugins for it but I only installed this test forum last night, I haven't installed all the plugins, and none of them touch on permissions anyway, at least not in the context I'm trying to get at.

miniBB is the definition of minimalism. Amongst things not in the open source/free edition: attachments, polls, contact form. They're all paid plugins ($5 for each, lifetime licence though only 10 downloads per purchase)

The 'mini' part really does carry through the admin panel, however, because... it has no permissions area at all. I'm not kidding. This is the ACP:

There's not even visibility permissions in the board config; it's just title/description/board icon/board category.

You want to set restrictions on who can see which forums? You're writing some code. You're editing bb_specials.php and adding code like this:

$clForums = array(1); // Board 1 is a closed board.
$clForumsUsers[1] = array(2,5); // Board 1 is only visible to users 2 and 5, and anyone who is an admin.

Meanwhile if your requirement is just 'must be logged into see it', you're writing a different line in bb_specials.php.

You want to make a board read-only? You're writing code in bb_specials.php in much the same way.

You want to make a board reply-only? You know where this is going.

You want to set users as moderators? Yup, you guessed it, you're writing code in bb_specials.php:

$mods=array(
    1=>array(9,996),
    2=>array(9)
);

User 9 is a moderator for both boards 1 & 2, and user 996 is a moderator for board 1.

But what powers do moderators have? Well, there's no permission for deleting messages, that's admin only. Admins and moderators can delete topics (but not individual messages?) and you can set something in the code to also allow members to delete their own content.

Admins and moderators can edit messages, users can edit their own (unless a moderator locks the message from editing), but none of this is configurable as far as I can tell beyond setting who is a moderator.

Only admins can move topics. Admin and topic owner can lock a topic; both can unlock unless you set a thing in bb_specials.php. Admins and moderators can sticky topics.

I can see the appeal of this: it's *super* minimal and as a result it's super fast this way. But it's super unfriendly too.

 

[Arantor]

You don't... THEY (the admins) do.

I was under the impression this was a forum for admins to discuss how admin things work. Surely it's worth looking at other systems in case anyone has different (or possibly better) ideas about how to do things?

XF's take is complicated, because it's trying to appeal to all the cases. Flarum for example doesn't feel the need to be as complex as XF. And, well, SMF chooses to arbitarily be more confusing than XF while being broadly the same functionality. And miniBB chooses to have literally no permissions UI at all.

That's what's interesting here: how different systems approach the same problem. And it *really* doesn't matter what other permissions there are. Unless you're going to sit here and tell me that configuring permissions for AMS or XFRM or XFMG or XenPorta or whatever else is so *wildly* different to configuring them for base XF, then we *might* have something to talk about, but you can do that in your own topic.

In any case, there is value in having a common frame of reference when discussing things.

But as a further case, you have no idea what formats of content I'm supporting, how they're presented, what methods of moderation might be relevant, or how any of that converts into permissions, so until I explain that (which I'm not going ot at this point) kindly stop derailing the topic with unnecessary repetition of irrelevant points.

 

[Tracy]

XF's take is complicated, because it's trying to appeal to all the cases.

Incorrect... XF is "complicated" because it allows a much more minute control of user abilities.
I'd MUCH rather have that ability than a "you can only do this because we don't think you need more" aspect (IPS being a classic case).

hat configuring permissions for AMS or XFRM or XFMG or XenPorta or whatever else is so *wildly* different to configuring them for base XF, then we *might* have something to talk about, but you can do that in your own topic.

Actually.. they (at the base level) are exactly that. Many of the "functions" are similar... but there are MANY additional items in those 3rd party add-ons that do NOT exist in the base XF script and have no correlative permissions.

But as a further case, you have no idea what formats of content I'm supporting, how they're presented, what methods of moderation might be relevant, or how any of that converts into permissions, so until I explain that (which I'm not going ot at this point) kindly stop derailing the topic with unnecessary repetition of irrelevant points.

Then until you detail those aspects and request input... You ask for input.. you are given it...and then choose to "lash" out at it if it goes against what you want to hear.
I'm beginning to see why you had issues with the folks over SMF development. 🤔

 

[Arantor]

You ask for input..

I didn't ask for input.

This is a reflection on what's out there already while I'm musing on the subject. And it's a brief look into forum platforms that not everyone has seen.

And I'm mindful that I don't have the same exact content to manage as some of these other things. But I repeat myself on this score.

I'd MUCH rather have that ability than a "you can only do this because we don't think you need more" aspect (IPS being a classic case).

Personally, so would I. However, not everyone is you or me, and some people are very very happy with the IPS style of solution. Some people are very content with less. (E.g. the miniBB people.)

If you'd kindly stop interrupting me, for the second time of asking, I'll get through all of the different things so we can compare all of them and draw out the things that are interesting about them, and whether for different kinds of users, whether a given solution is better than others, for different kinds of users.

but there are MANY additional items in those 3rd party add-ons that do NOT exist in the base XF script and have no correlative permissions.

And it still doesn't matter. Now that I think about it, Classifieds is one of the things you usually trot out, and in this case it makes a great example - it will have permissions that the core won't. And that's fine - but the act of *setting those permissions* is still basically the same, and still comes down to 'can I see the content' and 'can I interact with the content'. Everything else is a variation on those two points, whether you can read/create/update/delete that content. Whether you get notifications about that content. Whether you can score it/rate it/like it/react to it. And it really doesn't matter that the permissions aren't correlative, because they don't have to be.

I didn't, for example, bring up SimpleDesk or Levertine Gallery - SMF addons that both do things *very* differently to SMF itself. Radically differently. Why not? Because it's not relevant. I was very proud of what I did there, too, but it's not the same mentality or the same frame of reference so I'm not going to cover it in this topic. Maybe I will in the next topic.

Until then can I suggest you put this topic on ignore please?

 

[Arantor]

Now for something completely different. If you hadn't heard of miniBB before (even though Paul, its developer, did occasionally post on TAZ), you probably never heard of CBACK. It's not free - it's €39 for a licence plus a year's updates (or €89 for a year's licence plus premium support)

It's also very German. The default install even drops things into it in German like the default names for groups, default board content and so on. My wife's German so I can cope with it but it's... an interesting experience. I've fixed the group names so they're more useful.

There's a lot to unpack in this particular picture, most of which is really not immediately obvious.

First up: Category 1 is visible to Administrator and Members, and not Guests. That's not to say that Guests can't interact with the content, but the entire category is simply not shown by default. (If they know the URL, or can guess the ID, they can see the boards readily enough if they otherwise have permission)

The second thing to note is that templates are not as hardwired here as they are in other platforms, despite how it might initially appear.

Like Flarum, access to a given board is a permission in its own right, and as you can probably tell from this screenshot, all three groups can see Test Forum, and all three can enter Test Forum. The rest of the permissions under 'Forum' are create topic/create reply/tag topic as important/reviews/group is moderator in this forum. (I have that last one ticked; it isn't by default)

As a holistic overview it's interesting because most platforms don't give you that overview - it doesn't lend itself to big forums with many boards in if that's the display for a single board.

There are several templates in the core:

And you can create your own templates too.

But they are much more 'templates' than 'profiles' because you can deviate from the templates, exactly as I have - the idea is that you create the templates as 'for a board, this is what each of my groups should be able to do', and then apply that to a board or collection of boards to replace what's there.

Then you can configure individual exceptions if you wish...

The warning above the form is relevant for larger sites because PHP certainly caps that by default (it's 1000 ticked boxes, which won't take very long to fill on a big board hence 'use the templates to set things on a specific forum')

What's also interesting is that admins are not implicitly special here - they have all the features by default but you can turn them off. This is adhered to, not a UI oddity, e.g. if you remove the 'reviews' permission, you can't leave a score out of 5 stars on a topic. This makes an interesting change to platforms that assume admins always have all permissions and does mean you can avoid having a toggle on a feature for 'disable this feature'. But it also means you can do things like hiding a board from admin. I've seen use cases where this is a thing in the past, and it's a really niche feature but it's one thing you can do here natively.

It's worth noting that as a result of this design, while the admin panel does sort of work on mobile... it's really really not good on mobile.

 

[Tracy]

This is a reflection on what's out there already while I'm musing on the subject.

You muse... you are by default "asking" for input.

However, not everyone is you or me, and some people are very very happy with the IPS style of solution. Some people are very content with less. (E.g. the miniBB people.)

But that's not what you asked for input about. Those that want minimal input in permissions can broadcast their choice... those that want more "minutia" in their control aspects will also voice their position. Ultimately... the more minute the control, the better an admin can control what they offer to their clients.

Now that I think about it, Classifieds is one of the things you usually trot out, and in this case it makes a great example - it will have permissions that the core won't. And that's fine - but the act of *setting those permissions* is still basically the same, and still comes down to 'can I see the content' and 'can I interact with the content'.

And the base fact is that the script (at it's core level) has to OFFER those abilities. Depending on what the back end offers to the admins... those functions could (or could not) be available. It simply devolves into what level the script offers to third party developers above what the as script offers.

If you'd kindly stop interrupting me,

Sorry... you post on a public forum and your posts have "warts"... they are going to be brought to the forefront.

Until then can I suggest you put this topic on ignore please?

Pretty sure the content posted was EXACTLY on topic.... now may it have been what you desired? Probably not.
Some of us live in reality.. and then others of use live in fantasy land of "what could/should be".

 

[Arantor]

you are by default "asking" for input

If I wanted input, I'd have given you enough context for it. And I'd actually use the word 'ask' or some actual synonym. Since I have done neither of these things...

But that's not what you asked for input about.

I didn't ask for input. And you have no clue whatsoever about my target audience, their wants, their needs, their frame of reference.

Hint: it doesn't overlap nearly as well with you and your needs as much as your ego would like to think.

And the base fact is that the script (at it's core level) has to OFFER those abilities.

And the base fact is that the script does not have to offer those abilities because the target audience will literally never, ever, ever use them. I do, on the other hand, have to offer functionality that my target audience will use. And it's things you have zero use for and would question the entire premise of. But fortunately this isn't a platform you'll be using, for multiple reasons.

In case it wasn't already clear: I am not building a generic forum script. I'm also not building a script that's even self-hostable.

You are not in my target audience. If I had wanted your input, I would have made it clear that I was asking, I would have outlined what I was interested in getting feedback about, and I wouldn't have pointed out now for the third time that I do not want your feedback because it is in no way relevant.

Pretty sure the content posted was EXACTLY on topic.... now may it have been what you desired?

What I desired was to just go through and post about all the different forum platforms, in relative peace, and reflect on what could be learned from them and their different approaches to things. Why they do what they do. What choices they made in getting there. And see whether this lead me down one path or another.

It's also interesting for other people who haven't seen the different platforms. But you know, you do you.

I have now asked you three times to refrain from getting into this. If you persist I will start reporting them with a request they be moved or deleted as off-topic.

 

[Cedric]

Tracy stop arguing for fucks sake. Drop it now.

 

[joelr]

This is a fascinating look at permissions, and I thoroughly enjoy reading your thought process.

 

[Aaron]

These are really awesome! I know a few newbie forum owners who get confused about navigating admin dashboards.