I’ll get back to doing the others later when I don’t feel so awful.
Welcome to Admin Junkies, Guest — join our community!
Register or log in to explore all our content and services for free on Admin Junkies.
Site Management Forum permissions
- Thread starter Arantor
- Start date
For discussions on the overall management and administration of websites and forums.
As usual, spot on analysis. Looking forward to the rest of it 
Alrighty, time to get this show back on the road. Next up, a forum software that I'm certain almost no-one here will have heard of, and has since basically been abandoned by its author.
I give you, Vesta Athens. Vesta Athens (formerly Gaia Athens) is the product of someone who originally wrote their roleplay stuff as an SMF mod - but we never saw the author at simplemachines.org because we're all too mean and unpleasant, and in the end they found it too restrictive as a mod and made their own.
Vesta, then, is roleplay first, from scratch (but anyone who's ever worked with SMF will feel at home in the code), and Vesta's author got extremely upset that someone wanted to make a mod and share it. That was an interesting moment where I realised I had to check my privilege.
Anyway.
This is the board configuration screen. There is far more going on in this screen than it would appear.
Do note I have not changed the colour of the Eros theme, this is how it comes out of the box. Boards have a title and a WYSIWYG (hi TinyMCE) description editor. So far so normal.
It's interesting to note that it is here - and only here - that we set the 'sort topics by', because the front end doesn't have this otherwise. It's not configurable like it is on other platforms, but interestingly that's not really a problem because generally this isn't something you actually need.
Next thing I want to point out is the bottom area. You will note there is no deny option here, but also interestingly you can create a board that the admin cannot see. I don't think this is a deliberate design choice, though, just not stepping through the logical consequences of whether you'd ever want a board not to be visible to admins on a site they have to manage (especially because they can still go turn it back on for themselves later)
Then we have the actual permissions, such as they are. The presumption is that 'if you can see it, you can post there' with the only actual permission choice being for guests, such that you might make a board that guests can see but can't post in.
You might think this permission setup is weird otherwise but it's actually not that surprising for RP because most people who play in the RP world figure out where they want to post and how they should be posting and just *behave*. (It is instructive to note that Vesta has zero options for moving topics between boards, or splitting topics. These are things that just don't come up in RP land the way they do in regular forums.)
Enabling character posts is an interesting feature - what it ultimately means is that if not enabled, the board functions relatively normally as you would expect - you have an account, you post as that account. (Unless you're an admin, then you can start a topic literally as any user). Meanwhile enabling character posts turns on the extra facilities for posting as a character, which is a subset of an account rather than a full account. It really is the best approach here to do this.
Probably the most interesting feature here is joint posting. This essentially turns a board into a sort of 'everyone's a moderator' deal where anyone can edit anything if they can see it. Me personally I'd never enable it but for some specific subsets of sites I could see this being useful; the reality is that *most* people in the community are surprisingly well behaved and trolls tend to get booted quite quickly if it's clear they're not meshing with the community spirit.
Last but not least, read-only board is as it sounds, a hard 'read only' (except for admins of course). Haven't tested with moderators.
From a wider permissions setup, since it's relevant real quick... there are two kinds of groups, member groups and character groups (though the terminology varies in the admin panel as to whether this is 'character groups' or 'alliances'), but in practice the only distinctions that matter are that character groups are basically purely aesthetic and member groups are mostly permissions. Member groups control, in practice, 3 permissions: 'site owner', 'super user' and 'can use HTML'. That's the only permissions you actually have, and a member can only be in one group at a time. Site owners = admins and can do all the things, super users = moderators and can do things like post editing and deletion, but it's not very broken down into detail.
And that's really the recurring theme, and it's not an unfair one: RP communities do not tend to get particularly large in actual practice; they might seem to have vast numbers of members but in practice they're not really all members, they'll be a much smaller number of actual members with subaccounts glued on for the different characters they have, and in a small tight-knit community you can get away with much simpler permission models both for access and posting.
This will feel alien to many of us here who are used to much richer permissions models but actually, objectively, this is fascinating because this is built from the ground up for its target audience (although as I should get into another time, it actually misses its mark for the bulk of its target audience for other reasons), as opposed to what the usual forum developers do which is build what their experience suggests is the balance between desire and necessity.
I'm not going to dwell on it too much because it's out of scope, but you'll notice the surprising variety of things on the left menu, e.g. an affiliates system is *core*. It's very normal still to have affiliates going on in RP land. Most of the rest is variations on what you'd expect but notice that the forum isn't really the biggest focus here...
EDIT: As a footnote, part of the off-topic argument was about my use case for permissions - Vesta is much, much closer to what I'm thinking of doing than, say, XF because honestly this flattened permissions model makes more sense. You don't need a huge, super detailed permissions set for like 5-15 active people. Probably don't even need moderators if you have limited processes and suchlike.
I give you, Vesta Athens. Vesta Athens (formerly Gaia Athens) is the product of someone who originally wrote their roleplay stuff as an SMF mod - but we never saw the author at simplemachines.org because we're all too mean and unpleasant, and in the end they found it too restrictive as a mod and made their own.
Vesta, then, is roleplay first, from scratch (but anyone who's ever worked with SMF will feel at home in the code), and Vesta's author got extremely upset that someone wanted to make a mod and share it. That was an interesting moment where I realised I had to check my privilege.
Anyway.
This is the board configuration screen. There is far more going on in this screen than it would appear.
Do note I have not changed the colour of the Eros theme, this is how it comes out of the box. Boards have a title and a WYSIWYG (hi TinyMCE) description editor. So far so normal.
It's interesting to note that it is here - and only here - that we set the 'sort topics by', because the front end doesn't have this otherwise. It's not configurable like it is on other platforms, but interestingly that's not really a problem because generally this isn't something you actually need.
Next thing I want to point out is the bottom area. You will note there is no deny option here, but also interestingly you can create a board that the admin cannot see. I don't think this is a deliberate design choice, though, just not stepping through the logical consequences of whether you'd ever want a board not to be visible to admins on a site they have to manage (especially because they can still go turn it back on for themselves later)
Then we have the actual permissions, such as they are. The presumption is that 'if you can see it, you can post there' with the only actual permission choice being for guests, such that you might make a board that guests can see but can't post in.
You might think this permission setup is weird otherwise but it's actually not that surprising for RP because most people who play in the RP world figure out where they want to post and how they should be posting and just *behave*. (It is instructive to note that Vesta has zero options for moving topics between boards, or splitting topics. These are things that just don't come up in RP land the way they do in regular forums.)
Enabling character posts is an interesting feature - what it ultimately means is that if not enabled, the board functions relatively normally as you would expect - you have an account, you post as that account. (Unless you're an admin, then you can start a topic literally as any user). Meanwhile enabling character posts turns on the extra facilities for posting as a character, which is a subset of an account rather than a full account. It really is the best approach here to do this.
Probably the most interesting feature here is joint posting. This essentially turns a board into a sort of 'everyone's a moderator' deal where anyone can edit anything if they can see it. Me personally I'd never enable it but for some specific subsets of sites I could see this being useful; the reality is that *most* people in the community are surprisingly well behaved and trolls tend to get booted quite quickly if it's clear they're not meshing with the community spirit.
Last but not least, read-only board is as it sounds, a hard 'read only' (except for admins of course). Haven't tested with moderators.
From a wider permissions setup, since it's relevant real quick... there are two kinds of groups, member groups and character groups (though the terminology varies in the admin panel as to whether this is 'character groups' or 'alliances'), but in practice the only distinctions that matter are that character groups are basically purely aesthetic and member groups are mostly permissions. Member groups control, in practice, 3 permissions: 'site owner', 'super user' and 'can use HTML'. That's the only permissions you actually have, and a member can only be in one group at a time. Site owners = admins and can do all the things, super users = moderators and can do things like post editing and deletion, but it's not very broken down into detail.
And that's really the recurring theme, and it's not an unfair one: RP communities do not tend to get particularly large in actual practice; they might seem to have vast numbers of members but in practice they're not really all members, they'll be a much smaller number of actual members with subaccounts glued on for the different characters they have, and in a small tight-knit community you can get away with much simpler permission models both for access and posting.
This will feel alien to many of us here who are used to much richer permissions models but actually, objectively, this is fascinating because this is built from the ground up for its target audience (although as I should get into another time, it actually misses its mark for the bulk of its target audience for other reasons), as opposed to what the usual forum developers do which is build what their experience suggests is the balance between desire and necessity.
I'm not going to dwell on it too much because it's out of scope, but you'll notice the surprising variety of things on the left menu, e.g. an affiliates system is *core*. It's very normal still to have affiliates going on in RP land. Most of the rest is variations on what you'd expect but notice that the forum isn't really the biggest focus here...
EDIT: As a footnote, part of the off-topic argument was about my use case for permissions - Vesta is much, much closer to what I'm thinking of doing than, say, XF because honestly this flattened permissions model makes more sense. You don't need a huge, super detailed permissions set for like 5-15 active people. Probably don't even need moderators if you have limited processes and suchlike.
Last edited:
Next up, Codoforum by Codologic. This one is definitely an oddity though I think it's ended up homogenising itself a little to its peers; we're on the 5.x series now, but in the 2.x and 3.x era it *definitely* had a point of view that was a bit different.
I'll leave you to explore the main community to get a feel for what the front end looks like - http://codologic.com/forum/ - because it *is* a bit different to the others.
But as for the backend... that's, well...
I'm not averse to the single create-and-manage view of categories on a forum, at least in concept. But what this doesn't immediately make clear is that there is actually a way to not have a category be visible, you just have to edit the category's permissions.
What happens once you have the category, of course, is that you can enter the permissions screen for it where you'll see you can edit the visibility of the category, and of the topics in it, as permissions for it.
Now this *is* an interesting take for several reasons. Firstly, the notion of 'view my topics' vs 'view all topics' is a method (though, I'd argue not an intuitive one) for producing helpdesk-type areas, but what's also interesting to note is that 'view category' isn't the first permission on the list, it's all the way down after editing and deleting topics.
What's also interesting to me is the terminology, that permissions are 'granted or denied' but actually... they're not denied, they're disallowed - it's 'absence of permission' rather than 'presence of explicit refusal', and this is something we've seen in SMF (and we will see in other platforms when we get there)
I'm not sure the interface is as clear as it could be but it is functional and everything does work the way it claims to.
I'll leave you to explore the main community to get a feel for what the front end looks like - http://codologic.com/forum/ - because it *is* a bit different to the others.
But as for the backend... that's, well...
I'm not averse to the single create-and-manage view of categories on a forum, at least in concept. But what this doesn't immediately make clear is that there is actually a way to not have a category be visible, you just have to edit the category's permissions.
What happens once you have the category, of course, is that you can enter the permissions screen for it where you'll see you can edit the visibility of the category, and of the topics in it, as permissions for it.
Now this *is* an interesting take for several reasons. Firstly, the notion of 'view my topics' vs 'view all topics' is a method (though, I'd argue not an intuitive one) for producing helpdesk-type areas, but what's also interesting to note is that 'view category' isn't the first permission on the list, it's all the way down after editing and deleting topics.
What's also interesting to me is the terminology, that permissions are 'granted or denied' but actually... they're not denied, they're disallowed - it's 'absence of permission' rather than 'presence of explicit refusal', and this is something we've seen in SMF (and we will see in other platforms when we get there)
I'm not sure the interface is as clear as it could be but it is functional and everything does work the way it claims to.
OK so let's talk about something more typical: XenForo.
Like some of the others, XF pushes board access down to its actual permissions rather than a set of toggles in the board's configuration (or, more properly, the node configuration since not all nodes are boards)
But it doesn't quite apply the same logic as others on this front.
So, as others do, the ability to view a node is a permission.
But the way it works is... not immediately intuitive.
You set the default rules for each of the groups here in User group permissions, but then you can mix it up per-node. Yes/No/Never works here as you'd expect the terminology to imply (that Yes + No = Yes, No + No = No, anything + Never = Never)
Then we have to deal with the concept of inheritance.
And here's where people inevitably screw this up. You have the rules say 'inherit' but it's not clear where they inherit *from*. The term implies that it inherits from boards higher up the list, but this is not what happens.
What it means is that it will inherit from the default permissions for that group - so here, this is the permissions for the Registered group, in a specific node, and where it's not set explicitly, it's 'inheriting' from the default for the group for all those permissions.
There is no inheritance in a sub-node of permissions from the parent node, at least not that I can see or verify in testing.
This is also not helped by the 'Analyze node permissions' feature which will tell you where a given permission comes from but the initial presentation can confuse if you have a lot of per-node overrides. What happens is, it'll show you the rules for the base groups and then every individual node that has permission will also be shown. It can get messy fast, especially because the way it's set up I fully expect people to select more groups for explicit permissions than they actually need because the mental model is really not obvious.
Now, this whole setup is very powerful, no denying, but it's on the verge of being so powerful it actually becomes unintuitive without some care and thought.
It's also one of the reasons I wonder very long and hard about whether 'view board' should actually be a permission or not - from a technical perspective that makes it super easy to implement, especially if you're going to wrangle profiles and inheritance type stuff. But from a user-configuration perspective I continue to be unconvinced this is the best way to configure it, and that I continue to believe the SMF model of separating access from inner permissions might be the superior one.
Like some of the others, XF pushes board access down to its actual permissions rather than a set of toggles in the board's configuration (or, more properly, the node configuration since not all nodes are boards)
But it doesn't quite apply the same logic as others on this front.
So, as others do, the ability to view a node is a permission.
But the way it works is... not immediately intuitive.
You set the default rules for each of the groups here in User group permissions, but then you can mix it up per-node. Yes/No/Never works here as you'd expect the terminology to imply (that Yes + No = Yes, No + No = No, anything + Never = Never)
Then we have to deal with the concept of inheritance.
And here's where people inevitably screw this up. You have the rules say 'inherit' but it's not clear where they inherit *from*. The term implies that it inherits from boards higher up the list, but this is not what happens.
What it means is that it will inherit from the default permissions for that group - so here, this is the permissions for the Registered group, in a specific node, and where it's not set explicitly, it's 'inheriting' from the default for the group for all those permissions.
There is no inheritance in a sub-node of permissions from the parent node, at least not that I can see or verify in testing.
This is also not helped by the 'Analyze node permissions' feature which will tell you where a given permission comes from but the initial presentation can confuse if you have a lot of per-node overrides. What happens is, it'll show you the rules for the base groups and then every individual node that has permission will also be shown. It can get messy fast, especially because the way it's set up I fully expect people to select more groups for explicit permissions than they actually need because the mental model is really not obvious.
Now, this whole setup is very powerful, no denying, but it's on the verge of being so powerful it actually becomes unintuitive without some care and thought.
It's also one of the reasons I wonder very long and hard about whether 'view board' should actually be a permission or not - from a technical perspective that makes it super easy to implement, especially if you're going to wrangle profiles and inheritance type stuff. But from a user-configuration perspective I continue to be unconvinced this is the best way to configure it, and that I continue to believe the SMF model of separating access from inner permissions might be the superior one.
XF's permissions are definitely the most confusing ones I've ever seen. And at the same time as you said, very powerful. Once you get to know them, they're very fun to play with. Mind you, it took me literally almost a year to fully understand how they actually work.
Awesome posts again.
It's also funny how some things are different for RP. Considering there is a complete different audience. I never heard about Vesta Athens. Codoforum doesn't look too bad, but apart from that, everything is said. I wouldn't use it because of how the homepage looks. I'm too old fashioned, maybe, ha...
Awesome posts again.
It's also funny how some things are different for RP. Considering there is a complete different audience. I never heard about Vesta Athens. Codoforum doesn't look too bad, but apart from that, everything is said. I wouldn't use it because of how the homepage looks. I'm too old fashioned, maybe, ha...
With great power comes great responsibility.
Most people have never heard of Vesta Athens/Gaia Athens, you mostly only would have encountered it if you'd spent any time at RPG Initiative where its founder used to hang out, with a few sparse mentions at RPG Directory.
You can definitely abuse most normal forums to run RP sites, but RP-first software is generally not suitable for running general communities, too many things in the way.
As for Codoforum I wish I had the version I first saw maybe a decade ago. It did interesting things that no-one else was doing then. And now it doesn't do them any more.
Seems that Codoforum doesn't do much development anyway.With great power comes great responsibility.
Most people have never heard of Vesta Athens/Gaia Athens, you mostly only would have encountered it if you'd spent any time at RPG Initiative where its founder used to hang out, with a few sparse mentions at RPG Directory.
You can definitely abuse most normal forums to run RP sites, but RP-first software is generally not suitable for running general communities, too many things in the way.
As for Codoforum I wish I had the version I first saw maybe a decade ago. It did interesting things that no-one else was doing then. And now it doesn't do them any more.
OK, time for one that I'm sure some people are curious about, Invision Community.
I'll admit I'm a little behind on my local here; this is 4.6.5.1 mostly because patching it up to 4.7.x will require me to sit and rebuild the Docker container to bump it to PHP 8 and that's a level of effort I can't currently be bothered with doing for a purely internal test site. I don't believe it's wildly different from the current 4.7 release. All bets are off about 5.x though for the purposes of this comparison!
First thing to notice is the permissions on a board specifically because there are some per-board permissions that we actually set in the board's own configuration.
Setting a password on a board is here - something we don't see a lot of any more - as well as 'minimum content count'. This strikes me as interesting because it's basically a post count permission, something that other systems more or less shun at this point. (And not without good reason. SMF of course has post count groups that you could hang board access off, XF you could make it happen with a group promotion setup.)
And of course the 'helpdesk type board' is a set up here, as well as how the behaviour around opening a forum works.
What strikes me from a UI perspective is that these are permissions in all but name but they're not *presented* as such, and I think that's interesting, because while they're permissions in practice, they're *also* really behavioural modifiers in a way a classical permission isn't.
What makes that interesting is something I didn't talk about much in the XF display: the XF permissions also include things that are behaviour modifiers, for example time limit on editing posts because that's sort of a permission too, just a temporal modifier on how long you might have that permission.
IPS takes the view that behavioural modifiers as permissions aren't permission and should live in the area that they control the behaviour of, which is a perfectly valid position to take. (In that regard it's more similar to SMF than XF from what we've seen.)
But if we look in the Posting Settings tab for a board, we see the line gets more blurred.
Now we're looking at things that aren't behavioural modifiers but actual permission blocks: whether you need a post count to post, and its approval status.
Again the focus on post counts and the notion of progression-based contribution: something that I wonder how much use there really is, because in all the cases I've seen it, it's ended up being problematic once you get beyond the initial contribution phase (and that you almost want a different approach for that is more outcome-orientated, see my thoughts on Wedge for more)
On the flip side this makes the permission area very simple to drive.
As you can see, the actual number of permissions selectable per group is pretty minimal (though this is just the forum module, you can see the other tabs), but because we already saw the fiddly stuff managed in a board's own configuration (including 'see own topics' vs 'see all topics'), we're left with a really minimal set of permissions here.
Which brings to mind several questions, really, but actually... that's because I've misdirected you a little.
There is one more area for configuring the rights and privileges of groups - in the groups configuration itself.
There's many more options (for example the classic edit-time restriction is further down the Content tab), which are intentionally framed not as permissions but behavioural modifiers on the group (as opposed to within a given board)
This is really quite interesting - you have the 'group options', 'group permissions across boards', 'group permissions on a board level'. Now, it's true that the group configuration in XF also exposes the default permissions for that group but it's *presented* as permissions and shares the same permissions UI as the main user group permissions UI.
This on the other hand is a radical departure, because there are many things that are *not* framed as permissions even if they are, or they're lumped in with behavioural modifiers that aren't really permissions as such (or they're half way between the two, see edit-time restrictions), but it does mean that you have to think a little about where to go to get what done.
I don't think there's any obvious things that XF or IPS can do that the other can't (or, for the most part, SMF come to that, though SMF's idea of edit time restriction is all non-moderators with a single limit, rather than a per-group rule), but I think there's pros and cons to the way these platforms approach this problem.
I personally prefer XF's take on it, that the group settings are (mostly) for the group display and general behaviour, and that behaviour modifiers are really a subset of permissions, as opposed to IPS's take that behavioural modifiers are a complete sidestep from permissions, but I can see people arguing passionately the other way, especially if you're a fan of IPS in general.
I'll admit I'm a little behind on my local here; this is 4.6.5.1 mostly because patching it up to 4.7.x will require me to sit and rebuild the Docker container to bump it to PHP 8 and that's a level of effort I can't currently be bothered with doing for a purely internal test site. I don't believe it's wildly different from the current 4.7 release. All bets are off about 5.x though for the purposes of this comparison!
First thing to notice is the permissions on a board specifically because there are some per-board permissions that we actually set in the board's own configuration.
Setting a password on a board is here - something we don't see a lot of any more - as well as 'minimum content count'. This strikes me as interesting because it's basically a post count permission, something that other systems more or less shun at this point. (And not without good reason. SMF of course has post count groups that you could hang board access off, XF you could make it happen with a group promotion setup.)
And of course the 'helpdesk type board' is a set up here, as well as how the behaviour around opening a forum works.
What strikes me from a UI perspective is that these are permissions in all but name but they're not *presented* as such, and I think that's interesting, because while they're permissions in practice, they're *also* really behavioural modifiers in a way a classical permission isn't.
What makes that interesting is something I didn't talk about much in the XF display: the XF permissions also include things that are behaviour modifiers, for example time limit on editing posts because that's sort of a permission too, just a temporal modifier on how long you might have that permission.
IPS takes the view that behavioural modifiers as permissions aren't permission and should live in the area that they control the behaviour of, which is a perfectly valid position to take. (In that regard it's more similar to SMF than XF from what we've seen.)
But if we look in the Posting Settings tab for a board, we see the line gets more blurred.
Now we're looking at things that aren't behavioural modifiers but actual permission blocks: whether you need a post count to post, and its approval status.
Again the focus on post counts and the notion of progression-based contribution: something that I wonder how much use there really is, because in all the cases I've seen it, it's ended up being problematic once you get beyond the initial contribution phase (and that you almost want a different approach for that is more outcome-orientated, see my thoughts on Wedge for more)
On the flip side this makes the permission area very simple to drive.
As you can see, the actual number of permissions selectable per group is pretty minimal (though this is just the forum module, you can see the other tabs), but because we already saw the fiddly stuff managed in a board's own configuration (including 'see own topics' vs 'see all topics'), we're left with a really minimal set of permissions here.
Which brings to mind several questions, really, but actually... that's because I've misdirected you a little.
There is one more area for configuring the rights and privileges of groups - in the groups configuration itself.
There's many more options (for example the classic edit-time restriction is further down the Content tab), which are intentionally framed not as permissions but behavioural modifiers on the group (as opposed to within a given board)
This is really quite interesting - you have the 'group options', 'group permissions across boards', 'group permissions on a board level'. Now, it's true that the group configuration in XF also exposes the default permissions for that group but it's *presented* as permissions and shares the same permissions UI as the main user group permissions UI.
This on the other hand is a radical departure, because there are many things that are *not* framed as permissions even if they are, or they're lumped in with behavioural modifiers that aren't really permissions as such (or they're half way between the two, see edit-time restrictions), but it does mean that you have to think a little about where to go to get what done.
I don't think there's any obvious things that XF or IPS can do that the other can't (or, for the most part, SMF come to that, though SMF's idea of edit time restriction is all non-moderators with a single limit, rather than a per-group rule), but I think there's pros and cons to the way these platforms approach this problem.
I personally prefer XF's take on it, that the group settings are (mostly) for the group display and general behaviour, and that behaviour modifiers are really a subset of permissions, as opposed to IPS's take that behavioural modifiers are a complete sidestep from permissions, but I can see people arguing passionately the other way, especially if you're a fan of IPS in general.
I have always been used to IPB's permission system, coming from InvisionFree. Even ZetaBoards was wildly inspired by IPB's permission system. It's simple, easy to use. But now that I'm used to XF's permissions system, I'd prefer that immediately.
Next up, Woltlab.
Again, I'm not on the latest version but it's reasonably current (end of last year or so) so it's whatever the last major 5.x version is.
Like others, Woltlab puts the base set of permissions for a user group in the user group's own configuration.
And of course we see that board access is implicit in that too.
But the application of permissions to a board is fascinating.
When you first enter a board's permissions page, it's empty.
What it makes you do is pick one or more users and groups to apply permissions to as a modifier on top of their base groups' configuration.
I find this fascinating.
This is also mirrored somewhat in the board access page.
The permissions really do work as grant/deny, such that the left box being ticked is a yes, neither box being ticked is no, and right box being ticked is never. (Interestingly, deny even applies to admins.)
What's not immediately clear about this UI is that it's not as stackable as it appears.
Yes, you can apply permissions to multiple groups in a board at once, but there's no ability to mix and match - I don't see how you can produce the combination such that the default permissions in a board are x, groups a and b have x+y, and group c has x+y+z because the UI doesn't seem set up for that, but in practice you wouldn't *normally* do that in a single board anyway. (At least not on a per-board basis. The more usual scenario of 'guests can see, regulars can post, moderators can moderate' is fully achievable with the basic group permissions without needing to add per-board variations beyond basic visibility exclusions which don't really impact any of this.)
I haven't tested it but I suspect you probably could do it from the user group permissions page (the last screenshot) where you select which permission and grant/deny it for a group, but I haven't tested it.
In practice I always tend to keep my permission set much simpler so for me I don't think this would ever have been a deal breaker.
What I will say is that this feels completely inline with other systems and products I've seen come out of Germany in terms of their approach to the problem. It feels a little fussy and inelegant to me but very solid and robustly built.
Again, I'm not on the latest version but it's reasonably current (end of last year or so) so it's whatever the last major 5.x version is.
Like others, Woltlab puts the base set of permissions for a user group in the user group's own configuration.
And of course we see that board access is implicit in that too.
But the application of permissions to a board is fascinating.
When you first enter a board's permissions page, it's empty.
What it makes you do is pick one or more users and groups to apply permissions to as a modifier on top of their base groups' configuration.
I find this fascinating.
This is also mirrored somewhat in the board access page.
The permissions really do work as grant/deny, such that the left box being ticked is a yes, neither box being ticked is no, and right box being ticked is never. (Interestingly, deny even applies to admins.)
What's not immediately clear about this UI is that it's not as stackable as it appears.
Yes, you can apply permissions to multiple groups in a board at once, but there's no ability to mix and match - I don't see how you can produce the combination such that the default permissions in a board are x, groups a and b have x+y, and group c has x+y+z because the UI doesn't seem set up for that, but in practice you wouldn't *normally* do that in a single board anyway. (At least not on a per-board basis. The more usual scenario of 'guests can see, regulars can post, moderators can moderate' is fully achievable with the basic group permissions without needing to add per-board variations beyond basic visibility exclusions which don't really impact any of this.)
I haven't tested it but I suspect you probably could do it from the user group permissions page (the last screenshot) where you select which permission and grant/deny it for a group, but I haven't tested it.
In practice I always tend to keep my permission set much simpler so for me I don't think this would ever have been a deal breaker.
What I will say is that this feels completely inline with other systems and products I've seen come out of Germany in terms of their approach to the problem. It feels a little fussy and inelegant to me but very solid and robustly built.
Aha, that's a bit how we do it here. A base permission, and work up from there per usergroup... Interesting. Woltlab has been on the rise for a while now, and definitely a worthy competitor to XF and IPS. Even if they say otherwise. Their 3rd party customization isn't like XF yet but already/still better than IPS.
RIGHT THEN.
Time for a blast from the past now. I give you... vBulletin 3. The myth, the legend, the OG.
I'd honestly forgotten how this one worked.
vB3 operates on the classic principle that the general permissions for the group are a function of the group - we've certainly seen this view before.
Of course, 'view the board' is a clear permission here.
And when we go to the main forum permissions area we get something quite interesting to look at.
Immediately we're given an overview of whether a board is special or not - it certainly encourages you to keep your boards following the default permissions profile (which, often, makes a lot of sense: in general you probably don't want that many boards being special)
What's also *really* interesting is that things do actually cascade here. Set a board permission in one board, the children inherit that by default unless you override for that group lower down the tree. I think this is the first time we *actually* see this happening explicitly.
I'm not sure how I feel about the explicit inheritance; it feels at times like this is what XF seemed to mean with its 'inherit'. On the flip side, we don't get Yes/No/Never but setting that up for a particular board is not particularly difficult unless you have a lot of groups and/or a lot of boards where you want this.
This is a particularly interesting conundrum when you stop to think about it: we saw with SMF 2.x that you create profiles and apply them to boards, which lets you keep consistent permission sets across boards, while this approach is much more 'we have the group defaults and apply per-board variations' which is fine if you don't have many boards, or you have several boards that are all unique to each other.
I think here, the difference is probably the *most* pronounced because it's shown up front and very clearly, in a way the others downplay a little.
Time for a blast from the past now. I give you... vBulletin 3. The myth, the legend, the OG.
I'd honestly forgotten how this one worked.
vB3 operates on the classic principle that the general permissions for the group are a function of the group - we've certainly seen this view before.
Of course, 'view the board' is a clear permission here.
And when we go to the main forum permissions area we get something quite interesting to look at.
Immediately we're given an overview of whether a board is special or not - it certainly encourages you to keep your boards following the default permissions profile (which, often, makes a lot of sense: in general you probably don't want that many boards being special)
What's also *really* interesting is that things do actually cascade here. Set a board permission in one board, the children inherit that by default unless you override for that group lower down the tree. I think this is the first time we *actually* see this happening explicitly.
I'm not sure how I feel about the explicit inheritance; it feels at times like this is what XF seemed to mean with its 'inherit'. On the flip side, we don't get Yes/No/Never but setting that up for a particular board is not particularly difficult unless you have a lot of groups and/or a lot of boards where you want this.
This is a particularly interesting conundrum when you stop to think about it: we saw with SMF 2.x that you create profiles and apply them to boards, which lets you keep consistent permission sets across boards, while this approach is much more 'we have the group defaults and apply per-board variations' which is fine if you don't have many boards, or you have several boards that are all unique to each other.
I think here, the difference is probably the *most* pronounced because it's shown up front and very clearly, in a way the others downplay a little.
I never used vB before, but damn that looks so old. It probably even looked old when it was newly released. Idk, I did like some of their 3rd party themes, there has been some great work during the prime days, but I always felt vBulletin looked older than it was.
Nope, when vB 3 came out it was the bomb, and very much in tune with its era. But then again vB 3 is now OLD.
Just checked, 2004. Okay, I was on the internet for a year or two at most then, and don't quite remember how everything looked then. 😂 Only reference I have is phpBB 2.0 and InvisionFree. So yeah, compared to that, I probably agree with what you say. Admittedly, vB3 was out of my experience.
And so while we're on the subject of vBulletin, let's jump forward in time to vB 4.
Same concept this time around, user group general permissions in the user group configuration. Forums get shunted down under blogs if you install the full fat 4.x install (rather than the forum-only 4.x)
The main comment I have about vB 4 is very much in the 'if it ain't broke don't fix it' mindset. It's all a carbon copy in the ACP.
Though I'd possibly note that it's interesting that the CMS module abuses a forum board for its comments. But there's not a fat lot to comment on here that's wildly different.
Same concept this time around, user group general permissions in the user group configuration. Forums get shunted down under blogs if you install the full fat 4.x install (rather than the forum-only 4.x)
The main comment I have about vB 4 is very much in the 'if it ain't broke don't fix it' mindset. It's all a carbon copy in the ACP.
Though I'd possibly note that it's interesting that the CMS module abuses a forum board for its comments. But there's not a fat lot to comment on here that's wildly different.
Log in or register to unlock full forum benefits!
Log in or register to unlock full forum benefits!
Similar threads
Who read this thread
(Total readers: 0)
No registered users viewing this thread.
New Threads
-
Content Creation What's your longest thread you have?- Started by joelr
- Replies: 0
-
-
Admin Well-being Ever Had a Tussle With Your Co-Admin
- Started by Nomad
- Replies: 5
-
Site Management What Kind of Skills Do You Need to Manage a Community
- Started by Nomad
- Replies: 3
-
Welcome to Admin Junkies