Design issue  "Test permissions" does not apply to Style Chooser

Zak Smith

Member
I have three styles,

1. the "Default Style"
2. TBAC1 (the production one) - set as default
3. - child of TBAC1, for testing only

#1 and #3 have "Allow user selection" unchecked.

From the Admin control panel, if I use Test Permissions on a normal user (ie, a dummy user "John Smith"), the style chooser shows up at the bottom of the page and I can pick any of the 3 styles #1, #2, or #3.

If I log completely out and log in as the test user John Smith, the style chooser link is gone from the bottom of the page and I'm (correctly) stuck on style #2.
 
Style selection is not based on permissions, but is an option: Appearance -> Styles -> click the name of the style. You can select to allow the style to be user selectable or not. Even though you are testing a users permission set, you are still the administrator so all styles will be available to you.
 
That's an interesting interpretation of the concept of user permissions. There is an option that is shown to certain classes of users but not shown to other classes of users. Thus, it is an implicit attribute, or "permission", of the user classes -- whether or not it is considered by the current implementation to be a "permission" of the class (or a special case, or an accident). There is a feature described as showing the forum as if the permissions of the selected user were active.

http://xenforo.com/help/permissions/
You enter a user’s name and you will be shown the forum as if you applied the user’s permission to yourself.

This is either a bug in the implementation or it is a documentation bug.

I have posted, fixed/closed, and read thousands of bug reports in my professional life. The argument that the behavior is correct because the code does it that way doesn't hold a lot of weight.
 
The documentation is correct as you are viewing the forum with the users permissions.
That statement is false.

The user does not have permission to view/change styles because only one style has "Allow user selection" checked.

The admin class of users does have permission to select styles with that option selected.

QED.

Whether or not the permission the admin class has is implcit, explicit, programmed, by accident, or otherwise, is not relevant to the bug report.

The documentation does not use a "term of art" such as "User Group Permissions" as you have in your post just now.

I don't really care about the feature; however, it does not work in the documented and expected manner. To claim that it is not a bug and that it works in a rational manner is laughable. Take a step back from the myopic view of how the code is implemented and various concepts of permission are carved out. It is not rational behavior that tracks the documentation or what one would intuitively expect the feature to do based on its description.

Are you an official representative of XenForo Ltd? I would like to know if blowing off rational discussion of what the behavior ought to be by describing what is implemented is policy or accident.
 
Zak, one of the lines you quoted from the documentation is important:
You enter a user’s name and you will be shown the forum as if you applied the user’s permission to yourself.
You get the permissions (from user group permissions, node permissions, etc - the only things we refer to as permissions) that are assigned to that user, but they are applied to your user. The term "permission" has a specific meaning in XenForo.

Style change limitations are not part of the permission system, and thus are not affected by testing permissions. This falls under this part (from the test permissions page):
Note that account changes such as bans will not be reflected by this system.
 
Style change limitations are not part of the permission system, and thus are not affected by testing permissions.
Take a step back from the myopic view of how the code is implemented and various concepts of permission are carved out
Thus, it is an implicit attribute, or "permission", of the user classes -- whether or not it is considered by the current implementation to be a "permission" of the class (or a special case, or an accident)

That a non-unified conception of user permissions has lead to code that does not operate in a consistent manner in this case does not justify the behavior. Every bug has an explanation, that's not what bug reports are about (ie, what the behavior is vs what it ought to be).
 
Then this has to be considered an issue with the design, and only a fairly fundamental change could resolve it. I think that if we did extend this to further user states (admin, mod, banned, etc) people would run into other things that they didn't expect and we'd end up with the same confusion manifesting itself differently.
 
i'm using several test accounts to make an real permissions check.
There are some scenarios, where it doesn't make sense to use the xenforo permissions check feature (because some addons have a real strange permission system.. :( by userid, by groupid, etc...). To be able to test permissions really fast, i coded the quick account switch add-on
 
Top Bottom