Daily updates from Odoo
Wednesday, December 17, 2025
17 changes · 18.0
Resolved issues and error corrections
This update fixes alignment issues within the partner record form and improves the user experience by hiding the 'MyInvois' tab when it's not relevant – specifically, for journal entries related to sales or purchases. This ensures that users only see the most pertinent information, streamlining their workflow.
Original PR description
This commit: - Fixes alignment of the `MYINVOIS INFORMATION` section on the partner form. - Hides the `MyInvois` tab on journal entries where journal type is neither `sale` nor `purchase`. task-5356808 Forward-Port-Of: odoo/odoo#239837
This update ensures that downpayment lines in the l10n_my_edi_extended module consistently use a specific classification code ('022') for reporting purposes. This change maintains accurate accounting and tax reporting by standardizing the classification of downpayment transactions, while other product lines continue to use their standard product-based classifications.
Original PR description
Ensure downpayment lines are assigned a fixed classification code ("022"), while other lines retain their product-based classification.
Task-5356913
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update refines how EDI participants are registered within Odoo, specifically targeting localization-specific EDI integrations (MyEDI and Italian EDI). The change ensures that errors related to duplicate registrations are resolved, streamlining the process for users working with these localized EDI systems. This improves reliability and reduces potential registration issues.
Original PR description
This commit removes the `unique_active_edi_identification` constraints from the _auto_init of `account_edi_proxy_client` client user model, and adds back the constraint on `l10n_my_edi` and `l10n_it_edi` to make it apply only to those localizations. task-4852830 Forward-Port-Of: odoo/odoo#224811
This update fixes a technical issue impacting how appointment URLs are generated, leading to improved search engine optimization (SEO) for appointment pages. Previously, the appointment type slug wasn't correctly reflected in URLs, now it is, and users can also adjust the slug for appointment types. This enhances visibility and accessibility for appointments.
Original PR description
This PR replaces the appointment type's id by the slug of this one in the appointment URLs. This allows a better SEO for the appointment pages and users to change the slug of the appointment types too. Previously the slug was not replaces by the value entered in the Cutsom Url field of the Optimize SEO form, this is not longer the case. Community PR: https://github.com/odoo/odoo/pull/231609 Task-5114394
This update fixes a bug in the sales reporting module that was incorrectly calculating profit margins. The fix involves adjusting the calculation formula to ensure accurate margin figures are displayed when using multi-currency pricelists. This ensures sales reports accurately reflect profitability.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost…
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost price (300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation ( for TWD currency , multiply with currency rate) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Before <img width="687" height="97" alt="image" src="https://github.com/user-attachments/assets/3a821a5c-eb12-4eae-9465-1702e9d4ac97" /> After <img width="679" height="110" alt="image" src="https://github.com/user-attachments/assets/d62dbb1d-6839-4099-90b1-6f9a19576721" /> opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where assigned values in Many2one fields within project tasks would disappear after saving the changes. The fix ensures that data is correctly handled during the saving process, preventing data loss and maintaining accurate task information. This improves data integrity and user experience.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that previously caused errors during BIS3 invoice generation when reverse charge accounting was used. The change ensures invoices are correctly formatted and processed, preventing disruptions in financial reporting and compliance. This improves the reliability of our account receivable processes.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where videos added to product descriptions in the website editor would disappear after saving. The fix prevents the system from automatically clearing video elements from the description, and includes a setting to prevent video formatting issues in the backend for version 18.0.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Open website editor on a product page;
2. edit the ecommerce description;
3. add a video using the `/video` command;
4. save & close editor.
Issue
-----
The video disappears.
Cause
-----
The `write` override in `website_sale` uses the `is_html_empty` method to clear "empty" descriptions. When adding a video, it gets added as a `<div data-oe-expression="URL" class="media_iframe_video"></div>` element, i.e. an "empty" `div` element according to `is_html_empty`, hence getting cleared on write.
Solution
--------
In the `write` override, don't clear the ecommerce description if it contains "media_iframe_video".
Also, for 18.0, add `options="{'embedded_components': false}"` to the product view in the back-end to disable adding video there, as it gets formatted in a way that isn't supported by the front-end. For 18.2, this was already done in 6339f261e7161.
opw-5218018This update fixes a rounding issue in the sale timesheet module that was causing inaccurate remaining time displays on Sales Orders. The fix eliminates intermediate rounding to ensure precise hour calculations, preventing discrepancies and providing correct time overages. This improves the accuracy of sales reporting.
Original PR description
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order…
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order Line - Log 22:00 on timesheets Current behavior: Sales Order Line shows '-2:01 remaining' Expected behavior: Should show '-02:00' to reflect two hours overconsumed without rounding. Root cause: Python's float type follows the IEEE 754 double-precision standard, where only base-2 fractions can be stored precisely. Base-10 fractions cannot be represented exactly, introducing tiny rounding errors. During chained operations such as multiple conversions or subtractions, these small errors accumulate into larger discrepancies. The float_round() function uses a small constant epsilon to correct rounding noise, but as arithmetic chains grow, errors exceed epsilon's tolerance and it can no longer correct them. Since a single global epsilon cannot handle every case (small vs. large values, chained vs. single operations, or regressions), rounding drift is inevitable when rounding happens repeatedly. Fix: To prevent these rounding errors from compounding, the solution is to stop intermediate rounding altogether. By using conversions with round=False, all arithmetic is done in the base unit (hours) with full float precision, and rounding is applied only once when displaying the final value. This eliminates error accumulation and ensures consistent, drift-free results. task-5090240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229282
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this functionality due to a minor difference in how context information was passed. This change streamlines the rental order process and improves data consistency.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941 Forward-Port-Of: odoo/enterprise#102220
This update resolves an issue where ECO applications incorrectly linked product documents to attachments, leading to database errors. The fix ensures attachments are correctly associated during ECO application, preventing potential data inconsistencies and application failures. This improves the reliability of ECO processes.
Original PR description
When applying an ECO, the system incorrectly sets the origin_attachment_id of a product.document to a product.document record itself instead of its related ir.attachment. As a result, if the incorrectly referenced ir.attachment is missing, the ECO will attempt to reference a record that does not exist, leading to a foreign key violation during action_apply. Steps to reproduce: 1.) Create an mrp.eco record 2.) Upload a document, take note of the product.document ID 3.) Unlink the ir.attachment with ID = (document ID + 1) (+1 is to account for the .copy within action_apply) 4.) Run eco.action_apply 5.) Observe SQL Constraint Expected result: The ECO should correctly link the product.document to its related ir.attachment. Actual result: origin_attachment_id may point to an unrelated ir.attachment, causing constraint violations when those attachments do not exist. opw-5050263
This update fixes a potential memory error that could occur when installing the new 'account_no_followup' module in Odoo 18. The fix avoids a large data calculation that previously overloaded the system's memory. This ensures smoother module installations and prevents potential performance slowdowns.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue.
This update addresses a bug fix within the Odoo spreadsheet component. Specifically, it prevents the spread of empty matrices, improving data accuracy and stability. Multiple developers collaborated on this release, ensuring a robust update for the 18.0 version.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3d9063cb7f [REL] 18.0.52 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c4c51c062c [FIX] evaluation: do not spread empty matrix [Task: 5421196](https://www.odoo.com/odoo/2328/tasks/5421196) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects a bug where archived employees were still appearing in the timesheet section of helpdesk tickets. The fix ensures that timesheets are only populated with active employee data, improving data accuracy and preventing confusion. This resolves a potential issue with reporting and data management.
Original PR description
**Steps to Reproduce:** - Install hekpdesk_timesheet. - Go to settings, enable timesheets - Archive an employee. - In a ticket, try to add a timesheet entry. **Isuue:** Archived employees are also appearing under timesheets tab. **Fix:** Passed a context so that only active employees appear in the selection. task-5078763
This update fixes a technical issue where the HTML Editor was incorrectly accumulating local overlays, leading to potential performance problems. The fix ensures that these overlays are properly cleared when the Editor and its associated plugin are removed, resolving a bug introduced after a website refactor. This improves the stability and performance of the HTML Editor.
Original PR description
This commit ensures that local overlays are correctly removed when the Editor and `LocalOverlayPlugin` are destroyed. Steps to reproduce (observable after 18.4): - Go on website - Enter edit mode - Save - Repeat entering edit mode and saving - Inspect the DOM: oe-local-overlay elements keep accumulating, only one is non-empty The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. task-5380409
This update simplifies the TDS tax warning displayed in the withholding process. It now automatically alerts users when a vendor’s PAN (tax identification number) is missing, focusing on the core purpose of collecting this information. Removing the rate-based check ensures a clearer and more consistent warning message.
Original PR description
Simplified the condition to show warning whenever the partner’s PAN is missing in the TDS entry wizard, instead of checking for lower TDS rate. The warning’s purpose is only to alert users to collect PAN from vendors, so rate based check was removed. task-5245353 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where currency rates for non-UYU currencies were incorrectly dated, leading to inaccurate tax calculations. The change ensures all currency rates are synchronized with today's date, resolving a previous error and improving data accuracy for UYU and other currencies.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065