Unconfirmed users are grouped into member

ligyxy

I have the default role and permission settings, but the registration method is Basic.

I have also checked the option that user must confirm their email address, and it works well.

I found that all new users will be assigned to member role, although there's an option showing whether they have confirmed their email addresses when editing their personal info. Not sure if it's a bug, since there is a unconfirmed role by default, and that's for the users who haven't confirmed the email, isn't it?

vrijvlinder

all new users will be assigned to member role

After confirming their email if that is the setting.

there's an option showing whether they have confirmed their email addresses when editing their personal info

The role for Unconfirmed is the same as Applicant and it has the same permissions as Guest. All registrants should be Guests until they confirm their email and should not be allowed to post.

ligyxy

@vrijvlinder said:

all new users will be assigned to member role

After confirming their email if that is the setting.

I guess that's the problem I meet. All users, no matter they confirmed the email or not, are in member group. Is it just me?

R_J

Check for this config setting in your config.php: $Configuration['Garden']['Registration']['ApplicantRoleID']

If it is there, try if the misbehavior prevails if you delete it.

ligyxy

I guess my problem is the same to this one: https://vanillaforums.org/discussion/31154/new-member-that-have-not-unconfirmed-email-gets-wrongly-assigned-user-member

And the solution is to add the config $Configuration['Garden']['Registration']['DefaultRoles']

R_J

@ligyxy said:
And the solution is to add the config $Configuration['Garden']['Registration']['DefaultRoles']

Those lines are in /config/config-defaults.php and should therefore not be needed in config.php. If you need to add those lines to config.php, your config-defaults.php might be corrupt. Just because I'm curious: could you please
a) post what you have added to config.php
b) report if that has solved you problems
c) post your config-defaults.php (that file normally is never changed so there is no need to omit lines when you post it here)

ligyxy

@R_J Thank you.

There is this line in config-defaults.php, but it was
$Configuration['Garden']['Registration']['DefaultRoles'] = array('8');
It seems that it's the value by default. And the comment is outdated I guess, it syas '(4 is "Member")', but 4 is applicant in my db.

What I have added to config.php is:
$Configuration['Garden']['Registration']['DefaultRoles'] = '3';

It still works well when I update the value in config-defaults.php to 3 which is the unconfirmed users and remove the line in config.php.

R_J

Thanks for the feedback! You should not change the config-defaults.php it will be overwritten when you update to a new Vanilla version. Putting the line in config.php is the right thing to do.

Shadowdare

I've also noticed this behavior on Vanilla 2.2.1 recently. New members would be placed in the "Members" role instead of the "Unconfirmed" role. In my case, the default roles have been set up correctly, the email confirmation required option is enabled, and the $Configuration['Garden']['Registration']['ConfirmEmailRole'] = '3'; is set to the correct role ID for the "Unconfirmed" role.

This seems to be a change in Vanilla 2.2. from 2.1. When editing a user profile, you can see a new "Confirmed email address" checkbox. If it is checked, the user's "Confirmed" field in the GDN_User table would be set to 1 in the database. If this is not checked and even if the user is in the "Members" role after registration, they will inherit the permissions of the "Unconfirmed" role.

See the code behind this here: https://github.com/vanilla/vanilla/blob/release/2.2/applications/dashboard/models/class.usermodel.php#L1557

By the way, I haven't tested to see whether the InformMessage for unconfirmed users still shows up or not, but it may be good to double-check at some point since some members tried to do something they didn't have permission to and couldn't figure out why until I noticed (via the new checkbox) they haven't confirmed their email address.

It does seem a bit confusing to be able to assign these roles to the user, but also have a checkbox to change the confirmed status while editing a user's profile. Perhaps @Linc can provide more info behind these changes.

Linc

Vanilla 2.2 replaces the old config settings with role 'types' that should be settable by editing each role in the Dashboard. That getSession() code @Shadowdare highlights looks buggy because it's retrieving the ConfirmEmail role the old way.

That said, 'unconfirmed' is a bit of a weird state/role, because it's never meant to be permanent, and has a "backup" condition (usually the default member role) once its requirements are fulfilled (the user clicks a link in their email). Checking that box is supposed to simply override that requirement and send them to the default member role. It's a bit of an anachronism at this point, I think.

River

@Shadowdare said:

It does seem a bit confusing to be able to assign these roles to the user, but also have a checkbox to change the confirmed status while editing a user's profile.

if you missed the other thread....

Yes it has confused every admin who has actually paid attention to the Members. There are probably quite a few people who still think they have many "active" members when in fact they may just have a bunch of "pseudo-Members" who haven't and may never confirm their E-mail. It is especially confusing for registration by Applicant Approval, since Admin doesn't have a clear knowledge in User Dashboard out of the box on who has confirmed or not.

linc said: That said, 'unconfirmed' is a bit of a weird state/role, because it's never meant to be permanent, and has a "backup" condition (usually the default member role) once its requirements are fulfilled (the user clicks a link in their email). Checking that box is supposed to simply override that requirement

Yes it does remove that requirement, but it is still something that is pretty much invisible to the average forum admin (confirmed or not) and it is not in a central place to determine.

In fact in many cases it may be the reality (permanent and never confirmed), rather than it is meant to be, but appears to the admin as a "Member".

more info here:
https://vanillaforums.org/discussion/comment/241699/#Comment_241699

But then again, when the new dashboard is changed in a later version it may be clearer. But that change is probably a few versions off from what I've read and at least alerting users in release notes would be helpful, if a code change is not made in next release.