User Stuck Asking to confirm email

Gillingham

Anyone know where this flag in the database is set?

The user is in the normal confirmed email usergroup yet he constantly gets popup messages asking him to confirm his email again and again despite doing it multiple times.

UnderDog

Ok, let's see... There's something strange going on here...

You have 2 options:

a) compare his user ID with another user ID which doesn't get those popup messages (normal users, not an admin user, like you are :-) )

b) You need to know the exact text that the user gets, because then you can search in the Vanilla source files (grep is your friend if you're using Linux) for that exact text and then 'follow' the text into the Vanilla code, (if you know what I mean, because the text is usually from a translation file)

---

There is a plugin that lets you assume the credentials of that actual user, so you can test the outcome and maybe make some changes. (I just forgot the name of the plugin, but it's probably the name of the actual action of assuming that other user ID, (some of the other guys will know what I mean)

---

Can you doublecheck one more time the entries for that user ID in the gdn_userrole table? and then the RoleID in the gdn_role table? I need to see the actual text that comes out of those 2 checks, please :-)

Gillingham

RoleID is 3, which correlates to the Member role everyone else on the forum has without getting these notifications.

Looking at the user table this stuff might be in attributes, this is probably a vanilla bug that isn't letting it remove the emailkey requirement, I don't think there's any documentation to explain the Attributes column so who knows.

peregrine

attributes is serialized data

why don't you cut and paste the attributes data for the user that has the problem.

Gillingham

I removed the references to email in the attributes section and updated the array size, waiting for the user to test and get back to me.

UnderDog

Gillingham said: Looking at the user table this stuff might be in attributes, this is probably a vanilla bug that isn't letting it remove the emailkey requirement,

Sure it is, that's why you're the only one having this bug..., but seriously, then compare that user's attributes to someone elses attributes, copy his attributes to that user ID, etc, etc. There are many ways to solve that. (it was test a, remember)

By the way, I was expecting this result:

gdn_userrole

UserID    RoleID
13          3
13          2

gdn_role
RoleID    Name
2            Regular User
3            Confirmation Role

but ok... if you say it's RoleID 3, then it's RoleID 3 and not accidentally an extra role... that's fine.

Sheila

@UnderDog, I think this thread is about the same issue http://vanillaforums.org/discussion/20874/email-confirmation-wont-turn-off

peregrine

The solution is to remove it from attributes (as was done). But this is how to recreate the problem I believe.

it gets checked in the classhooks.php starting around line 40 and about line 51 it will never be changed IF:

if the configuration line is changed in config.php from

Garden.Registration.ConfirmEmailRole = TRUE;

to

Garden.Registration.ConfirmEmailRole = FALSE;

and if some users have not confirmed.

I believe any users created who haven't confirmed between the changes will never get the EmailKey remove if it is set and will have to be removed manually by removing the

emailkey sequence.

UnderDog

Sheila said: @UnderDog, I think this thread is about the same issue http://vanillaforums.org/discussion/20874/email-confirmation-wont-turn-off

Ok, so I was wrong, mea culpa

Thanks for finding the solution so quickly, peregrine

Gillingham

That was not the case here, if anything the value went from False to True. One thing that did happen was that the email confirmation Role was set to the normal member role, so maybe the logic that transitioned the user from the email confirmation role to whatever member roll doesn't work if they are the same RoleID?

peregrine

probably another case were switching confirmation roles while confirmations are still not confirmed causes an issue.

UnderDog

Gillingham said: One thing that did happen was that the email confirmation Role was set to the normal member role

That's the reason I wanted to see the actual details, I just wanted to bring it slowly. But hey, since I was wrong, I will stay out of this one for a while.

Just curious. Did you convert from another Forum system? Or was your forum set up using Vanilla from scratch?

Sheila

I'll try to contibute with this also.

I have had my board invitation only, recently I turned it to allow registrations via confirmation email. I did test it creating a new account, and did notice that 'nag'. I think the thing that confuses here, as a usability sense, is that there's a x in the notification popup.

X usually means that once you click it, you close something and it goes away. In this case the nag keeps repeating, untill you actually confirm your email address. So a quick fix to this would be to lose the x from the popup since the confirmation is really meant to be done by clicking an link in a email message.

There might be some bug also but could this be because user has been confirmed as member via admin panel but he/she never actually clicked the link in their email?

Gillingham

This forum has been vanilla for a long time, in fact it was originally 1.x and has been upgraded with all 2.x updates since then, I'm sure a lot of oddities are due to that migration path.

Also regarding the admin confirming/user confirm the user did in fact do the confirmation process, multiple times even.

UnderDog

Gillingham said: This forum has been vanilla for a long time, in fact it was originally 1.x and has been upgraded with all 2.x updates since then, I'm sure a lot of oddities are due to that migration path.

That's what I was thinking too... Look. I've been an actual 'Todd' for custom (windows) software, long long time ago. I know all those things about oddities and migration paths, as I'm sure you do too... The only thing, If you really want to fix it, is install a clean Vanilla 2.1 separately (after you decide to upgrade to 2.1 once it's stable or even in a sort of 'test-phase') and compare the structure and contents of the core tables to the one of the migrated 2.1 database.

So you will have the Lussumo (the name of Vanilla 1) DataBase, upgraded to 2.1 and you will have a clean Vanilla 2.1 database.

Compare those 2 and maybe, just maybe you will see differences.

If it's really bad, just ask the Vanilla Team to chime in, but in the meantime, let's just let them work on 2.1 ;-)