Odoo Changelog — 2025-11-25

Tuesday, November 25, 2025

18 changes · saas-18.2

Bug Fixes(18)

Resolved issues and error corrections

[FIX] l10n_ec_edi: prevent error on vacuuming withhold wizard

Enterprisesaas-18.2l10n_ec_ediMEDIUM

This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.

Original PR description

Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…

Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard.

**Steps to replicate:**
* Install `l10n_ec_edi` and change company to `EC company`
* Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm
* Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post
* Set system time to future date > Run `Base: Auto-vacuum internal data`.

Refer video [1] for replication steps.

**Error:**
`psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'
`
**Root cause:**
* The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours.
* However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error.

**Solution:**
* Unlink the lines first and then unlink the wizard.

[1]:
https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing 
[2]:
https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 
[3]:
https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 
[4]:
https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427

sentry-6253783256

Forward-Port-Of: odoo/enterprise#99653

#accounting#withhold#ec

[FIX] l10n_es_reports: fix accounts coverage report

PR #99860

Enterprisesaas-18.2

Original PR description

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#98745

[FIX] web_studio: disable image resize options in Studio reports

PR #100362

Enterprisesaas-18.2web_studio

A bug was causing image resizing within Odoo Studio reports to fail, resulting in PDFs displaying images at their original size. This fix disables the percentage-based resizing option, preventing incorrect rendering in PDFs due to limitations of the underlying PDF generation tool. This ensures consistent image display in generated reports.

Original PR description

Problem:
When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`).

Solution:
Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs.

Steps to reproduce:
1. Open Studio → Reports → open any report.
2. Add an image.
3. Resize it to 25%.
4. Save and print the PDF.
5. The image appears at its original size in the PDF.

opw-5233052

Forward-Port-Of: odoo/enterprise#100301

#reports#studio#image resizing

[FIX] l10n_ke_edi_oscu(_stock): add product registration and fix view resolution

PR #100383

Enterprisesaas-18.2l10n_ke_edi_oscuMEDIUM

This update automatically registers products with eTIMS before invoice submission, ensuring accurate data transmission. It also fixes the display of product information, now showing eTIMS-specific fields. Crucially, it corrects a multi-company issue where product registration was using the wrong company's eTIMS system.

Original PR description

Before this PR:
- Sending invoice/vendor bill to eTIMS would send null item codes if products
  weren't registered.
- `View Product(s)` button in validation messages opened standard product
  variant view with generic product fields instead of eTIMS-specific fields.
- When sending multiple invoices via batch processing, product registration used
  incorrect company context (in `self.env.company`) instead of the specific
  invoice's company, causing products to be registered to the wrong company's
  eTIMS system.

After this PR:
- Products are automatically registered with eTIMS before sending
  invoices/vendor bills.
- `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view
  with eTIMS-specific fields.
- Product registration now properly uses the invoice's company context
  (`move.company_id`) ensuring products are registered to the correct company's
  eTIMS system in multi-company scenarios.

Task-5039671

Forward-Port-Of: odoo/enterprise#93375

#eTIMS#Kenya#EDI#Invoice

[FIX] l10n_pe_edi : fix partner reference in UBL XML

PR #100349

Enterprisesaas-18.2l10n_pe_edi

This update corrects a technical issue in the Odoo Enterprise software related to the generation of Peru UBL XML invoices. Specifically, an error was preventing the correct formatting of the XML, now resolved by removing a problematic code addition. This ensures accurate invoice generation for Peruvian clients.

Original PR description

In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information.

ticket-5193233

Forward-Port-Of: odoo/enterprise#100043

#Peru#UBL#Invoice

[FIX] l10n_uy_edi, l10n_uy_edi_stock: synchronize `l10n_uy_edi.document` with its origin

PR #100320

Enterprisesaas-18.2l10n_uy_edil10n_uy_edi_stockMEDIUM

This update resolves an issue where CFE PDFs weren't being generated correctly for Uruguayan invoices. The fix ensures that the PDF from Uruway is properly linked to the invoice data, allowing users to access and download the required documents. This improves the accuracy of invoice processing for our Uruguayan clients.

