Email Address Not Updating 9.2

[okjones]

I've confirmed this on three different development instances.

While my first attempt seem to work correctly, subsequent attempts failed...

When a customer attempts to update the email address, ASPDNSF refreshes the page, displays the account update message, and it appears that the email address updated. However when you navigate away and return, or click a link to display account.aspx and a new database call is made, the old email address remains.

Also, if the user tries to enter an email address that's already in the system, the error message is displayed saying that the email address was not updated because it's already in use. However, the email address actually does update with the duplicate, and the newly entered duplicate appears in the Customer table in the database.

Has anyone else experience this? Is there a workaround?

I've entered it with support.

[okjones]

Erik confirmed this as a bug in 9.2. They're not planning on fixing it until an upcoming release. If someone can come up with the fix for this, please post.

[webopius]

Hi,

Disclaimer first: I've done a very quick visual check of the v9.2 account.aspx.cs, customer.cs and database procedure that updates the customer. So this might not work!

But, try this:

Looking at the file account.aspx.cs there is a method called 'btnUpdateAccount_Click' which is called when the customer clicks to update their account details.

Within this method is this line:

NewEmailAddressAllowed = Customer.NewEmailPassesDuplicationRules(

Which I think returns true if the new email address is permitted.

The problem is that later in the code, there is this check:

if (NewEmailAddressAllowed || !emailisvalid)

Which then goes on to reset the Customer's email back to their original email address. The problem is that this is being called when the new email address is allowed, whereas it really needs to be called only if the new email address isn't allowed or the email address is invalid.

The fix

To fix this, I *think* you just need to change the line in account.aspx.cs to add a ! in front of NewEmailAddressAllowed:

if (!NewEmailAddressAllowed || !emailisvalid)
{
      EMailField = ThisCustomer.EMail ;
}

...and Vortx, add a test case into your product test schedule to test for this in future releases!

[okjones]

Excellent. The fix worked worked on our installation. It fixed both issues. This should become a sticky because anyone running 9.2 is likely experiencing customer frustration with this bug.

Thanks!!!

[Skriver]

I'd have to say that Webopius are the best out there.

[AspDotNetStorefront Staff - Erik]

Kudos to Webopius! I added your fix to the bug in development. It still has to go through the usual process of review, prioritization, etc. but I have personally verified the fix is valid.

[webopius]

Great to hear and thanks for the feedback.

Adam

[rsen]

Hi,

Disclaimer first: I've done a very quick visual check of the v9.2 account.aspx.cs, customer.cs and database procedure that updates the customer. So this might not work!

But, try this:

Looking at the file account.aspx.cs there is a method called 'btnUpdateAccount_Click' which is called when the customer clicks to update their account details.

Within this method is this line:

NewEmailAddressAllowed = Customer.NewEmailPassesDuplicationRules(

Which I think returns true if the new email address is permitted.

The problem is that later in the code, there is this check:

if (NewEmailAddressAllowed || !emailisvalid)

Which then goes on to reset the Customer's email back to their original email address. The problem is that this is being called when the new email address is allowed, whereas it really needs to be called only if the new email address isn't allowed or the email address is invalid.

The fix

To fix this, I *think* you just need to change the line in account.aspx.cs to add a ! in front of NewEmailAddressAllowed:

if (!NewEmailAddressAllowed || !emailisvalid)
{
      EMailField = ThisCustomer.EMail ;
}

...and Vortx, add a test case into your product test schedule to test for this in future releases!

Is anyone else seeing this in v9.3.0.0 as well ?

[AspDotNetStorefront Staff - Erik]

No, this has not been fixed out of the box as of MSx9.3.1.0