HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options
Approval with Confirm Email config.php settings
Here are some of my config.php settings:
$Configuration['Garden']['Registration']['ConfirmEmail'] = '1';
$Configuration['Garden']['Registration']['Method'] = 'Approval';
$Configuration['Garden']['Registration']['ConfirmEmailRole'] = '3';
$Configuration['Garden']['Version'] = '2.1.11';
$Configuration['Vanilla']['Version'] = '2.2.1';
I believe it was working correctly (users had to confirm their email, and then still had to get approved by an admin before becoming members), but then it stopped and now people who simply confirm their emails automatically become members. Any suggestions?
Tagged:
0
Comments
Some more info: When a new user registers, they automatically become "members", even though ConfirmEmailRole above is set to '3' which is the "Confirm Email" role, as demonstrated by the end of the URL when I click on that role in the dashboard: index.php?p=/role/edit/3
However, even though they are "members" they cannot post to the forum until they click on the link in their confirmation email. I do not understand why they are given the role "members" and not the "Confirm Email" role.
But the most important issue is subjecting the applicant to non-member status before being approved by an admin, even after they confirm their email.
I think I may have found the answer: $Configuration['Garden']['Registration']['DefaultRoles'] = '3';
Doing the above helped, but now the problem is the Applicant is getting both "Member" AND "Confirm Email" status, and when they confirm it becomes just "Member." I have now assigned a different status called "Applicant" to use instead of "Confirm Email", but the results are the same. How can I get rid of applicants getting "Member" status until an admin manually assigns that role to them?
Some of the info here might help you
https://vanillaforums.org/discussion/comment/240552#Comment_240552
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Thanks for the link and response. My database values show that member has a "RoleID" of 8, while "Applicant" has a "RoleID" of 4. If I set both of the values to "4" below, then my applicants STILL get member status:
$Configuration['Garden']['Registration']['ConfirmEmailRole'] = '4';
$Configuration['Garden']['Registration']['DefaultRoles'] = '4';
It looks like at one point in time, I had the following set as such, but I tried it and it did not fix the issue:
$Configuration['Garden']['Registration']['DefaultRoles'] = array('3');
What am I missing? Thanks!
If you are using Vanilla 2.2.1 or 2.3b1 I can tell you how things seems to work.
User confirmation of e-mail is marked in the User Table. A "zero or 1" in the Confirm(ed) column determines if a user has confirmed their e-mail.
The user's role is determined in the User Role Table.
A user can have the Role Administrator or Member or Whatever. If they have NOT Confirmed their email and email confirmation is required, they will not have the permissions you think they might have determined by their assigned role. If they have NOT Confirmed their email and email confirmation is required, they will NOT have the permissions you think they might have determined by their assigned role.
If they have NOT Confirmed their email and email confirmation is required, they will NOT have the permissions you think they might have determined by their assigned role.
If they have NOT Confirmed their email and email confirmation is required, they will NOT have the permissions you think they might have determined by their assigned role. They will have the permissions of the "unconfirmed role"
This is COUNTER INTUITIVE out of the BOX.
If you look in the Users list in the Dashboard - you may have two Members that are not EQUAL. If you require e-mail confirmation and both users have registered, but only one has confirmed their e-mail. Then both may show up as members but only one will have the permissions of the Member's role. This is controlled by the presence of a 0 or a 1 in the confirmed column of the users table.
the roles of a new installation are in config-defaults.php and there is
$Configuration['Garden']['Registration']['DefaultRoles'] = array('8'); // The default role(s) to assign new users (4 is "Member")
notice the note // The default role(s) to assign new users (4 is "Member")
THIS is still incorrect even in the current master version, so disregard the comment here.
$Configuration['Garden']['Registration']['ConfirmEmailRole'] = 3;
$Configuration['Garden']['Registration']['ApplicantRoleID'] = 4; // The "Applicant" RoleID.
so these are your 3 defaults in the config-defaults.php.
$Configuration['Garden']['Registration']['DefaultRoles'] = array('8');
$Configuration['Garden']['Registration']['ConfirmEmailRole'] = 3;
$Configuration['Garden']['Registration']['ApplicantRoleID'] = 4;
so if you don't want to change them there is no need to add the line in config.php. If you want the above you can simply delete those three lines in your config.php. Since the effect of overriding something with the same exact value is not needed.
IF you want to change behavior via config.php $Configuration['Garden']['Registration']['DefaultRoles'] = array('8'); to
something else (as you did) to give you a heads up in the user dashboard about email confirmation.
Ideally a "Unconfirmed" would be showing up in Dashboard Users table based on the presence of the Confirmed flag. Unrelated but equally beneficial would be a flag "SuperUser" if there is a 1 or higher in the Admin column of the User Table, since a Super Admin could have a role of applicant but still be a Super User if the Admin column for that user had an integer greater than 0 in that column for the specified user. You wouldn't expect this but if you took over a forum, it could be "booby-trapped" this way and you might never know unless you looked at user table or selected for users with a greater than 0 in the admin column. I don't believe a blind automatic removal of etra superusers is a good idea, just an alert in the user table, since there may be a real need for two superadmins, although in most cases not.
So, in the mean time you could sql select the same way to determine users who have not confirmed email, at least those who registered since 2.2.1
Yes this is the behavior of Vanilla with 2.2.1 and 2.3b1 - it is not intuitive, but the permissions for an unconfirmed email user who is a Member are "restricted" as you probably noticed. You should not be able to post a discussion or even see a button with a default setup of permissions and confirm e-mail required, but the dashboard will show you as a Member, even if you haven't confirmed. So the "roles look screwy in the dashboard" due to user role table, but the permissions seem to be accurate, based on the value in User Table for confirm(ed).
This may be fixed in the Master, but is NOT fixed in 2.3b1. you would need to search on github. If this is the intended behavior there should be copious notes in the User Documentation that Tim said is being made.
https://vanillaforums.org/discussion/comment/241582/#Comment_241582
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
not sure if this is related or a different issue, too hard for me to tell.
https://github.com/vanilla/vanilla/issues/4063
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
with regards to vanilla 2.2.1 and/or 2.3b1
In a standard installation with these 3 config statements. from config-defaults.php or added to config.php
$Configuration['Garden']['Registration']['DefaultRoles'] = array('8'); $Configuration['Garden']['Registration']['ConfirmEmailRole'] = 3; $Configuration['Garden']['Registration']['ApplicantRoleID'] = 4;and this in config.php
you should see applicants for any new registrant. they will get a confirm email request. upon registration they remain applicants until you approve them.
if you want to make it clearer on the Manage Applicants Screen.
add this to your plugin.
// show ***Confirmed Email*** on Manage Applicants Screen in dashboard for applicants that have confirmed e-mail. Leave Applicants without confirmation as is. public function UserController_ApplicantInfo_Handler($sender,$args) { if ($args["User"]->Confirmed) { echo "<strong> ***Confirmed Email*** </strong>"; } }then you can approve the users with Confirmed Email after their name on the Manage Applicants screen.
you could do something similar with a different event on user dashboard, but the applicant screen is less crowded and the details are probably more important to you - did they confirm email or not.
I would advise trying the above settings regarding config.php if you want both approval and confirm e-mail.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
Thanks for all the great information. I'll look into it soon.