Daily updates from Odoo
Wednesday, September 4, 2024
19 changes
6 changes
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
5 changes
Resolved issues and error corrections
The UK BACS payment module now correctly depends on the UK localization module. This helps ensure the required UK banking functionality is installed automatically when needed, reducing setup issues for users.
Original PR description
### Steps to reproduce: - Install the 'l10n_uk' module - The module "l10n_uk_bacs" is not installed, but it should ### Solution: Make the `l10n_uk_bacs` module dependent on `l10n_uk`. When running `./odoo-bin --addons-path="addons/,../enterprise/" -u l10n_uk_bacs -d [db]` it detects the unmet dependency (`module l10n_uk_bacs: Unmet dependencies: l10n_uk`) and installs it. So I guess there is no need for an upgrade script. opw-4122475
This change prevents a shared translation dictionary from being modified globally, reducing the risk of incorrect translated text appearing elsewhere in the system. It also improves how data is prepared for reporting by moving shared JSON handling to a more appropriate common location.
Original PR description
The global dictionary containing the translations cannot be modified. opw-3932856
This change restores a previous implementation in the appointment booking flow to fix a problem where available time slots were not shown. Customers and users can once again see and select appointment slots as expected.
Original PR description
This reverts commit 9e38975d3f1e9dc87a3061c06ce9df7cf562949c which prevents slots from being displayed. task-3928221
Payroll users can once again register payments for payslips that generate miscellaneous journal entries. This prevents payroll payment workflows from being blocked by a recent accounting validation change.
Original PR description
A recent update restricted the registration of payslip payments since the journal entries generated were misc entries. https://github.com/odoo/odoo/pull/174314 This commit fixes the issue by bypassing that check for payslip payments.
This fixes subscription behavior so only invoices tied to the current subscription are considered when checking for active draft invoices. It prevents unrelated contract invoices from affecting subscription payment and renewal tests, improving reliability without changing expected business workflows.
8 changes
Resolved issues and error corrections
A previously removed method that handles page reloading in the IoT module was causing errors for users with older interface versions. This fix restores the method to ensure compatibility and prevent system errors when users interact with IoT device setup.
Original PR description
We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9). Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore. We then add it again to fix the issue. Support task: 4152608
This fix resolves an issue where subscriptions with the same invoice address were being billed separately instead of consolidated into a single invoice. The system now correctly groups subscriptions by their invoice address before generating invoices, ensuring that customers with multiple subscriptions to the same billing location receive one combined invoice instead of multiple separate ones.
Original PR description
Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual…
Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual then duplicate it - Create a subscription with the indiviual as customer - Duplicate the subscription then set the duplicate contact as customer - Debug mode > Scheduled actions - Sale subscription: Generate recurring invoices and payments > Run manually The subsciptions are invoiced separately instead of having one invoice for both. The consolidated billing should produce only one invoice since the invoicing address is the same. This behavior works as intended if using the create invoices action on both subscriptions at once. Here, the recurring invoice creation for subscriptions uses its own grouping function using partner_id as a key instead of partner_invoice_id which is 'parent invoice address id if any, else partner_id'. Because this grouping is performed before creating the invoices, we end up processing sale orders that should have belonged to the same group separarately and thus create the invoices one by one. This means we don't let _create_invoices do the grouping since we only pass it one SO at a time, this fix will make it so _create_invoices is called on the grouped SOs instead. opw-4114035
A dialog in the Account Reports module was failing to close properly due to a missing close function. This fix implements a custom close function that properly handles the dialog closure, allowing users to successfully open and close dialogs without encountering errors.
Original PR description
When we tried to open the dialog, we would get an error telling us that the function close from the props is missing. The fix is to use a custom close function that will trigger the action of type `act_window_close` task-4154392
Employee names that are too long were being cut off in the appraisal form view. This fix extends the employee name field to use the full available width, ensuring all employee names display completely regardless of length.
Original PR description
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637
This fix prevents the invoice status of a sales order from incorrectly reverting from "Fully Invoiced" to "Nothing to Invoice" when a field service product's price is changed to zero after invoicing. The system now checks whether an order has already been invoiced before recalculating invoice status, ensuring the invoice history remains accurate and unchanged.
Original PR description
### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the…
### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the delivered quantity of the field service product to meet the order quantity - Check the invoice status (will be 'Fully Invoiced') - Set the field service product in the SO to a unit price 0 ### Current behavior before PR: After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91 ### Desired behavior after PR is merged: We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL. opw-4017282
This fix corrects an issue where the sales order item list in field service tasks was incorrectly displaying down payments and loyalty rewards. The solution refines the filtering logic to show only relevant sales order items, improving accuracy when creating tasks for customer service requests.
Original PR description
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records accurately. opw-4001226 odoo pr : https://github.com/odoo/odoo/pull/173667 Forward-Port-Of: odoo/enterprise#66388
This fix resolves an issue where customers couldn't add certain product variants to their cart when the product had multiple subscription plans. The system now correctly recognizes when a variant matches any of the subscription plans already in the cart, allowing the purchase to proceed instead of showing a compatibility error.
Original PR description
Steps ----- [website_sale_subscription] 1. Create a recurring product with 2 recurring plans. 2. Create 2 variants for this product. 3. In the "Recurring Prices" tab, add a variant to the first plan and the other variant to the other plan. 4. Go to eCommerce and add to the cart the second variant (not the default selected one, this is important). 5. Refresh the page > ** This product pricing is not compatible with the product(s) in your cart. ** Cause ----- `_get_first_suitable_recurring_pricing` doesn't specify a plan, so it can return a pricing which doesn't match the cart's plan. Change ----- Allow adding to the cart if any of the product's variants are matching the cart's plan. opw-4081043
Employee names that are too long were being cut off in the appraisal form view. This fix extends the employee name field to use the full available width, ensuring that all employee names display completely without being cropped.
Original PR description
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637