XF 1.5 "Please select a prefix" Error

[byte]

I've only dealt so far with the front-end of XF for our company's project, but due to some recent internal changes I've been forced to play around more in the ACP. Everything is very straight forward and pretty easy to understand and navigate, however I am having the toughest time understanding how permissions work, and simply put, the logic behind how they function. I've read these resources, but still cannot figure out why some things are acting like the way they are.

Right now I've set my username to that of the Administrative level, and for secondary groups I have Moderating and Registered checked. We don't use any other sort of special user groups / classes. I've also set the Administrative user group to explicitly allow everything (checked the green "check all").

Now the problem I'm experiencing is when I created a node, I created prefixes and enabled the "Require users to select a prefix" which states below it that it does not apply to moderators. However when I'm logged in as my user who has been set to the Administrative user group with everything set to allow and with the Moderating set as the secondary group, when I attempt to post a thread within that node without a prefix it says "Please select a prefix". Why is that? Also, how can I make it possible to post in this forum as an Administrator and not have to specify a prefix?

Bonus question: Is there some way to make a user class (e.g. Administrator) have full rights to do anything and everything so I don't get random "insufficient privileges" on some things? I understand the risks in this, but for a strictly internal project on an internal network such as ours it would be very helpful. Also I don't see how it would be any different than a root account for a Linux server.

Thanks in advance!

 

[Mr Lucky]

I've set my username to that of the Administrative level, and for secondary groups I have Moderating and Registered checked.

This seems wrong

You don't need registered as a secondary group because it should be the primary group for all users.

If you haven't done that, it could explain all your issues.

 

[byte]

This seems wrong

You don't need registered as a secondary group because it should be the primary group for all users.

If you haven't done that, it could explain all your issues.

I would think so too, but upon the creation of a XenForo forum, the default Administrator account has their group set to "Registered" and the secondary groups that are enabled are "Administrative" and "Moderating". Speaking of which, is rather odd considering it's the Administrator account.

Either way I unchecked "Registered" as a secondary group but still getting the same error with the prefix.

 

[Mr Lucky]

This is my point, what you have there is wrong.

The usergroup (primary) should be Registered, not Admistrative.

Somewhere this is all explained very well, I'll try to find it for you.

 

[Mr Lucky]

Somewhere this is all explained very well, I'll try to find it for you.

Here:

https://xenforo.com/help/permissions/

and

https://xenforo.com/community/resources/implementing-permissions-across-multiple-user-groups.358/

 

[byte]

This is my point, what you have there is wrong.

The usergroup (primary) should be Registered, not Admistrative.

Somewhere this is all explained very well, I'll try to find it for you.

I changed it to the following and still getting the same error. So is something wrong with my below configuration?

Also I appreciate the links but I've already referred to the ones mentioned in the original post.

 

[Mr Lucky]

So is something wrong with my below configuration?

No, provided you have reset the permissions as you want. But be aware that being in the moderating or administrative usergroup doesn't automatically make that user a moderator or administrator. For that they need to be selected as such under the User menu

 

[byte]

No, provided you have reset the permissions as you want. But be aware that being in the moderating or administrative usergroup doesn't automatically make that user a moderator or administrator. For that they need to be selected as such under the User menu

I appreciate your help, but I guess I'm a little confused. How do I go about being able to post threads without prefixes as an Admin, in forums where I have prefixes required.

 

[Mike]

The wording of that is a little misleading, but it's refers to not applying to moderator actions. Moving being a prime example, though a moderator could actually edit the thread and remove the prefix as well (and there are other moderator actions that it doesn't apply to). It applies to all users when creating a thread without exception. I can't say I recall a requirement of admins/moderators being able to bypass a requirement while creating a thread. What's the use case?

Bonus question: Is there some way to make a user class (e.g. Administrator) have full rights to do anything and everything so I don't get random "insufficient privileges" on some things? I understand the risks in this, but for a strictly internal project on an internal network such as ours it would be very helpful. Also I don't see how it would be any different than a root account for a Linux server.

Administrators and moderators are separate and distinct roles, though a user can have both. You can confirm the permissions for these roles in the administrator and moderator sections within the admin control panel.

If everything is checked there, you generally shouldn't be getting permission errors, but if you can be specific about the error message and what you're doing, we may be able to give more details.

 

[byte]

The wording of that is a little misleading, but it's refers to not applying to moderator actions. Moving being a prime example, though a moderator could actually edit the thread and remove the prefix as well (and there are other moderator actions that it doesn't apply to). It applies to all users when creating a thread without exception. I can't say I recall a requirement of admins/moderators being able to bypass a requirement while creating a thread. What's the use case?


Administrators and moderators are separate and distinct roles, though a user can have both. You can confirm the permissions for these roles in the administrator and moderator sections within the admin control panel.

If everything is checked there, you generally shouldn't be getting permission errors, but if you can be specific about the error message and what you're doing, we may be able to give more details.

Hey thanks for the reply. The use case I'll admit is a rare one, but in this particular instance I needed to add a couple stickies to a forum where the required prefix option was in place. If you're saying it's simply not possible, then I can understand that and I can just go disable that, create the sticky threads, and then re-enable it (can you confirm that's the only way currently?). It's just as I mentioned in the OP, the logic of the permissions confuse me. I would expect that the user group Administrator, who I've set all permissions to green/yes/allow, would be able to override anything. So again it's not a big deal if it's not possible, I just wanted to make sure that I wasn't missing something and not comprehending the logic of permissions.

Regarding additional permission errors, a particular incident would be when I'm trying to create an "Announcements" forum and only want Administrators to be able to post there. Even though the user is an Administrator, it still says insufficient privileges. I read this (#14) which tells you exactly how to do it, but the method described doesn't quite make sense to me that you have to not only "deny" the user group to be able to post a thread, but then you have to go and "allow" the Administrator group to be able to post a thread. Again, a user group of Administrator with all privileges enabled shouldn't have to be explicitly "allowed" to post a thread - they should just be able to. Either the logic isn't there, or using terms like Administrator or Moderator are misleading because they don't function as a user would think and are used to across other platforms, software, OS', and pretty much everything else.

The main thing in all this, is I just want to understand I'm not using the permission incorrectly and these "set permissions here, and set other ones here, and set other ones here" is how it is supposed to be. Thanks!

 

[TPerry]

I would think so too, but upon the creation of a XenForo forum, the default Administrator account has their group set to "Registered" and the secondary groups that are enabled are "Administrative" and "Moderating". Speaking of which, is rather odd considering it's the Administrator account.

Common misunderstanding... the Administrator user group is more for styling and then specific node permissions. The actual authority is set when you use the ACP to configure the user(s) as an Administrator



This is where the actual Administrator is set at - along with the Super Admin's via the config.php.
By default, all users should have a base of Registered as their default user group. If (for styling) you need the administrator group to have higher priority, just set it that way, using a higher number than the others.

 

[Mike]

