Private Nodes are viewable by users who have not yet confirmed their e-mail

[XFuser]

Hello,

If a user registers and upon registration is automatically assigned a User Group that gives them permission to view a Private Node, then they are able to view the Private Node before confirming their e-mail.

Users who are not "valid" with a confirmed e-mail should not be considered "full members" and should therefore not be able to view Private Nodes until they confirm their e-mail.

Please fix this issue.

Thank you.

 

[Digital Doctor]

You probably have to set the settings to do what you want.

 

[XFuser]

You probably have to set the settings to do what you want.

What do you mean? We require e-mail confirmation, yet users who haven't confirmed their e-mails are granted viewing permissions (based on a secondary usergroup they are automatically assigned to upon registration) that they shouldn't have until they have confirmed their e-mail. What setting other than "Enable Email Confirmation" are you referring to?

 

[Digital Doctor]

based on a secondary usergroup they are automatically assigned to upon registration)

Change the settings for that secondary user group ?

 

[XFuser]

Change the settings for that secondary user group ?

Change them to what? I want the secondary user group to give the valid users those viewing permissions, but a non-valid user should not be granted those permissions until they confirm their e-mail.

 

[Digital Doctor]

Assign the permissions when they confirm their email ?

 

[XFuser]

Assign the permissions when they confirm their email ?

The permission is assigned automatically when they register. The point is, a member should not be granted any kind of permission from primary or secondary usergroups until they confirm their e-mail whenever e-mail confirmation is enabled. Otherwise, what is the point of e-mail confirmations?

 

[Digital Doctor]

The permission is assigned automatically when they register.

Don't do that ?

 

[XFuser]

Don't do that ?

Not an option, those particular valid members need those permissions granted to them by that secondary usergroup. Why are non-valid users being granted any kind of permission by XF before they confirm their e-mails?

 

[Digital Doctor]

B/c you set it up that way.
This isn't a bug, it's your settings.

 

[XFuser]

B/c you set it up that way.
This isn't a bug, it's your settings.

I think we are discussing two different things. On the one hand, there are the Usergroup Permissions that determine what an entire usergroup can see and/or do. On the other hand, there is the individual User State that determines whether an individual user is valid or not. The individual User State should trump all when e-mail confirmations are enabled. Otherwise, again, what is the point of e-mail confirmations?

In other words, it doesn't matter if a user is a member of every user group, if they are not valid, then they are not valid. Period. Validity is not ambiguous, either a user is valid or they are not. If they are not valid, then they should not be able to do anything on the Forum until they are granted validity.

This seems like common sense, what am I missing?

 

[Jim Boy]

Not a bug - the validate email address stops people from adding content to the site, that's all and that's all it should do

I suggest that if you want to grant permissions only to those that have validated their email, then make the relevant usergroup part of a usergroup promotion that is activated upon a user's state becoming valid. Note that unless you change the cron job timing, it will run hourly.

 

[XFuser]

Not a bug - the validate email address stops people from adding content to the site, that's all and that's all it should do

If that's the case, then the phrasing of "Valid" in the User State should be changed to "Valid E-mail".

I suggest that if you want to grant permissions only to those that have validated their email, then make the relevant usergroup part of a usergroup promotion that is activated upon a user's state becoming valid. Note that unless you change the cron job timing, it will run hourly.

Although I appreciate your solution and agree that it would work, such a convoluted solution to this problem is precisely why the User State of "Valid" should trump all Usergroup Permissions as it's a much easier, elegant, and more intuitive solution.

I've provided an example of why users should not be granted any access by XF until they become valid by confirming their e-mails. For the opposite perspective, could someone please give me an example of why users should be granted any access at all before validating their account when e-mail confirmation is enabled? I'm trying to understand in what kind of scenario that would be useful. Thanks.

 

[Jim Boy]

For the opposite perspective, could someone please give me an example of why users should be granted any access at all before validating their account when e-mail confirmation is enabled? I'm trying to understand in what kind of scenario that would be useful. Thanks.

Being invalid isn't just something that happens at registration, it also happens when people fail to update their email address and they get disabled through email bounce handling, sometimes its just a quirk that causes the user to be invalid. Now if I was running a forum where I was giving out stockmarket tips on a private board - one that the user has paid to get access to, then if they were to suddenly to lose access on the basis of a dodgy email, then they would rightly be peeved.

The only reason why this functionality exists is to try and show that user account is a real person, it's not a permissions tool, XF comes with a permissions system that is powerful and does the job.

 

[XFuser]