Original PR description

### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…

### Issue:
When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway.

### Steps to reproduce:
- Install 'l10n_uy_edi' and switch to an Uruguayan company
- In the Settings change 'UCFE Web Services' to 'Testing' and input credentials
- Create a new invoice, confirm and send, click 'Generate CFE'
- The CFE status is accepted but the PDF from Uruware is not on the record

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set.

In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same.

Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)).

### Solution:
We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`.

opw-5272776

Forward-Port-Of: odoo/enterprise#100128

#uy#edi#invoice#cfe

[FIX] sale_renting: ensure return qty can't exceed pick up qty

PR #100303

Enterprisesaas-18.2salestock

This update fixes a potential issue where rental orders could incorrectly record more returned products than were initially picked up. The change ensures that returned quantities never exceed the quantity originally picked, improving order accuracy and preventing discrepancies in rental accounting. This resolves a previous bug reported by our team.

Original PR description

## Versions
17.0+

## Issue
It is possible to return more products than what has been picked in Rental.

## Steps to reproduce
- Create a service product available for rent;
- Create a rental SO for any partner:
  - Add 5 units of the created service;
  - Confirm the SO;
  - Pickup 5;
  - Return 4;
  - Return 4;
  - Check the SOL containing 5 delivered products and 8 returned products.

opw-5259727

Forward-Port-Of: odoo/enterprise#100015

#rental#returns#inventory

[FIX] l10n_ro_saft: output receivable account for customer

PR #100359

Enterprisesaas-18.2l10n_ro_saft

This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the correct customer receivable account, ensuring accurate reporting for Romanian VAT returns. This resolves a discrepancy identified in previous reports.

Original PR description

### Issue:
In the SAFT report both the Customer and the Supplier have the same account.

### Cause:
In the XML there was probably a typo and both have `property_account_payable_id` as account.

### Solution:
For the `Customers` node, use `property_account_receivable_id`.

opw-5144009

Forward-Port-Of: odoo/enterprise#99196

#reporting#VAT#Romania

[FIX] voip: don't fetch /null on Ringtones.stopPlaying

PR #100217

Enterprisesaas-18.2voip

This update corrects a technical issue where stopping audio playback in the VoIP feature triggered unwanted HTTP requests. The fix resets the audio element's source, eliminating the request and improving performance. This ensures a smoother user experience.

Original PR description

Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null".

This commit fixes the problem by resetting the source using removeAttribute instead.

[Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985)

Forward-Port-Of: odoo/enterprise#100146

#performance#audio#voip

[FIX] documents: restrict unfold of folders

PR #100201

Enterprisesaas-18.2documents

This update resolves an issue where opening a folder within 'My Drive' caused the entire 'My Drive' folder to unfold. Now, 'My Drive' will only unfold when its root folder is opened, improving the user experience and preventing unexpected folder expansions.

Original PR description

Steps to reproduce
===================
- Go to the `All` section.
- Open the folder hosted in the `My Drive`.
- `My Drive` gets unfolded.

To Be
=====
- The` My Drive` folder should not be unfolded when opening folders inside it,
  like `Company`.

Technical
===========
- Earlier, we were sticking to the condition that allows other root folders to
  unfold when we open a folder inside it, except the `Company` folder.

After this commit
==================
- This commit addresses the issue, and now whenever we click on a certain folder
  it will not unfold until its root is unfolded.

Task-5046161

Forward-Port-Of: odoo/enterprise#93718

#folders#My Drive#UI

[FIX] account_reports: prevent traceback when creating an annotation

PR #100321

Enterprisesaas-18.2account_reportsMEDIUM

This update resolves an issue where creating annotations in Arabic language reports would cause errors due to incorrect date formatting. The fix ensures dates are formatted correctly for PostgreSQL, preventing the application from crashing and allowing users to accurately add annotations to their financial reports. This improves the reliability of the reporting system for all users, regardless of their language settings.

Original PR description

Steps to reproduce:
-------------------
1. Install `account_reports`
2. Switch the user language to Arabic
3. Go to Accounting > Reporting > General Ledger
4. Click on the 3-dots  > Annotate
5. Create a new annotation

Issue:
------
A traceback occurs:
```python
psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠"
LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ...
```

Cause:
------
In Arabic locale, Luxon formats dates using the Arabic numbering system,
which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error.

Solution:
---------
Use the Latin numbering system (`latn`) when formatting the annotation date.

Ticket [link](https://www.odoo.com/odoo/project.task/5244656)
opw-5244656

Forward-Port-Of: odoo/enterprise#99493

#reporting#arabic#localization

[FIX] website_knowledge: avoid opening issue for shared articles

PR #100361

Enterprisesaas-18.2website_knowledge

This update resolves a bug where shared Knowledge articles weren't accessible to users when the website had multiple language settings. The fix corrects a URL rewriting issue, ensuring articles appear correctly regardless of the user's preferred language. This improves the usability of our knowledge sharing feature.

Original PR description

## Issue:
When multiple languages are enabled on the website (English + another),
sharing a public Knowledge article may block portal users from accessing it
For example, if the website’s default language is Spanish and the user opens the link,
they are redirected to the home page and the article does not appear in the sidebar

## Cause:
When accessing `/knowledge/article/...`, the `_match` route handler automatically
rewrites the URL to `/en/knowledge/article/...`
However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid
As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page

## Steps to reproduce:
- Install Knowledge and Knowledge Website
- Set Spanish and English (US) as available website languages
- Set Spanish as default website language
- Create an article in knowledge
- Click Share and activate "Share to web"
- Copy the link and open it in a private window (The article should be visible)
- Log in as a Portal user
- Open the link
- The user is redirected to the home page and the article is missing from the sidebar

opw-4916118

Forward-Port-Of: odoo/enterprise#96505

#knowledge#website#sharing#language

[FIX] mrp_workorder: assign correct employee on work order completion

PR #93378

Enterprisesaas-18.2mrp_workorderMEDIUM

This update fixes an issue where time logs were incorrectly assigned to the current user instead of the assigned employee when marking work orders as complete. This ensures accurate tracking of labor hours and eliminates user confusion regarding who is working on each order. The fix improves data integrity and reporting accuracy.

Original PR description

## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the…

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

#work order#time tracking#employee assignment

[FIX] pos_settle_due: reconcile only with partners

PR #100132

Enterprisesaas-18.2pos

This update ensures that invoice lines are reconciled with the correct partner during point-of-sale transactions. Previously, reconciliation could incorrectly link invoices to different partners, leading to inaccurate reporting. This fix improves the reliability of sales data and reconciliation processes.

Original PR description

Invoice lines to be reconciled are not tailored to the single partner while the session lines do.
That can cause reconciliation to happen between different partners.

Backport of https://github.com/odoo/enterprise/pull/100131

task-5346644

#pos#reconciliation#accounting

[FIX] l10n{cl_edi,br_edi}_pos: fix tour tests

PR #100311

Enterprisesaas-18.2l10n_cl_edi_posl10n_br_edi

This update resolves an issue where the company name used in tour tests for the l10n{cl_edi,br_edi}_pos modules was incorrect. This fix ensures that tour tests run properly and accurately reflect the company's information, improving the reliability of the testing process.

Original PR description

There was an error in the generic hooks, the company name was not the correct one.

runbot-234336

#localization#pos#testing

[FIX] account_reports: show settings when closing won't have right bounds

PR #100464

Enterprisesaas-18.2account

This update streamlines account reporting settings for users in specific countries, ensuring relevant options are displayed based on their reporting needs. Previously, users had to manually determine acceptable fiscal year settings, which has now been automated to prevent confusion and ensure accurate reporting.

Original PR description

We're adding several countries to the settings, each time a user from this country has specific fiscal year and does non-monthly reporting. 
It's cumbersome, as we have to know in which country it's acceptable.

At the same time, we don't want to show a setting if it's useless to the user. 
It will just confuse him.
So, we should show this setting as soon as the report will complain:
- If it's monthly and he does not start at the beginning of the month.
- If he does non-monthly and does not end on 31st of December.

We could be even more selective and also compute which months would be valid if in quarterly and other modes but we think it's fine for these cases.

Forward-Port-Of: odoo/enterprise#100181

#reporting#fiscal year#settings

[FIX] pos_self_order_iot: restrict kiosk to only configured payment methods

PR #89490

Enterprisesaas-18.2pos_self_order_iot

This update ensures kiosks only utilize payment methods explicitly configured for that device. Previously, kiosks would incorrectly prompt for unavailable payment options, leading to a poor user experience. This fix prevents errors and improves the kiosk's functionality by restricting payment method selection.

Original PR description

Ensure the kiosk only uses payment methods that are explicitly configured.

**Steps to reproduce:**
- Set up an online payment method (do not assign it to the kiosk)
- Open a kiosk session.
- Try to validate an order.

**Issue:**
- The kiosk prompts for an online payment method, even though none are configured.

**Fix:**
- Prevent loading of any unconfigured payment methods to the kiosk.

Task: 4911495

Related: https://github.com/odoo/odoo/pull/217467

#payments#kiosk#pos

[FIX] l10n_*_reports: auto-activate ec sales list report menu item

PR #100360

Enterprisesaas-18.2accountreports

This update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving user experience.

Original PR description

In this PR:
-  Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation.

Task-4885725

Forward-Port-Of: odoo/enterprise#93939

#reporting#EU#localization

Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653

Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button - Click on the "Accounts Coverage Report" Observation: - we receive a traceback ``` psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d" LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance... ``` Cause: - few records used a wrong format style for values of `domain_formula` - These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is. - when browsing account.tag record using these domain, record ids were expected, instead we got its string representation , causing traceback https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680 Fix: - we fix the data file, which is properly evaluated and stored in database. - Manifest's data file order is changed, so that account tags is loaded first. opw-5224114 Forward-Port-Of: odoo/enterprise#98745

Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052 Forward-Port-Of: odoo/enterprise#100301

Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375

