Daily updates from Odoo
Wednesday, September 4, 2024
6 changes · saas-17.2
Resolved issues and error corrections
This fixes an issue where sales order confirmation emails were not sent to a CC address when that address matched the company or sender email. Businesses can now rely on copied recipients receiving customer-facing email notifications as configured.
Original PR description
[Reproduce] - Apply diff (ref.1) (optional) - Install payment_demo,website_sale - Configure email server (or Mailhog) - Skip if applied (ref.1): - Change email of current company to…
[Reproduce]
- Apply diff (ref.1) (optional)
- Install payment_demo,website_sale
- Configure email server (or Mailhog)
- Skip if applied (ref.1):
- Change email of current company to contact@yourcompany.com
- Update template: "Sales: Order Confirmation", so the cc field is set to the same email
- Buy something in the website shop
- BUG: email not sent to CC
(ref.1)
```diff
diff --git a/addons/sale/data/mail_template_data.xml b/addons/sale/data/mail_template_data.xml index ed191440817f..2a02d13bd312 100644
--- a/addons/sale/data/mail_template_data.xml
+++ b/addons/sale/data/mail_template_data.xml
@@ -69,6 +69,7 @@
<field name="model_id" ref="sale.model_sale_order"/>
<field name="subject">{{ object.company_id.name }} {{ (object.get_portal_last_transaction().state == 'pending') and 'Pending Order' or 'Order' }} (Ref {{ object.name or 'n/a' }})</field>
<field name="email_from">{{ (object.user_id.email_formatted or object.company_id.email_formatted or user.email_formatted) }}</field>
+ <field name="email_cc">{{object.company_id.email_formatted }}</field>
```
opw-4012438This fix prevents a Firefox-specific crash that could interrupt users when navigating Email Marketing screens during guided tours or related iframe activity. The page now waits for the embedded content to fully load in a safer way, improving reliability without changing user-facing features.
Original PR description
__Current behavior before commit:__ On Firefox `iframeEl.contentDocument` might be `null` inside the `readystatechange` event handler. This makes the page crash with the error `TypeError: iframeEl.contentDocument is null`. __Description of the fix:__ Utilizing `event.target` instead of `iframeEl.contentDocument` to make sure the document is not `null`. Since nothing is done in the event handler unless `document.readyState === "complete"` we can just use the `load` event instead. __Steps to reproduce the issue on runbot:__ On Firefox (127): 1. Install `mass_mailing` 2. Open the debug menu > Start Tour 3. Start the `mass_mailing_tour` 4. Go to Email Marketing > open a mailing with the `Sent` state 5. Click on any link/tab (e.g. a/B Tests) -> Crash opw-4005833
The website editor color picker now opens with the expected color combination tab first, restoring the previous website-building experience. This fixes a regression introduced by a mailing editor change that made an important website design workflow harder to use.
Original PR description
*: web_editor, mass_mailing This purely reverts [1] which, while implementing a minor feature for the mass_mailing editor, broke a major feature of the website builder. This went unnoticed because the test tours were also adapted to account for the change. Once the time is right, the minor feature will be re-implemented although it probably will be done another way. Also, the functional need should be rediscussed as I don't see the point in showing the "solid" tab at all if it is to show it only when such a color was previously selected. Just removing that tab seems to improve the UI and would be a one-line-code feature instead of this. To re-discuss. [1]: https://github.com/odoo/odoo/commit/8594fa708c06232cde5743be2b66f551ff5a4589
This update makes an automated website editor test more stable by adding checks that wait for the page content to be ready before continuing. This reduces random test failures and helps keep website changes safer to release.
Original PR description
In this commit, we fix undeterministic test_html_editor_scss tour. To fix this behavior, we add few additionnal steps to check the state of DOM before continuing the tour.
Italian electronic invoices can now be generated when an invoice includes a negative line with a different tax. This prevents an incorrect blocking error during Send & Print and aligns the export with what the Italian SDI system accepts.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice for an Italian customer with: * 1 positive line having a tax * 1 negative line having another tax - Confirm the invoice - Generate E-invoice XML via "Send & Print" button **Issue:** A UserError is raised because orphan negative lines are not allowed after dispatching the negative lines. **Solution:** Remove the UserError as SDI accepts negative lines. opw-4132287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves Odoo's internal web test environment so tests can identify the correct page element instead of accidentally selecting test framework overlays. It helps make automated test results more reliable and reduces false failures during development.
Original PR description
This commit introduces a global mock for the document `elementFromPoint` and `elementsFromPoint` methods, so that it ignores both Hoot's fixture and UI container. This has been done since when not debugging a test, the fixture is z-indexed behind the body and both of these methods would consider them accordingly, meaning that production code relying on these methods would consistently get the Hoot UI or the body instead of the desired element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr