We’re getting ready to launch (in four days) and as we put our install through its paces, we came across the alert above.
The path was:
Admin in Chrome browser:
• New user created (via csv bulk upload)
• Email invite sent
User (really just the admin testing the process in an incognito browser)
• Email accepted
• Users uses Discourse
• Not actively logged off
• Return to computer next day with incognito turned off
• Log out of admin profile
• Try to log into user profile (not in incognito)
Error occurs.
We see that this sort of false non-activation had been discussed here on the board previously and been declared dead.
We’re going to try to recreate this in new browsers, no incognito hocus pocus, but since we saw some other bugs (and we’re on the hosted plan, which means we can’t use those solutions) we want to raise our hands early and ask, “is this something real?”
The “redeem invite” code was not consistently sending “Confirm your new account” email if the user has already set password while accepting invite. This was causing error in email log and hence no_email_found.
Now invited user will always receive “Confirm your new account” email if they set password while accepting invite. Once they confirm their account the login flow will work perfectly.
@Seth_Godin Thank You for reporting this issue and providing detailed repro steps!
This fix will be deployed on your instance early next week.
This is probably going to have to wait 2 to 3 more days till we roll out the change.
We recently added a very sizable feature (user selectable themes) which needs a few days “to cook”, what we are doing now is gradually rolling the change out, but it will probably take a few more days till it hits your instance.
