Lack of interest User Group Permissions should select or show Inherited User Groups

[NealC]

We have to assume that "Registered" is the permission base for inheritance. But when you start adding user groups and you want a ladder of inherited permissions the system is a little short of what I think it could be to really do this right. For example if I create a new user group I should select a user group (or groups) that permissions are inherited from. I know in past products such as vB we selected a permissions to be based on as a start. In XF it's about inheritance. But I cannot designate or visualize what user groups I'm inheriting from as there is no visible or sortable hierarchy to show who is inheriting from who.

I would also like to see a permissions chart so I can view all of the user groups such as across the top row, permissions down left column and X's to show what is ON for that user group.

 

[Kirby]

That post confuses me ...

There is no "ineritance" of permissions between different user groups?

Basically, every user is "Registered" and all other groups only touch the permissions they need to modify, egl. leave everything at no except the permissions that this group should have (or should never have) additional to "Registered"

 

[NealC]

Okay, got it. Registered is the only inherited user group permission set.

User groups | Manual | XenForo

End-user documentation for XenForo

xenforo.com

 

[Kirby]

Jep. Don't try to design/think of permissions like you did in vBulletin, this won't work well and most likely would create complicated, redundant permissions that are hard to understand.

Threrfore I always recommend to throw away all additional permissions after an import and start over clean.

 

[NealC]

Why when I go to the Moderating user group does it not show "Inherit" as an option but instead just yes / no / never options? It's inheriting from Registered is it not?

 

[Kirby]

User groups themselves are never "inheriting" anything from anywhere.

Node permissions are inherited though (from parent nodes).

 

[NealC]

Ahh, I was going to ask why I see inherit in some places and not others. I still think user groups "inherit" from Registered from what I understand but it is what it is...

 

[Kirby]

Well, I don't know what else I should say but usergroups do not inherit permissions form other usergroups

Imagine (or try) you've set Bookmark Permissions - Create Bookmarks to No for a usergroup "No Bookmarks" but have it enabled for "Registered".
Now create 2 users - one with primary = Registered and no Secondary, one with Primary = No Bookmarks and no Secondary.

=> The second user won't be able to create bookmarks, the usergroup "No Bookmarks" has set the permission to No and does not automagically inherit a different value from "Registered".

 

[NealC]

Well, I don't know what else I should say but usergroups do not inherit permissions form other usergroups

Let me explain my theory. I realize in the vB days you could apply a user group's permissions towards a new user group you're creating. That was a copy operation. In XF I believe all user groups inherit from Registered. Take for example you have a setting "Foo" that is YES in the Registered user group. You create a new user group "Test Group" and the FOO setting is set to NO. Will FOO be honored as a YES or NO value? I believe it is a YES value as that's what the Registered user group is set to. Now change Registered "FOO" to NO and it will now be a NO for "Test Group" users. The point is that changes in Registered do change other user groups for those settings therefore they are inheriting Registered as there baseline.

 

[Paul B]

The point is that changes in Registered do change other user groups for those settings therefore they are inheriting Registered as there baseline.

This is incorrect.

Permissions don't inherit between user groups.

Permissions are cumulative based on user groups, nodes, and member specific permissions.

 

[Kirby]

Will FOO be honored as a YES or NO value?

Users in Registered would have Yes, users in Test Group No.
However users that are members of both groups would have Yes as they get Yes from Registered, No from Test Group.
When this is calculated the Result is the addition of set permissions from all groups, eg. Yes takes precedence over No and Never over Yes and No.

Now change Registered "FOO" to NO and it will now be a NO for "Test Group" users.

It would still be No as it was before; changes in one usergroup do not affect other usergroups.

The point is that changes in Registered do change other user groups for those settings therefore they are inheriting Registered as there baseline.

They do not.

 

[NealC]

Okay, I've got it now. The key here is primary usergroup is registered for everyone validated so that's the baseline then the accumulation between it and the secondary user group. I missed the point and concept that everyone pretty much remains in the registered user group so that makes the baseline and people that go into higher level user groups are doing so via the secondary user group.

Thanks for helping me digest this. Got it now.

 

[Kirby]

If you follow the recommendations, yes.

However, you could also design your usergroups & permissions with multiple primary usergroups - but I would strongly recommend not to do this.