XF 1.1 Suggestion/best practice for default 'registered' permissions?

flynnibus

Member
I'm tuning my site after upgrading from an older vb site and finding setting the forum permissions a bit cumbersome.

Generally our forum is 'all forums have posting access.. except a handful which are limited access' - nothing shocking.

But I started with 'registered' user group having permissions to post in the user groups, and then having secondary user groups with basically just 'no' in the user group definitions as the user group is just a container and doesn't grant new universal permissions.

But when setting up the forum permissions.. I'm finding I'm having to go into every user group and do 'revoke' for all the user groups in the special groups. This seems like the longer way.. as there are more groups without permissions than with.

Do people find it easier to go go in and add the posting right on a forum basis (user group doesn't have the posting right) or revoke it on every group (user group has the posting right)?

Obviously this weighs on what ratio of forums you have open vs closed.. but curious what others have done as a best practice?

Marking the forum private helps somewhat but its still hard to see things clearly.

I think I'm going to tag my user groups as permissions vs membership groups to help make things easier to see.
 

While that's a nice intro - it doesn't really address the topic which is the best way to structure permissions to make node permissions optimal. The article is about 'all users' and doesn't address the practicality where permissions are not uniform across the site.

Since nodes set to inherit from the parent node, and then form the user group if no parent. So if I leave nodes as inherit, the 'registered' users rights will apply to all nodes. But when I want to exclude a permission for all users but a subset.. I now must go and explictly revoke those registered user permissions.

The documentation is also a bit ambiguous as it relates to the Private forum function. It says basically you must give explict permissions when set private.. ok. But it was confusing if administrators/moderators needed to have explict permissions added back in as well.

What I have done now is break user groups into two different types..
[forum] and [permissions] - the first is intended to be containers to be applied at the node level so they don't actually grant any rights.. and the latter is where any baseline permissions are applied. To keep things managable, it was important to make sure the # of groups that actually grant any sort of posting/viewing permissions to be limited. So when I need to manipulate at the node level.. the # of groups that needed modification (revoke) would be very limited.

So my choice was 'grant universal' and then then pinpoint revoke. I was wondering if others have found the other way to be better... if it is possible or make sense to not give 'registered' those rights and try to grant them at a node level instead of revoking.

Restricting which user groups actually grant any permissions seemed to be the key for me..
 
I have a sneaking suspicion that you are trying to force another format of permissions to fit the ones for xenForo.
The main process involves giving your normal registered user account the minimum necessary - and then explicitly granting additional permissions to other groups (and by definition to restricted nodes/forums for those additional groups - a flow chart came in handy for me).
A classic example is my users have read/write permissions to most areas. They can't use a signature until they have at least 20 posts and the promotion system has run. Additionally I have 2 areas that are specific to the Blue Knights and the Red Knights that nobody can see unless they are a member of THAT user group or a moderator/administrator (done by that nodes special permissions - revoke the members - grant the special groups). Took about 3 minutes to configure it and make the user groups.
The permission system in xenForo was designed to be granular from what I can see. Easiest thing I found was to throw out all thoughts of how other software did it and concentrate on the theory that was designed into this software. Once I did that it started making sense and was much easier to use.
 
I could care less about other formats- I'm trying to establish a method that minimizes risk for errors while minimizes how many groups need editing for each node

That means minimizing where permissions must be modified for each node - less changes equals less chance for errors.

The more user groups you have and the amount of work can explode.

The least groups that have permissions at the user group level... The least I have to revoke at the node level. I found that to mean keeping all view/post permissions out of all user group permissions except for the 'registered' group. Then there is less chance of missing any when doing node permissions. I grant the view/post at the nodes... And only have to revoke from one group
 
Sounds like you are doing it the hard way - but more power to you. I think we may be talking at cross purposes here. If you are controlling every node by including the group in there then, it appears to me, that you are doing more work than necessary. I know that the way @Brogan related is the easiest way to do it. Hopefully you will find your ideal way to it in the manner you want. I do think you will eventually find that his way is a good starting point to work from, by using the groups primarily and then specifically allow access to private nodes for certain groups.
 
If I'm reading it right, most of your forums are accessible to all and a few forums are accessible to just some?

If this is the case, then the easiest solution is this:

Group permissions
Registered - set these with the minimum permissions on your forum
Other groups - set these with any additional permissions that Registered don't have

All users to have Registered as their primary group, the other groups are secondary ones added to those you wish to give additional permissions.

Forum permissions
Forums accessible to all - set all permissions to inherit
Forums accessible to some - set these as private nodes and set the "View Node" permission to "Allow" for the groups that you want to view these nodes

With this set-up, all Registered users will access most of the forums. Any users you had a secondary group to that has the "View Node" permission to "Allow" for the private forums will be able to see these, the rest won't.
 
Sounds like you are doing it the hard way - but more power to you. I think we may be talking at cross purposes here. If you are controlling every node by including the group in there then, it appears to me, that you are doing more work than necessary. I know that the way @Brogan related is the easiest way to do it. Hopefully you will find your ideal way to it in the manner you want. I do think you will eventually find that his way is a good starting point to work from, by using the groups primarily and then specifically allow access to private nodes for certain groups.

Brogan's outline doesn't address nodes at all... so how you say this is the 'easiest way' I have no idea. He doesn't address the topic of per node variations at all. I don't think you even understand the problem being put forward.

And what way is 'easier' depends on which you have more of... more user groups.. or more nodes with variations. If I only have a few groups.. its easiest (by definition of less clicks) to simply revoke based on the user group at each node. But if I have a lot of user groups.. that means in each node that varies from the baseline permissions the permissions must be revoked in each user group where the permission is granted

The last fragment there is the key -- the key is to reduce the # of permissions granted across the board.. aka the permissions in the user groups.

Lets say I have three user groups. Registered, Veteran, and Elite

If in all three user groups, someone defines the permission for 'post new thread' to be 'allow'
Then anytime I have a node that I do not want users to post new threads in, I need to explicitly 'revoke' that permission in three user groups. Having to do it in multiple groups makes it error prone to miss one.. especially as the # of user groups goes up.

The key to avoiding this problem is where all possible.. avoid duplicating a permission in secondary user groups. In this scenario, do not grant 'post new thread' to any group but Registered. This is mentioned in Brogan's article, but is not emphasized as key to reducing workload.

So that minimizes the # of user groups in a node I should be touching... but should I be granting the permission in the user group or node? This depends on what are you doing more of... granting or revoking? If you find yourself revoking everywhere, flip the permissions and don't grant them at the user group level and instead grant them to the specific groups at the node level.

I helped myself further in this by labeling user groups as permission groups or membership groups. 'Registered', 'Unregistered', 'Banned', etc would be examples of permission groups. 'Teen Club' or 'Photogs' would be examples of simple 'membership groups'. Membership groups are set to 'no' for everything in the user group - they grant no permissions universally. Their purpose is only a container for when applying permissions at the node. Hence, they are completely inert in the majority of nodes.

And example grant/revoke quandry is 'bad user' group or something. 'bad users' can only post in one or two nodes. If you make the group a secondary group... I now need to go and revoke posting permissions for that group in all my nodes where they can't post or at least the parent nodes where the child tree is uniform. The alternative would be to create another primary group for 'bad users' and do not give him any posting permissions in the user group.. and instead only grant the group posting permissions via the node permissions. Here, I only selectively grant, instead of having to revoke everywhere. I can't use revoke at the user group level because then they couldn't post anywhere.

What I found in my site after the import was... too many groups with the same permissions. This lead to a lot of work when working at the nodes. They key was stripping as much out of the user groups as possible to reduce overlap between groups.. and labeling groups better (I used prefixes) so when viewing nodes.. it was easier to validate that user groups I was EXPECTING to have customized permissions actually as being marked as customized. It provided a easy validation.

The summary and copying of permissions is an area xenforo is very basic at this point.
 
Top Bottom