Lack of interest Improve Permissions System

[Kirby]

As it is right now, it is for example possible to give Registered Users the permission to edit their own posts and revoke that permission on node level.
It is however not possible to allow Registered users to have a high time limit on editing posts and to lower that on node level:
https://xenforo.com/community/threads/node-based-integer-permission-does-not-become-active.153148/

It is also not possible to setup Registered users to never be able to edit their own posts except on specifically configured nodes.

This seems inconsistent to me and makes permission configuration more complicated (and thus error-prone) than it needs to be:

Assuming that there is one forum (Forum 1) on level 1 (eg. a direct child of a root category ), in order to set a lower limit for this forum it is necessary to

1. Set Registered to have a limit of zero
2. Configure Registered to Unlimited on every top-level node except the one which contains the child-node that should have a lower limit
3. Configure Registered on every sibling of the "Low Limit" node to unlimited
4. Configure Registered on Forum 1 to the required value, for example 30 minutes

I therefore like to suggest the following changes:

1. Integer permissions should not unconditionally take the highest value, instead the value should be calculated for every single group:
   If it is inherited on a node take the inherited value, if a specific value is set take this one.
   Afterwards, take the highest value from all calculated group values the user belongs to.
2. Never should take usergroup into account
   If a permission is customized (eg. it is not inherited) the customized value should be used
   Example
   Registered - Can Edit own Posts = Never
   Group A - Can Edit own Posts = Yes
   
   User belongs only to Groups Registered and Group A
   
   Can Edit own Posts = Yes is set for Registered on a Node
   => Final Result should be Yes on this node
   
   Can Edit own Posts = Inherit is set for Registered on a Node
   => Final Result should be No on this node, regardless of how Can edit own Posts is set for Group A

With these changes in place, it would be possible to just Configure Registered on Forum 1 and set the limit to 30 minutes.

 

[MaGeFH]

I really would recommend to implement this. Xenforo's permission system is in a really good spot. It does a lot of thing very well, but this is a spot where it needs a bit of help.

Right now there are some rather simple examples that are very hard (or even impossible) to setup with the way the permission system works.
To illustrate this, here is an example:

You want to limit the time your users are allowed to edit their own posts in a specific sub-forum, but allow a more relaxed time frame on the parent forum.

No matter how you set this up, the more relaxed edit timeframe of the parent forum (or the general edit timeframe permission) will always be considered when the software will determine how large the time edit window will be. And the larger one will always win.

Now, if this change is applied to Xenforo you need to consider what would happen to existing permission setups:
As this change would result in equal or lower numbers on the effective permissions than before, the only thing that could happen is that some users suddenly face more restrictive rulesets than before, but only if the admin set up the permissions in a way that reflects his intent to reduce the permissions for these users on these nodes.

This is the most important thing here, I think: Intent

If I set up a specific sub-forum with more restrictive rules, I explicitly state my intent to the system that for this node and this usergroup/user, I want this restriction to be in effect. This is intuitive, and that's important. Permission management is no simple task and it really needs to be as intuitive and intent-driven as possible.

Personal Footnote: We host and manage nearly 75 forums with our team, and I know for sure that our community managers would benefit from any streamlining that could be applied to the permission system.

 

[nocte]

Never should take usergroup into account

For a beginner it's even now not easy to fully understand the permission system. So if a "never" would not be a "never" anymore, it would be even harder.

Also this might break current permission setups.

 

[Kirby]

For a beginner it's even now not easy to fully understand the permission system. So if a "never" would not be a "never" anymore, it would be even harder.

You got a point there, yes. However I think it isn't any harder to understand why a Yes for a usergroup on a node is not Yes if there is only that one group invloved - if I set Yes I really want Yes (even if I had globally set Never).
So the current GUI is confusing, it does show settings which will can't ever take effect.

Also this might break current permission setups.

Not really. There might currently be permission settings which are not effective because Never overwrites them.
But the upgrade process could take care of this and give the user the option to either remove that setting (which keeps the previous behaviour) or to keep it (which enables it to become active).

 

[Vekseid]

I'd love to see SMF's group inheritance, personally.