As designed `user_state` other than `valid` ignores node permissions

[Hardcore]

I have a node with several child nodes that have various permissions based on secondary user groups. This morning I was doing some testing a noticed that any `user_state` other than `valid` will ignore any node permissions that I've set. And if I set the user_state back to valid they're applied.

I'm running 1.5.2. Thanks.

 

[Chris D]

This might be expected. Can you expand the scenario slightly? Which user_state have you tested with? Can you give an example of some permissions that aren't applying and what is happening and what do you expect to happen?

 

[Xon]

What you should be seeing is the XenForo_Visitor object has guest permissions.

 

[Hardcore]

This might be expected. Can you expand the scenario slightly? Which user_state have you tested with? Can you give an example of some permissions that aren't applying and what is happening and what do you expect to happen?

Sure.

• Parent node is viewable by all.
• Child node is not viewable by all.
• Child node is viewable only if they're in secondary group A.
• Child node is not viewable if they get dropped into secondary group B; as a moderation action.
• If the user_state is anything other than valid, they can view the child node; even if they're in secondary group B.

I expect the user_state to not ignore node permissions for users who are logged in; regardless of the user_state.

Thanks.

 

[Chris D]

I still believe this to be a configuration issue with the permissions. As Xon rightly says, an invalid user will actually receive the permissions of a guest user, regardless of group membership.

If guests are allowed to view that node then so will an invalid user.

But also, it's not totally clear the exact way you have configured this. Is Child node a private node? What permission (e.g. View node) and their values (e.g. Inherit, Allow, Revoke, Never, etc.) are given to group A and group B?

 

[Hardcore]

I still believe this to be a configuration issue with the permissions. As Xon rightly says, an invalid user will actually receive the permissions of a guest user, regardless of group membership.

That's odd to treat a logged in user (who say just changed their email) as a guest and essentially bypass permissions.

But also, it's not totally clear the exact way you have configured this. Is Child node a private node? What permission (e.g. View node) and their values (e.g. Inherit, Allow, Revoke, Never, etc.) are given to group A and group B?

It's not a private node. It's viewable to guests for SEO purposes, but essentially closed for logged in users who have yet to join the secondary group. For view node: Group A is inherit view and Group B is set to never.

Anyway. If it's working by design, that's fine. I can adjust things. But this is my official request to reconsider the design if so.

Thanks for the help.

 

[Paul B]

I don't believe I've ever heard of a node being visible to guests but inaccessible to logged in members.

What is the purpose? They can just use an incognito window to view it.

 

[Chris D]

That's odd to treat a logged in user (who say just changed their email) as a guest and essentially bypass permissions.

It's a perfectly reasonable way to treat an invalid user. An invalid user may not have confirmed their email address yet (could be a new or existing user who has changed their email), or their email might be bouncing or they might be in a moderated state - these are all good reasons to treat forum access a bit different. The usual idea behind revoking permissions back to the guest level is because it is often expected that guests will have less permissions than established users. You are doing something which is opposite, and rather unexpected (and a somewhat rare use case). It's actually borderline against Google's terms, too, though I appreciate it's unlikely they'd ever discover it.

A more common use case would be allowing all members including guests to view the content, but not allowing people to participate until they are in the group that allows them to do so. If you want to hinder the group from viewing the content, well, you're not, because they can just open an Incognito browser window and view it as a guest anyway. If it's only about preventing them from participating, well, view permissions aren't involved there.

But this is my official request to reconsider the design if so.

This is almost certainly very unlikely to be considered, ever, unfortunately.

 

[Hardcore]

@Brogan @Chris D Thanks for the input and clarification. I'll adjust things.