Thursday, July 17, 2025
19 changes · saas-18.4
New functionality added to Odoo
Users can now download a transcript after a live chat conversation is closed, making it easier to keep records or share the discussion outside Odoo. Emailing transcripts is now limited to logged-in users, improving control over who can send chat records.
Original PR description
This commit will add the possibility to download the transcription of the closed live chat conversation. This commit will also restricts the possibility to send the transcription by email to logged in users. This commit will adapt the mock server to allow logged in live chat visitors. task-4904819 Forward-Port-Of: odoo/odoo#216871
Enhancements to existing features
Website editors can now preview more layout and configuration changes immediately before saving, instead of needing a reload. This makes the editing experience smoother and helps users make confident design choices faster.
Original PR description
Certain options of the website builder are not previewable because they require an rpc call and a reload. However, some of these options could easily be previewed, because their only effect is the addition or the removal of a class. This PR contains two commits that make this kind of option previewable. The main idea consists of applying the correct class when the option is previewed, deferring the rpc call to a save handler. More details are reported in the individual commit messages.
Resolved issues and error corrections
Factur-X electronic invoices now use the deferred start and end dates from invoice lines when those dates are available. This ensures the billing period shown in the XML matches the actual service period, improving accuracy for customers using deferred revenue dates.
Original PR description
### Issue: The FacturX XML has a field `BillingSpecifiedPeriod`, it should depend on `deferred_start/end_date` if they are there. Currently, it only outputs the invoice date as start date and the due…
### Issue: The FacturX XML has a field `BillingSpecifiedPeriod`, it should depend on `deferred_start/end_date` if they are there. Currently, it only outputs the invoice date as start date and the due date as end date. ### Steps to reproduce: - Install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start date and end date on the line of this invoice (`deferred_start/end_date`) - Confirm and send to Factur-X - In the generated XML the dates used are the invoice date and the due date ### Cause: As the `deferred_start/end_date` fields are defined in enterprise and the XML generation is in community, this [commit](https://github.com/odoo/odoo/commit/f0c5d5b46444a289bf55ad5846623d48ac3a3b71) set dates defined in community instead of the deferred ones. ### Solution: Mimicking [the way it's done for UBL20](https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L846) we check if `deferred_start/end_date` are defined (i.e. account_accountant is installed). If it's the case, we use the min/max of the `deferred_start/end_date` as start/end date of the `BillingSpecifiedPeriod` in the XML. To include as much info as we can this commit also adds the `deferred_start_date` and `deferred_end_date` on lines. opw-4874370 Forward-Port-Of: odoo/odoo#218888 Forward-Port-Of: odoo/odoo#215595
Live chat conversations that are waiting for help now automatically move to an in-progress status when an operator joins. This helps teams see the real state of customer conversations more accurately and reduces manual status updates.
Original PR description
The "Looking for help" turn into "In progress" when a new operator joins. task-4933423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an IoT Box cannot be reached through the usual local connection method, Odoo now remembers that failure for 20 minutes and skips repeated slow attempts. This reduces delays of about six seconds per call on affected networks and helps devices fall back more quickly to the alternate connection method.
Original PR description
To contact an IoT Box, if longpolling fails, we fallback to websocket. We use this logic on every call: if the longpolling fails once, there is chance that it fails on the next call. We now avoid contacting via longpolling if it has failed during the last 20 minutes. We then avoid 6 seconds timeout on every call on networks where local requests fail (clients with DNS for example). Task: 4922624 Forward-Port-Of: odoo/enterprise#89598
This fix prevents the Point of Sale from crashing when an employee logs in, loses internet connection, and reloads the page. It ensures employee login data is prepared earlier so offline POS sessions can recover more reliably.
Original PR description
Steps to reproduce: =================== - Enable Login with Employee in POS settings - Open POS and log in with employee - Turn off the internet connection - Reload the POS page Issue: ====== - POS crashes with the following error: `TypeError: Cannot read properties of undefined (reading 'push')` - At that point, employeeBuffer is still undefined Cause: ====== - The method `set_cashier()` is triggered during the parent `setup()` - `employeeBuffer` was only initialized after `super.setup()` - In offline mode, this sequence still executes, leading to an exception when trying to .push() into an undefined buffer Fix: ==== - Moved the initialization of `employeeBuffer` to the beginning of the setup() method Task: 4850543 Runbot Error: 227777 Forward-Port-Of: odoo/odoo#219341 Forward-Port-Of: odoo/odoo#216843
This fixes an issue where returning an intercompany dropship order could incorrectly increase the delivered quantity on the original sales order. The change ensures returned dropshipped items reduce delivered quantities as expected, improving accuracy for sales and inventory records.
Original PR description
**Current behavior:** Returning an intercompany dropship (product vendor is another `res.company`) increases the original sale order line's delivered qty. **Expected behavior:** The delivered qty…
**Current behavior:** Returning an intercompany dropship (product vendor is another `res.company`) increases the original sale order line's delivered qty. **Expected behavior:** The delivered qty should decrease once the return is completed. **Steps to reproduce:** 1. Create two companies, enable all the inter-company synchronization rules 2. Create a product with the dropship route and set the other company as the vendor 3. Create a sale order for the dropship product, confirm 4. Confirm the corresponding purchase order -> validate the dropship picking 5. Return the dropship picking 6. See the sale order line's delievered qty is wrong **Cause of the issue:** The dropship return move(s) are incorrectly flagged as outgoing. **Fix:** Use the `_is_dropshipped_returned()` method to filter these moves from being considered outgoing. Also added on to an existing dropshipping test so that there is now coverage for this use-case when the vendor is not another company, as this was previously not covered. opw-4526750 Forward-Port-Of: odoo/odoo#200133
The website translation editor now hides toolbar actions that cannot be used in translation mode, reducing confusion for users. It also restores the ability to add or remove text animations while translating, and fixes an error that could appear when editing translated lists.
Original PR description
> [LOCO] in translate mode, hide the options in the toolbar that does not work
Invoices automatically sent after online payments now use the invoice email template configured in Sales settings. This ensures customers receive the intended communication and keeps post-payment invoicing consistent with business preferences.
Original PR description
When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system…
When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system parameter. This was due to the `_send_invoice` method in `payment_transaction` calling `_generate_and_send_invoices` without passing the configured template. This commit modifies the `_send_invoice` method to retrieve the 'sale.default_invoice_email_template' system parameter. If found and valid, the corresponding mail template record is passed in the context to `_generate_and_send_invoices`, ensuring the correct email template is used for auto-sent invoices after online payments. Added unit tests for the different scenarios. FW-18.4: Seems like cls.partner in the unit test does not have an email address set. This causes issues and the invoice email is not sent because it gets filtered out for not having an email set (see https://github.com/odoo/odoo/blob/aca52bc9135083050aa09cd1598638dce5438399/addons/account/models/account_move_send.py#L203-L204). For simplicity, an explicit assignment for email on the partner was added to the unit tests. ## Reproduction Steps: 1. **Enable Auto-invoicing:** Go to Sales > Configuration > Settings. Under "Invoicing," enable "Automatic Invoicing." Set a specific email template in "Invoice Email Template" (e.g., "Customer Invoice"). Save. 2. **Configure Payment Acquirer:** Go to Invoicing > Configuration > Payment Acquirers. Activate and configure any payment acquirer (e.g., Bank Transfer). Ensure it's published. 3. **Create Sales Order:** Go to Sales > Orders > Quotations. Create a new SO, add a product, and Confirm it. 4. **Simulate Online Payment:** As a customer, navigate to the SO's public portal link. Click "Pay Now," select the configured acquirer, and complete payment. 5. **Observe the Issue:** Check the communication history on the generated invoice. The email will have been sent using Odoo's default invoice template, ignoring the configured setting. opw-4865475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219177 Forward-Port-Of: odoo/odoo#217878
This fixes two website issues: the setup translation check now works with the updated Website Builder, and rapidly saving after entering edit mode no longer causes an error. It improves reliability for website configuration and editing without changing business workflows.
Original PR description
**Commit 1:** Commit re-enables the test_01_configurator_translation test, which was broken and skipped due to the DOM changes introduced by the new Website Builder. It also adapts the tour selectors…
**Commit 1:**
Commit re-enables the test_01_configurator_translation test, which was broken and skipped due to the DOM changes introduced by the new Website Builder. It also adapts the tour selectors accordingly.
In the configuration screen, after clicking the "Build My Website" button, the website was taking unexpected time to load. To address this, we added `expectPageUnload` to wait for fill page load. After that, we wait for the configurator to finish.
**Commit 2:**
Steps to reproduce:
Go to edit mode and quickly click "Save" within 200ms.
It will throw the error:
Cannot read properties of null (reading 'classList')
Reason:
In the useEffect of WebsiteBuilderClientAction
1. User enters edit mode → isEditing = true.
2. This adds "o_builder_open" class to <body>.
3. A setTimeout is started to run builder-related DOM updates.
4. Before the timeout runs, user clicks "Save" → isEditing = false.
5. The "o_builder_open" class is removed from <body>.
6. When the timeout executes, it tries to access:
document.querySelector(".o_builder_open .o_main_navbar")
7. This returns null because ".o_builder_open" no longer exists.
8. Calling .classList.add() on null throws a TypeError.
Fix:
Added a cleanup function to the useEffect hook to ensure that any pending timeouts are cleared when the dependency (`isEditing`) changes. This prevents unexpected DOM updates and ensures consistent behavior when toggling edit mode rapidly.
runbot-226533Mercado Pago payments that return a processing status are now treated as still in progress instead of failed. This prevents confusing error messages at checkout and lets the normal retry flow continue until the payment result is confirmed.
Original PR description
The Mercado Pago 'PROCESSING' payment status was not handled. As a result, when receiving this status, the payment was treated as failed and the user saw an 'Unknown payment status' message. This fix treats 'PROCESSING' as an in-progress state, just like 'OPEN' and 'ON_TERMINAL'. It triggers the same retry mechanism. opw-4918455 Forward-Port-Of: odoo/odoo#219056 Forward-Port-Of: odoo/odoo#218990
This fixes how Vietnamese credit notes are sent to Viettel SInvoice so that totals and tax amounts keep the correct negative sign. It helps ensure credit notes display accurately in Viettel's portal for accounts where Viettel automatically adjusts submitted values, though accounts without that validation flow may be affected differently.
Original PR description
Description of the issue/feature this PR addresses: - Viettel SInvoice will automatically change the signs of the amount values (except for unit price) we sent for credit notes (on accounts with data…
Description of the issue/feature this PR addresses: - Viettel SInvoice will automatically change the signs of the amount values (except for unit price) we sent for credit notes (on accounts with data validation step). So the "right" values will appear in the portal. Currently (before the commit) the values have the wrong sign in the portal (because they are changed but we sent the right ones already). - We need to retain the original signs of those values when submitting them to SInvoice. Current behavior before PR: - All the amount values, including `itemTotalAmountWithoutTax`, `taxAmount`, `itemTotalAmountAfterDiscount` and `itemTotalAmountWithTax` are sent to Viettel SInvoice in negative values for credit note. Viettel SInvoice changes the sign of these values to positive (which is not correct for credit note). Desired behavior after PR is merged: - Only the sign of `unitPrice` is changed when we send the credit note to SInvoice. **Note:** - The signs will not automatically be changed for accounts with data validation step removed. So this commit will break credit notes for them (since the signs are not automatically adjusted but our values have the wrong signs). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201993
This update ensures Odoo respects the setting that prevents missing standard tax groups from being recreated during accounting data loading. It helps avoid upgrade failures and incomplete accounting records when tax group data is intentionally absent.
Original PR description
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be…
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be created. However, this wasn't respected for `account.tax.group`. As a result, tax groups could still be created even when `force_create=False`, leading to null values in accounts fields like `tax_payable_account_id` and `tax_receivable_account_id`. **The issue which prompted this patch:** - A recent patch in upgrade: odoo/upgrade@d2d16a2321abb525fe3fe2c403f89009f51c1394 This patch was made to update the `reconcile` and `non_trade` flags on standard accounts due to recent changes across localizations. During the upgrade, we overrode the `write` method of `account.tax.group` to conditionally update these flags. However, in a client’s database, `account.tax.group` records were missing for the `l10n_pk` module, while the standard account records were present. When `try_loading` was triggered at the end, it attempted to `create` the missing tax groups. But since the create method is called during creation and does not include the conditional update logic for `reconcile` and `non_trade` the upgrade failed with the same error that the original patch aimed to resolve. - To avoid such errors and prevent tax groups from being created with null account fields when `force_create=False`, this patch ensures `force_create` is respected for `account.tax.group`. **Steps to reproduce:** - Create a `v17` DB and install `l10n_pk` - Delete the standard tax groups - Upgrade to `v18` OPW-4915394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219211
This update corrects rounding differences when Mexican electronic payment documents are generated for invoices paid in a foreign currency. It helps prevent valid USD payments from being rejected by the tax authority due to small peso conversion mismatches.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
- line 1: price_unit 93.76, quantity 172, tax 16%
- line 2: price_unit 74.18, quantity 161, tax 16%
- line 3: price_unit 74.18, quantity 162, tax 16%
- line 4: price_unit 93.76, quantity 384, tax 16%
- line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI
Issue: Payment validation will fail with error
> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".
opw-4750981
Forward-Port-Of: odoo/enterprise#90003
Forward-Port-Of: odoo/enterprise#88952Deferred revenue or expense entries are now created even when the covered period is shorter than one month. This helps ensure invoices for short date ranges are allocated accurately instead of being skipped.
Original PR description
Previously, `_get_deferred_periods` would return an empty list when the deferral period was contained within a single month and matched the invoice date's month, even if the period spanned multiple days. This caused deferred entries to be skipped for valid short deferral spans (e.g. June 25 to June 30). This fix removes the condition that filters out single-month deferral periods, ensuring that deferred entries are always generated when a valid start and end date are present. This change supports accurate pro-rata allocation even for invoice periods shorter than one month, aligning the accounting behavior with expected financial standards. task-4910854 Forward-Port-Of: odoo/enterprise#89114
Field service tasks now correctly validate deliveries for kit products added through related sales orders. This ensures delivered quantities update as expected when the task is marked done, avoiding manual delivery follow-up and billing delays.
Original PR description
**Problem:** when the product in the sale order linked to a field service task is a kit and the task is marked as done, the delivery is not validate (as it would for a non kit product) **Steps to…
**Problem:** when the product in the sale order linked to a field service task is a kit and the task is marked as done, the delivery is not validate (as it would for a non kit product) **Steps to reproduce:** - Create a product and set up a Kit-type Bill of Materials for it (with at least two components) - Create a service-type product. - Set the Invoicing Policy to Prepaid/Fixed - set the "create on order" field to Task - assign the Project to Field Service. - Create a Sales Order using the service product. - Confirm the Sales Order. - In the linked task, click on the Products smart button - add the kit-type product from step 1. - Mark the task as done. **Current behavior:** On the sale order, the delivered quantity for the kit product is 0. If you click on the delivery smart button, you'll see that the picking is not validated yet **Expected behavior:** the picking should be validated **Cause of the issue:** https://github.com/odoo/enterprise/blob/d8dc0cabd83a29d0522cb5fd25c6956968d4408b/industry_fsm_stock/models/project_task.py#L23 the orer_line is considered as an exception because the order_line product_uom_qty is smaller than total_qty (the sum of the move_ids' product_uom_qty) But this is normal in the case of a kit opw-4848444 Forward-Port-Of: odoo/enterprise#89616 Forward-Port-Of: odoo/enterprise#88363
Restaurant reservations made through appointment booking now display the number of guests entered by the customer instead of showing zero or defaulting to table capacity. This helps staff see accurate party sizes and manage seating more reliably.
Original PR description
Currently when making an appointment for x amount of people, inside the restaurant it will show 0 as the number of people who booked. Steps to reproduce: ------------------- * Activate booking on the restaurant * Open the booking preview * Place a reservation for 5 people * In the restaurant and remove default filter > Observation: It shows 0p on the reservation Why the fix: ------------ By having a default value on the field is would not trigger the compute unless a change was made on `resource_ids` after the create was over. After fixing this bug we also aboserve that if we make a reservation for 1 person but all the tables in the restaurant are 4 person seatings, the reservation will show 4p. The reservation should in priority depend on the number entered while booking otherwise we can compute it regarding the resources. opw-4882681 Forward-Port-Of: odoo/enterprise#88777
Fixes issues in the salary configurator and offer-signing flow so employee contract versions are created and updated correctly. This helps avoid incorrect current salary versions and ensures personal details are saved in the right place, including Belgian payroll-specific data.
This fix ensures DHL and USPS shipping each use their own package detail logic. It prevents one carrier from accidentally using the other's package information, reducing the risk of incorrect shipping data when both connectors are installed.
Original PR description
Forward-Port-Of: odoo/enterprise#89771