Daily updates from Odoo
Monday, December 22, 2025
11 changes · master
Resolved issues and error corrections
This update resolves an issue where website subscription tours weren't working correctly after changes to the search bar. The fix adjusts the tour selectors to account for updated search results, ensuring tours now function as expected for users. This improves the overall user experience for subscription sign-ups.
Original PR description
Purpose: - Adapt tours to work without :first-style selectors, since our changes altered the number of search results and the original selectors can no longer locate the expected elements. community: https://github.com/odoo/odoo/pull/236245 task-5264301
This update resolves an issue where a technical error (traceback) occurred when generating tax reports for companies not based in Belgium. The fix ensures the system correctly handles VAT numbers from other countries, preventing errors and improving the reliability of tax reporting. This ensures accurate tax calculations for all company types.
Original PR description
**Steps to reproduce:** 1. Go to Companies and set a non-BE VAT on the current company, e.g., `US12345678` 2. Go to Accounting → Configuration → Fiscal Positions. 3. Create a new Fiscal Position and set the country to Belgium. 4. Enter a valid Foreign Tax ID, e.g.,` BE0477472701`, and save. 5. Create the taxes. **Issue:** A traceback is raised: `ValueError: invalid literal for int() with base 10: 'US12345678'` **Cause:** This happens because `_be_company_vat_communication` attempts to parse the company's VAT number even when the company does not belong to BE, resulting in invalid VAT formats such as "USxxxxxxx". **Solution:** Return an empty structured communication unless: - the VAT is valid, and - the detected country code is BE, and - the fiscal country is Belgium. This prevents parsing foreign or invalid VATs and avoids the traceback during foreign tax generation. **opw-5368016** Forward-Port-Of: odoo/enterprise#101648
This update fixes an issue where sharing a document via link wouldn't automatically open the preview when the user's default view was the list view. Now, the preview opens correctly, similar to the kanban view, ensuring a consistent and user-friendly experience when accessing shared documents.
Original PR description
Bug === If the user has the list view as his default view, if we share him a document, the preview is not opened. After this commit, the preview is opened like in the kanban view, and the document is selected. Task-5361212 Forward-Port-Of: odoo/enterprise#102598 Forward-Port-Of: odoo/enterprise#100716
This update resolves a problem preventing a demo tour from running correctly. The issue stemmed from a duplicate job entry in the demo data, causing incorrect matching. Additionally, a minor correction was made to a job name to ensure proper tour execution.
Original PR description
- fixing tour `hr_contract_salary_tour_sign_again`which was failing with demo data because another job was installed in the demo data with name Experienced Developer so it was matching with it instead of the correct job position - note that the job is renamed from `Experienced Developer (BE)` to `Experienced Developer BE` because the closing bracket wasn't written correctly (framework issue most likely) so it was written as `Experienced Developer (BE` task-id: 5413364
This update fixes a crash that occurred when generating work entries for employees who don't have a resource calendar (fully flexible). The fix ensures accurate unavailability intervals are created, preventing errors when opening work entry or payroll modules. This improves stability and functionality for all employee types.
Original PR description
Steps to reproduce: - Install hr_work_entry - create an active employee with a running contract and no resource calendar(fully flexible) - try to open work entries/payroll - you get a traceback because of `_gantt_unavailability` Current behavior: - when the employee is flexible, the unavailability is set to an empty interval without accessing the calendar(that doesn't exist) - added `test_gantt_unavailability` to check if the unavailability intervals of employees are generated correctly task-id: 5408752
This update fixes an issue where the price displayed on Italian POS receipts for multiple product purchases was incorrect. The fix ensures that the unit price, rather than the total line price, is used when generating the receipt. This guarantees accurate pricing for customers using the Italian POS system.
Original PR description
Currently, when buying multiple quantities of the same product, the unit price value sent to the italian printer is incorrect. Steps to reproduce: ------------------- * Set up italian printer for one shop * Open shop * Add a product to the order with a qty 3 and a price unit of 1 * Pay the order * Print italian receipt > The price total for the 3 product says 9 instead of 3 Why the fix: ------------ When computing the order lines details we were using `total_included` for the unit price which takes into account the quantity. Per definiton, it's not the price for 1 unit. opw-5404877 Forward-Port-Of: odoo/enterprise#102457
This update resolves an issue where document previews were not updating correctly after renaming documents. Previously, the preview displayed the old attachment name even after a successful rename. This change ensures that document previews always reflect the latest document name, improving data consistency and user experience.
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#101919
Forward-Port-Of: odoo/enterprise#95111This update resolves an issue where users were encountering errors when creating reports in web_studio. Specifically, it prevents the generation of invalid field nodes within the report templates, ensuring reports render correctly. This improves the overall reliability and usability of the report design tool.
Original PR description
cf commit Forward-Port-Of: odoo/enterprise#102311 Forward-Port-Of: odoo/enterprise#99385
This update corrects a previous issue where newly created serial numbers within the Barcode app were automatically assigned to the current company. This prevented the use of these serial numbers across different companies. The fix removes the automatic company assignment, allowing serial numbers to be used flexibly across all company environments, aligning with current Odoo functionality.
Original PR description
## Context In the barcode app (`stock_barcode`), users can update inventory counts by scanning a product's barcode or by manually entering the barcode. ## Issue When the barcode is entered manually,…
## Context In the barcode app (`stock_barcode`), users can update inventory counts by scanning a product's barcode or by manually entering the barcode. ## Issue When the barcode is entered manually, the lot/serial number is created with the *Company* field set to the current company. This causes issues when working with intercompany flows, because lots with a company assigned cannot be used by other companies. This behavior is also inconsistent with the other ways of updating a company's inventory. In fact, the following flows create serial/lot numbers with no company assigned: - Inventory / Products / Products / *Forecasted Report* or *On Hand* - Inventory / Operations / Adjustments / Physical Inventory - Barcode / Inventory Count / Add product (add the serial number from the *Inventory Count* screen, **not** by clicking on the cogwheel in the top-right corner) ## Cause The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34. At the time, that behavior was consistent with the backend behavior, as the `company_id` of a lot/serial number would always be set to `self.env.company`. In fact, the feature allowing a lot/serial to be shared among multiple companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69). This last commit adds a compute method for the `stock.lot.company_id` field: https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136 Since then, lot/serial numbers shouldn't be created with a `company_id`, as this restrict other companies to use those numbers. Users can always add a company to a lot/serial number later if necessary. ## Solution The line assigning a `company_id` to the `stock.lot` can be removed, as it does not reflect the current behavior (saas-17.2+). Nowadays, a `company_id` should be set **only** if the user wants a lot/serial number to be used by a specific company; it should not be the default behavior. ## Steps to reproduce 1. Install *Barcode* (`stock_barcode`). 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. In Settings / Users & Companies / Companies, create a second company. Use either company for the following steps. 4. Create a product tracked *By Unique Serial Number*. 5. Open the Barcode app, then click *Inventory Count*. 6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*). 7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*. 8. Go to Inventory / Products / Lots / Serial Numbers. 9. The serial number created from the Barcode app is assigned to the current company. opw-5264216 Forward-Port-Of: odoo/enterprise#102130
This update clarifies the Odoo Enterprise interface by renaming a menu item to 'Unrealized Currencies'. Previously, duplicate labels caused confusion, and this change ensures users are directed to the correct section for managing unrealized currency positions. This improves clarity and usability.
Original PR description
Previously, there were two menu items named `Currencies`: one under Review and another under Configuration, which caused confusion. The one under Review was incorrectly labeled, it should have been `Unrealized Currencies`. This **PR** renames the menu item under Review to `Unrealized Currencies` to reflect its actual purpose. **task**-5169637 Forward-Port-Of: odoo/enterprise#97356
This update resolves a problem with the layout of Chile's invoice PDF reports. Previously, the PDF displayed incorrectly with text wrapping vertically and overflowing. The fix ensures proper alignment by adding a width constraint to the report's layout, improving readability and preventing formatting errors.
Original PR description
Steps to reproduce: 1. Install l10n_cl_edi. 2. Create an invoice with a customer having a Chile address. 3. Print "Invoice PDF copy (Chile)". Issue: The PDF layout is broken: some text is rendered vertically and the content overflows across multiple pages. Cause: The footer right column row did not have an explicit width, causing wkhtmltopdf to shrink the container and wrap text letter by letter. Fix: Set w-100 on the inner row to stabilize the layout and prevent vertical text rendering. Before Fix : <img width="408" height="313" alt="image" src="https://github.com/user-attachments/assets/1d61412d-cfd3-48df-a4d4-eabd10df4865" /> After Fix: <img width="409" height="320" alt="image" src="https://github.com/user-attachments/assets/3a098227-7e43-44f0-9266-b4b0023f382c" /> opw-5348151 Forward-Port-Of: odoo/enterprise#102111