In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043

### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776 Forward-Port-Of: odoo/enterprise#100128

## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100015

### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196

Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146

Steps to reproduce =================== - Go to the `All` section. - Open the folder hosted in the `My Drive`. - `My Drive` gets unfolded. To Be ===== - The` My Drive` folder should not be unfolded when opening folders inside it, like `Company`. Technical =========== - Earlier, we were sticking to the condition that allows other root folders to unfold when we open a folder inside it, except the `Company` folder. After this commit ================== - This commit addresses the issue, and now whenever we click on a certain folder it will not unfold until its root is unfolded. Task-5046161 Forward-Port-Of: odoo/enterprise#93718

Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493

## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505

## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the current user’s employee instead of the assigned one. This behavior caused confusion for the user as the wrong person was shown as working on the order. ## **Steps to Reproduce:** - Create an MO with work orders and confirm it. - Assign another employee to a work order. - Mark the work order as done with the current user from the work order line. - Open the workorder and notice that the time log is created for the current user’s employee. ## **Cause of the Issue:** The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790), where the logic for assigning the main employee was overridden, ignoring the case of an already assigned employee. ## **With This Commit:** The time log is now created for the assigned employee, This resolves the confusion by ensuring the right person is tracked on the work order. TaskID: 4983514

Invoice lines to be reconciled are not tailored to the single partner while the session lines do. That can cause reconciliation to happen between different partners. Backport of https://github.com/odoo/enterprise/pull/100131 task-5346644

We're adding several countries to the settings, each time a user from this country has specific fiscal year and does non-monthly reporting. It's cumbersome, as we have to know in which country it's acceptable. At the same time, we don't want to show a setting if it's useless to the user. It will just confuse him. So, we should show this setting as soon as the report will complain: - If it's monthly and he does not start at the beginning of the month. - If he does non-monthly and does not end on 31st of December. We could be even more selective and also compute which months would be valid if in quarterly and other modes but we think it's fine for these cases. Forward-Port-Of: odoo/enterprise#100181

Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/odoo/pull/217467

In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939