Daily updates from Odoo
Sunday, January 18, 2026
12 changes · master
Resolved issues and error corrections
This update resolves a critical issue where Odoo installations didn't consistently create foreign key relationships in the database. This resulted in 'Record missing' errors appearing after data changes, potentially causing significant disruptions. The fix ensures Odoo installs with properly configured foreign keys, improving database stability and preventing these unexpected errors.
Original PR description
---- Description of the issue/feature this PR addresses: See related OPW Ticket [opw-5495025](https://www.odoo.com/my/tasks/5495025) Current behavior before PR: Odoo seems to install correctly, and works normally. However the database consistency is not ensured. Foreign Keys are not created. User receives `Record missing` errors after some time, when there was a Contact deleted, for example. Issue is dangerous, because it can be latent and be undetected for weeks or months. Desired behavior after PR is merged: Odoo installs *with* the Foreign Keys, and works normally. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr --- Ticket opw-5495025 Forward-Port-Of: odoo/odoo#243833
This update fixes an issue where sale warnings weren't showing when set on a company contact instead of an individual contact. The change ensures that all sale warnings, regardless of whether they're linked to a company or individual, are now correctly displayed to users. This improves sales process visibility and accuracy.
Original PR description
### Issue: Due to this issue, the sale warning message is only shown when the warning message is set on partner itself, not partner's company. #### Steps to reproduce (with demo data): 1- Enable `Sale warnings` from setting. 2- On `Contacts` app, open `Azure Interior`, and add a sale warning from `Notes` tab. 3- Create a SO with `Brandon Freeman` from `Azure Interior` as the customer. 4- No sale warning is shown. ### Cause: The IMP #192211 replaces warning popup with a message. However, it doesn't check for the warning from `partner_id.parent_id`, which was the case before that PR. This is the case with purchase as well. opw-5404983 Forward-Port-Of: odoo/odoo#242050
This update fixes an issue where loyalty points weren't being calculated correctly after discounts were applied in the POS system. The change ensures that loyalty rewards are accurately reflected in the customer's account, regardless of discount percentages. This improves the customer experience and ensures accurate reward tracking.
Original PR description
Step To Reproduce: - create a loyalty of type "loyalty card", that grants 1 point per $ spent - configure pos for global discounts - start pos, select a product (say price_with tax is 100) - select a…
Step To Reproduce: - create a loyalty of type "loyalty card", that grants 1 point per $ spent - configure pos for global discounts - start pos, select a product (say price_with tax is 100) - select a customer - apply a discount of 10%, price should be 90 refer image <img width="1367" height="687" alt="image" src="https://github.com/user-attachments/assets/37709299-b377-4eee-95af-e857b19c7671" /> Observation: - the loyalty gained stays 100, even after we applied discount, it should be 90 <img width="257" height="587" alt="pos loyalty issue" src="https://github.com/user-attachments/assets/772821c2-dc06-4dfc-8d4c-ab00de209ce8" /> Cause: - the recent commit [1], `applyDiscount` uses `addLineToOrder`, which bypasses `addLineToCurrentOrder`. - This skips `updateRewards` and other module-level extensions defined on `addLineToCurrentOrder` [1] https://github.com/odoo/odoo/commit/b63c7c28cfe6d59888982d58b8e9d99ea62281f4 https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/pos_loyalty/static/src/app/services/pos_store.js#L439-L448 Fix: - Replace `addLineToOrder` with `addLineToCurrentOrder` to ensure rewards and programs are properly updated opw-5437844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243548 Forward-Port-Of: odoo/odoo#242740
This update speeds up product searches within Point of Sale, making the system more responsive, especially when dealing with a large number of products. The changes optimize how products are searched and sorted, reducing delays and improving the user experience. This enhancement focuses on performance improvements within the POS module.
Original PR description
Previously, the product search performed normalization inside the filter and sort loops. Because sort algorithms perform O(n log n) comparisons, the `normalize` function was called redundantly thousands of times for the same product, leading to UI lag when handling large products. This commit optimizes the search by: - Moving normalization to the model getters - Flattening the template search string to include all variants, removing the need for nested `.some()` loops during filtering. - Replacing `localeCompare` with primitive string comparison for faster sorting. opw-5448113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241668
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. By converting component costs to the invoice currency, this fix ensures accurate price difference calculations and reliable reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243941 Forward-Port-Of: odoo/odoo#238428
This update resolves a bug where imported sales orders containing kit products were incorrectly splitting the order into multiple lots during the POS process. The change prevents this splitting behavior when a kit product is sold, ensuring accurate order processing and a smoother POS experience. This was a critical fix to avoid errors in sales transactions.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update resolves a problem where clicks within editable lists were unintentionally triggering unwanted actions. A new feature allows developers to 'ignore' clicks on specific list elements, ensuring the correct focus and functionality is maintained when editing data. This improves the overall user experience for working with lists.
Original PR description
Since commit 37d78a4, the global click listener sets `capture: true`, which prevents other components to stop the propagation of the click event in order to maintain the focus on the selected list element. This commit introduces a special data key that can be set on an element so that any click occurring within it will be ignored by the list renderer. task-none but necessary for https://github.com/odoo/enterprise/pull/103732 Forward-Port-Of: odoo/odoo#243107
A recent update caused a crash when users clicked on boxes within x2many fields. This was due to a change in how click events were handled, leading to the system expecting the field to be in edit mode when it wasn't. This fix resolves the crash and ensures stable editing of these fields.
Original PR description
Since commit odoo/odoo@37d78a4, a crash would occur when clicking on a box while a field of a x2many field was focused.
The commit mentionned above changed the order in which the click event handlers are called because of the addition of `{ capture: true }` on the list renderer click listener.
Before, the propagation of the click event was stopped at the box layer level, preventing it to reach the global listener of the list renderer and thus keeping it in edit mode.
After, the click listener of the list renderer is executed first, which means we leave the edit mode before executing the click listener of the manual correction component. This causes a crash as the list renderer is expected to be in edit mode to be able to fill in the value.
task-none
Forward-Port-Of: odoo/enterprise#103732This update fixes a usability issue in the Sign editor where the document dropdown didn't close correctly after selection. The changes include improved hover behavior, consistent styling for actions, and a fix to handle interactions within the PDF iframe, ensuring a smoother user experience.
Original PR description
- Fix hover and pointer behavior on update document action - Apply consistent danger styling to delete action - Ensure dropdown closes correctly after interaction (PDF iframe has its own document so outside-click logic did not apply; add a click listener on the iframe document to close open dropdowns. ) task: 5384677 Forward-Port-Of: odoo/enterprise#102447
This update resolves a technical problem where order data wasn't being saved correctly in the Sweden POS module. The fix involves renaming related fields in the user interface to ensure data is properly recorded in the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104393 Forward-Port-Of: odoo/enterprise#104180
This update resolves a problem where Odoo invoices for exports were being rejected by the SII system due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential issues with tax authorities.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update restores automatic follower copying from parent sales orders to subscription renewals and upsells in Odoo 18.2. This ensures that users associated with the original order are automatically included in subsequent subscription orders, streamlining sales processes and improving customer management. This change specifically addresses a previous restriction on automatic follower copying.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181 Forward-Port-Of: odoo/enterprise#101088