send emails stop working after migration for umbraco 15

[marvingbh]

Which component is this issue related to?

Umbraco Commerce (Core)

Which Umbraco Commerce version are you using? (Please write the exact version, example: 10.1.0)

15.2.2

Bug summary

After migration to Umbraco 15, the order confirmation email stop working. I've notice a weird thing when using the UI to try send the e-mail, the default language is setup to ucModals_sendEmailPlaceholder, is that some variable that I need to set?

I'm guessing this is the cause of the issue but I don't know how to fix it. can you help me?

found this on the logs:

Specifics

No response

Steps to reproduce

Migrate a website from 13 to 15
Try to buy something
email does not work

Expected result / actual result

No response

Dependencies

No response

---

This item has been added to our backlog AB#52853

[umbracotrd]

Hi @marvingbh , the latest version is now 15.3.4 with a multiple bug fixes. Can you give it a shot?

By the way can you describe the upgrade process from 13 to 15? Like, when you're at version 13.x.x, did you upgrade to 14 or jumped straight to 15.2.2?

[marvingbh]

@umbracotrd I've tried with 15.3.4, same problem, about the migration we migrate from 13 to 15, skipping 14.

[marvingbh]

any update on this?

[umbracotrd]

About the ucModals_sendEmailPlaceholder, it's just a translation error, it does not block the email sending process. You can add your own translation file to fix it temporary, we'll push the fix for it in the next patch.

About the emails stop working, can you to go any order and try send out test emails using other email templates? I want to know if all emails stop working or just the order confirmation one. If you see any errors in the log relates to email sending, please share in this post.

[marvingbh]

On the order webpage, emails are sent correctly when I select the appropriate language, regardless of the template. However, when an order is confirmed, the confirmation email is not automatically sent. I suspect this is because the system is using default values instead of the selected language settings, which prevents the email from going out.

[umbracotrd]

Can you access the database? If you can, please run this query select top 100 languageIsoCode, * from umbracocommerceorder where languageIsoCode IS NULL order by createDate desc to see if the languageIsoCode is null for some orders.

The language info's supposed to be saved for each order and the email service will use that language to send out the emails.

[marvingbh]

there is none null. the most common are:

by this query: select languageIsoCode, count(1) count from umbracocommerceorder group by languageIsoCode order by COUNT(1) desc

[umbracotrd]

Yeah, that’s a problem. languageIsoCode is supposed to store the... well, the language ISO code. Any idea how those values ended up there?

[marvingbh]

we don't do anything different, we use headless and the cart code is in react, but calling the umbraco api. in production we have the version 13 running, and the values are like this:

in v13, it works fine the confirmation email.

[umbracotrd]

when creating/updating an order using the storefront api, are you passing language in the request body?

If you are, please check the value you're passing to language property. It should be a string ISO code for the System.Globalization.CultureInfo constructor.

If you're not then you can start passing the language property in the request and it should fix the issue for upcoming orders while wait for the fix from our end.

[marvingbh]

I'm not passing language in the body, I just migrate from v13 where was working, and now is not working anymore. all those fields are optional by the documentation.

[mattbrailsford]

@marvingbh they are optional, but the default behaviour is to fall back to the Accepts-Language header, but it's clear we should be doing more processing to extract the culture value, rather than just using it raw.

@umbracotrd's suggestion to pass the language is to prevent this default behaviour from running and using an explicit language code. We of course will look to fix this issue, but this was just a suggestion to get things working in the meantime.