Fixed Email bounce handling & changing email

Affected version
2.1.3

Xon

Well-known member
If "Enable email confirmation" is disabled (or the user is an admin/mod), and the user is in a bounced status, changing their email does not change their account's state leaving them in a bounced state.

This is because of;

PHP:
if ($this->isConfirmationRequired())
{
   $this->changeUserStateForConfirmation();
}
There is no else path to update from bounced to non-bounced
 

kick

Well-known member
I already wrote about the problems. However, they did not even respond to the complaint.
 

XF Bug Bot

XenForo bug fixer bot
Staff member
Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.4).

Change log:
When an email address is changed, move user out of email bounced state if email confirmation is not required
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 

Sperber

Well-known member
Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.4).

Change log:

Any changes made as a result of this issue being resolved may not be rolled out here until later.
I am on 2.1.4. It seems the fix isn´t included in that version and my subscription run out. Any chance to get those additional lines for the else statement, so I could add them manually? 12k accounts are affected.
 
Last edited:

ENF

Well-known member
I am on 2.1.4. It seems the fix isn´t included in that version and my subscription run out. Any chance to get those additional lines for the else statement, so I could add them manually? 12k accounts are affected.
This fix is included in 2.1.4 as noted in the release notes:

Have you run a test on an affected account?
 

Sperber

Well-known member
This fix is included in 2.1.4 as noted in the release notes:

Have you run a test on an affected account?
Yes, I´ve just checked the php files the other minute and it´s already in there. Guess I have something messing around with that setting and my best guess is, it´s caused by a specific third party modification. So we should consider this as fixed in 2.1.4, as announced.
 
Top