Being invalid isn't just something that happens at registration, it also happens when people fail to update their email address and they get disabled through email bounce handling, sometimes its just a quirk that causes the user to be invalid. Now if I was running a forum where I was giving out stockmarket tips on a private board - one that the user has paid to get access to, then if they were to suddenly to lose access on the basis of a dodgy email, then they would rightly be peeved.

Thanks for providing this scenario.

In that case, it really should be renamed to "Valid E-mail" instead of "Valid" as the latter suggests a very different thing to a newcomer to XF, particularly when it falls under the "User State" label. Thanks again.

 

[Jeremy]

Hello,

If a user registers and upon registration is automatically assigned a User Group that gives them permission to view a Private Node, then they are able to view the Private Node before confirming their e-mail.

Users who are not "valid" with a confirmed e-mail should not be considered "full members" and should therefore not be able to view Private Nodes until they confirm their e-mail.

Please fix this issue.

Thank you.

How are you setting this node to private? Did you check the "Private Node" checkbox or did you revoke permissions and have them granted via secondary user groups (without ticking the box?). Are you granting permissions / promotions that can be matched by them before they confirm their account? What do you see by analyzing permissions for an unconfirmed user on the node?

In other words, it doesn't matter if a user is a member of every user group, if they are not valid, then they are not valid. Period. Validity is not ambiguous, either a user is valid or they are not. If they are not valid, then they should not be able to do anything on the Forum until they are granted validity.

This seems like common sense, what am I missing?

Validity is nothing more than a user state, of which you have several related to emails and registering. All validity means is that they confirmed their email (if you require it) or you've manually approved one that was caught by various spam filters to send them to moderation queue. It's also the step before "registration" finishes.

Not a bug - the validate email address stops people from adding content to the site, that's all and that's all it should do

I suggest that if you want to grant permissions only to those that have validated their email, then make the relevant usergroup part of a usergroup promotion that is activated upon a user's state becoming valid. Note that unless you change the cron job timing, it will run hourly.

This is not true. If you allow guest posting, they will be allowed to add content. Access and abilities are controlled by permission, even in this state.

 

[Mike]

A user in a non-valid state always receives the permissions of the unregistered / unconfirmed group. How have you confirmed the issue? Are you running any add-ons ?

 

[XFuser]

How are you setting this node to private? Did you check the "Private Node" checkbox or did you revoke permissions and have them granted via secondary user groups (without ticking the box?). Are you granting permissions / promotions that can be matched by them before they confirm their account? What do you see by analyzing permissions for an unconfirmed user on the node?

I checked the "Private Node" checkbox.

A user in a non-valid state always receives the permissions of the unregistered / unconfirmed group. How have you confirmed the issue? Are you running any add-ons ?

I think I found the problem, then. These particular users, despite not having confirmed their e-mails yet and therefore not being "Valid" yet, are in the "Registered" primary usergroup instead of the "Unregistered / Unconfirmed" usergroup. So that must mean that the bug is with the add-on we are using. That add-on is incorrectly assigning those new users the "Registered" usergroup before they confirm their e-mail despite having the "Skip Email Confirmation" option of that add-on disabled.

Thanks for your clarifications Jeremy and Mike, it wasn't making sense to me how non-Valid users were having permissions they weren't supposed to have despite being assigned a secondary Usergroup that gave them those permissions, and the replies from the first 2 gentleman above confused me even further as they were suggesting that the problem was with the secondary usergroup when in reality the problem was with the primary usergroup as Mike pointed out. Being assigned the "Unregistered / Unconfirmed" primary usergroup until users confirm their e-mails is exactly how XF should work when E-mail Confirmation is enabled and makes perfect sense as that primary usergroup will trump any secondary ones with regards to the "Never" permissions.

I'm going to bring this to the attention of the add-on authors so that they can fix it ASAP.

Thanks again to everyone for their help.

 

[Mike]

The groups aren't changed. The user just receives the permissions from the unregistered / unconfirmed group. That's why I was asking how you confirmed it. You should be able to verify it by just changing your own user's state in the ACP.

There is also no priority distinction between primary and secondary groups.

 

[XFuser]

The groups aren't changed. The user just receives the permissions from the unregistered / unconfirmed group.

And that's how it should work, but this add-on is giving users the "Registered" usergroup before they actually confirm their e-mail and become "Valid".

That's why I was asking how you confirmed it. You should be able to verify it by just changing your own user's state in the ACP.

The users who have registered but have not yet confirmed their e-mail have the "Registered" usergroup assigned yet their User State shows as non-Valid, so they are incorrectly receiving the "Registered" permissions before actually confirming their e-mail.

There is also no priority distinction between primary and secondary groups.

True, but the "Never" permissions of the "unregistered / unconfirmed" usergroup would trump all other permissions, correct?