If you're saying it's simply not possible, then I can understand that and I can just go disable that, create the sticky threads, and then re-enable it (can you confirm that's the only way currently?).

Given your use case, that's probably simplest, though there are a couple other approaches that could be taken. (Moving the thread into the forum, or editing the thread to remove the prefix later.)

I read this (#14) which tells you exactly how to do it, but the method described doesn't quite make sense to me that you have to not only "deny" the user group to be able to post a thread, but then you have to go and "allow" the Administrator group to be able to post a thread.

It sounds to me like you've used "never", which is explicitly something that can never be overridden. It's the highest priority permission. It has its uses, but should only be used sparingly because of this. The "revoke" term used in the FAQ is the specific permission choice you'd want to use.

If that still hasn't solved the problem, you'll want to use the permission analyzer on the node in question. That should check what the final permission is coming out as and why. If that says yes, then it'd be worth double checking the forum configuration to confirm that posting is allowed in the forum.

Note that there is no concept of anyone bypassing their permissions. Administrators and moderators always have whatever permissions are assigned to them using the standard permission priority rules. Our recommended approach is to put everyone in the Registered group as their primary group and then add additional groups to give additional permissions. You don't strictly have to follow this. For example, if you didn't put this admin user in the Registered group, then they wouldn't be affected by the permission revocation. However, all programmatic group changes will add additional secondary groups, so we generally recommend using an "additive" approach everywhere.

 

[byte]

It sounds to me like you've used "never", which is explicitly something that can never be overridden. It's the highest priority permission. It has its uses, but should only be used sparingly because of this. The "revoke" term used in the FAQ is the specific permission choice you'd want to use.

I'm not quite sure what you mean here. So long as I follow how it's stated to do so in the FAQ that I linked, it works. I don't have "never" set anywhere just for the reason that the FAQs mention to avoid this. I was referring to the fact that I don't understand why an Administrator would need to be explicitly "allowed" to post something.

So just to make sure we're on the same page:

• The Administrative group (which my user is a part of, as well the account is also the Super Administrator) is set to "Allow All" across the board.
• The "Announcements" node only has a single permission modified, which is to revoke the "Post new thread" ability for Registered users.
• The Super Administrator (me) has their user group set to "Registered", and the Secondary User Groups are "Administrative" and "Moderating".
• No other permission have been modified.

Given the above scenario, it doesn't make sense to me why I still must manually go into the permissions of the Announcements node and "allow" the Administrator group to "Post new thread".

If that still hasn't solved the problem, you'll want to use the permission analyzer on the node in question. That should check what the final permission is coming out as and why. If that says yes, then it'd be worth double checking the forum configuration to confirm that posting is allowed in the forum.

The permission analyzer is a very helpful tool which I wasn't aware of, so thanks for mentioning that. What I did was take the exact scenario above and did an analysis on it using the Announcements node and the aforementioned Super Admin account, however I didn't explicitly allow the Administrator group to be able to "Post new thread". Here is the result. Again I can't quite understand the logic if I've set up the Administrator Group to do absolutely everything possible, not to mention the account in question is the Super Admin, and it's still saying it's not allowed.

However, all programmatic group changes will add additional secondary groups, so we generally recommend using an "additive" approach everywhere.

This may be why I just haven't been following or understanding how this system works. This approach is the complete opposite of every system that I've ever worked with. I don't know of any other platforms that start users the same as all other users, and then you add permissions as you go along. With other platforms and software, again it's the opposite - an initial admin or root user is created, "one user to rule them all" so to speak, and from there you create additional users with less and less privileges to build out user groups. Even though I don't quite understand why there is this "additive" approach, I appreciate you wording it like that. I think I have indeed understood the logic this whole time, but I just assumed I didn't because I wasn't aware of another platform that operates in this way.

 

[TPerry]

This may be why I just haven't been following or understanding how this system works. This approach is the complete opposite of every system that I've ever worked with. I don't know of any other platforms that start users the same as all other users, and then you add permissions as you go along.

And that's why it takes some people a while to get acquainted with it. It IS different than how others work, but once you get acclimated to it you find it's typically much more granular and powerful.

 

[Mike]

Given the above scenario, it doesn't make sense to me why I still must manually go into the permissions of the Announcements node and "allow" the Administrator group to "Post new thread".

When it comes to permissions, there aren't any "special" groups that affect the calculations. So in this regard, the Administrative group is no different than the basic Registered group.

So in this situation, the permissions you set within a particular node have priority over any global permissions. Ignoring the admin situation here, but if it didn't do this, you wouldn't be able to remove permission for registered users to post in this forum.

Since you've revoked posting permissions for registered users and the admin user in question is in the registered group, they won't have permission. This is what the permission analysis is showing. When you re-add permissions for the admin group, the node-specific allow overrides the node-specific revoke.

This approach is the complete opposite of every system that I've ever worked with. I don't know of any other platforms that start users the same as all other users, and then you add permissions as you go along. With other platforms and software, again it's the opposite - an initial admin or root user is created, "one user to rule them all" so to speak, and from there you create additional users with less and less privileges to build out user groups. Even though I don't quite understand why there is this "additive" approach, I appreciate you wording it like that.

The approach is basically what would be called "role based access control". A user can have many roles and thus there are potentially a significant number of permutations that could exist, depending on your requirements and configuration. In various situations, it becomes essentially impossible to define a system where a user can only exist in one role. (For example, if you have 3 user upgrades that can be purchased independently, there are 6 permutations of what someone can purchase.)

With the additive role based system, each role only needs to define the permissions that are specific to it (those that are unique). There shouldn't be much overlap in permissions between roles. In this case, the admin's ability to post in a particular forum is a unique part of that role and thus needs to be specified (given that you've removed permission for all registered users).

 

[byte]

@Mike Thanks for all your helpful insight on this. I believe I was just looking at all this the wrong way. You have provided a lot of clarity though, so again, I appreciate it!