XF 2.2 Strange permission problem / behaviour in resource manager

smallwheels

Active member
I do post this in the general support forum b/c it is a permission issue, so it may or may not be related to resource addon.

What is the issue?

A new user could not access a certain resource within a certain category in resource manager. He is - as are almost all others - in the group "registered" with no secondary group. I checked the permissions of the resource category in question and it turned out that I had locked out this user group actively from that category. Adjusted the permissions for the group on this category to "inherit", works, job done.

But here's where my confusion starts: A couple of other users who had the same set of permissions as the user in question and were also members of the group "registered" (and only of that group) were able to see the resource in question and also to post replies to the related discussion thread while he had problems. Should not be the case, I've no explanation for this. But it gets worse:

The general permissions for resources for the group "registered" is set to "yes":
Bildschirmfoto 2024-05-18 um 18.37.16.webp

But when I pick a random user of the group "registered" and check his general permission for resources they are set to "no":
Bildschirmfoto 2024-05-18 um 18.39.10.webp

I've checked this for a sample of about 10 different users that have been registered between today and 1,5 years ago when I started the forum - all the same.

Question 1: How come that the general permission of the primary group a user is in are not applied to that user if he is not part of a secondary group that says differently?

It gets even more confusing: I've been using the resource manager almost since the start of the forum and had no complaints that people could not access it. In opposite: They could and can, they view, add and download resources. The fix for the initial problem for the one user was to apply "inherit" for the resource category in question (which was the case for most other resource categories already). Here's an example resource category:

Bildschirmfoto 2024-05-18 um 18.35.04.webp

Given that the general permissions for the group "registered" is set to "yes" it seems logical that they have access. Given that every individual user has - for unknown reasons - the individual permissions for resources set to "no" they should not have access in my eyes. I am glad that they have - but it seems not logical to me.

Question 2: How can it be that inherit seems to do the opposite of what it is supposed to do on a user level?

If I analyse permissions for a certain user for the resource category they are set to "yes" - as it should be. But why?

Bildschirmfoto 2024-05-18 um 19.13.39.webp

The details only refer to the group "registered", the only one the user is in:
Bildschirmfoto 2024-05-18 um 19.16.32.webp
in comparison: if I do the same analysis for my own user all the user groups I am in are listed:

Bildschirm­foto 2024-05-18 um 19.27.46.webp

But then: Why does he (and all the others) have a "no" when analyzing the general resource permissions for the same user? Where does it come from?

Question 3: How can I find out what causes the individual setting of a certain permission for a certain user? I did certainly not manually edit 100s of users, so there must be a reason. But how do I find it?

Question 4: Can I batch update the permissions for all users of a certain group (so those that are affected here) w/o using the permissions of the group itself? And if to how?

Note: I am aware how permissions in XenForo work: Yes is Yes and overwrites a No that is set for the same permission via another (secondary) user group. No is No if there is no overwrite by a yes. Never ist a hard no and cannot be overwritten but overwrites an existing yes set by another (secondary) group a user may be in.

Just that in my case for most of the users there is no second user group involved at all.

For the record: I am running XF 2.2.15 with RM 2.2.5 and MG 2.2.5 (so the actual stable versions) along with a bunch of other plugins. There have no troubles been reported but I am a little bit in fear that I might have issues like that in other areas of the forum as well w/o knowing it and it is a bad feeling not be able to trust the output of the admin backend. I've absolutely no clue when this behaviour of the permission system did start or if it is limited to RM or not. :(

I barely dare to think of this but could it possibly be that it is a bug in the view so that in the user view of permissions for the area of resources something is wonky and a yes is shown as a no in the backend in that view or something like that?
 
Last edited:
Permissions can also be set at the user level, which works in the same way. The user permissions page only shows permissions set for that specific user. The “user” no (default) is being overridden by the “group” yes.
 
Last edited:
Permissions can also be set at the user level, which works in the same way. The user permissions page only shows permissions set for that specific user. The “user” no (default) is being overridden by the “group” yes.
Thanks, forgot to explicitly mention that. But as this affects possibly a unknown but very huge amount of the users of my forum (possibly hundreds) including one who only registered a couple of days ago (the one who brought the whole thing up) and I am the only active admin on my forum it is impossible that all these users got their permissions set manually one by one.

Also, if permissions are set manually on a per user-basis they show up when analyzing permissions. I did it with a test user to try it out and it looks like this:
Bildschirm­foto 2024-05-18 um 21.17.50.webp

Also, you can find users that do have individual permissions set listed here in ACP:

Bildschirm­foto 2024-05-18 um 21.17.16.webp

The users in question are not listed there, just the few where I know that I set individual permissions (I try to avoid that as it typically causes chaos longterm).

Unfortunately it turned out that the inital problem with not having access to a certain resource category is not solved for all users. One gave me feedback that he still does not have access. He is one of the few having a second user group assigned and this usergroup is set to "no" for resources. But this should be overriden by the general "yes" from his primary usergroup "registered" if I get it correctly - but it is not.

Do not know about the others. My testuser however did not have access as well but has access since doing the change to "inherit" for the resource category as mentioned in my startposting.
 
The user permissions page only shows permissions set for that specific user. The “user” no (default) is being overridden by the “group” yes.
Ok, that's good to know. So no worries regarding what the permission per user shows. Still the question remains why it says yes on group-level , on analyze permissions for ressources in general as well as for the category in questeion - and still does no. :oops:
 
The user is set to never, never always overrides any yes. You need to be careful when editing user level permissions. It can get quite confusing.
 
I'm not sure. Maybe worth noting that if the 'Private category' option is selected, explicit view permissions must be granted on the category level. However the analyzer for that specific category should always show what the actual value is in practice for the given user. If it shows 'Yes' but a user is seeing 'No' (or vice-versa), then something is very wrong.

Might also be worth running the 'Clean up permissions' tool on the 'Rebuild caches' page.
 
The user is set to never, never always overrides any yes.

He is. And I know, as I wrote in the start posting of the thread. It is a testuser and the setting was made to check if individually set permissions show up in the permission analysis and they do. If it makes you sleep better: Permissions for this test user have been set back to normal state directly after the check. ;)

You need to be careful when editing user level permissions.
I do not do that normally. Guess why I wrote earlier in this thread:

(I try to avoid that as it typically causes chaos longterm).
 
Back
Top Bottom