Daily updates from Odoo
Monday, October 6, 2025
12 changes · 18.0
Enhancements to existing features
Belgian partner lookups on the Peppol network now check the two most commonly used identifier types, improving the chance of finding the right participant. The update also removes outdated warnings about recommended identifiers because the mandatory identifier handling is now managed automatically by the access point service.
Original PR description
1. For belgian partner, we now check for 0208 and 9925 which are the two most used EAS when looking for partner existence on the Peppol network. 2. Remove the warnings about the recommended EAS: 0208 is now the mandatory EAS, this will be handled directly on IAP where the Peppol Access Point will try to register 0208 in all cases with an alias system. Note that we have always computed 0208 as recommended value in registration process. task-4852903 Forward-Port-Of: odoo/odoo#227431
Resolved issues and error corrections
Publishing and sending planning shifts from the Gantt view now respects the filters the user already applied, such as a specific role, while still updating the selected date range. This prevents unintended shifts outside the filtered selection from being included, making planning publication more accurate.
Original PR description
To reproduce: ============= -Reset all planning.slot to draft -Search "Dev" role -In weekly Gantt view, click on publish & send -Change date to match the current month (or any other period) -Publish Problem: ========= We filter only by datetime and ignore domain from context : https://github.com/odoo/enterprise/blob/20b45f6c65c78a572a3f26b78f6ed458accf7c9f/planning/wizard/planning_send.py#L31-L33 Solution: ========= - Get active domain from context and override only it's date_time since it changed. opw-5017014 Forward-Port-Of: odoo/enterprise#93295
This fixes an issue where Point of Sale pricelists with start and end times on the same date were not applied correctly. Businesses can now rely on time-limited pricing, such as daily promotions or happy-hour pricing, to show the correct price in POS after refreshing when the time window changes.
Original PR description
Pricelist that have a start and end datetime that are the same day but with different hours were not correctly applied in the POS. Steps to reproduce: ------------------- * Create a pricelist with a start datetime of 2025-01-01 08:00:00 and an end datetime of 2025-01-01 18:00:00. * Create a product and assign it to the pricelist with a fixed price. * Add the pricelist to the PoS config. * Open a session and select the pricelist. * Add the product to the order > Observation: The price is not correctly applied. Note: ----------- To update the pricelist when the datetime has been crossed the user will need to refresh the PoS. opw-4934183
This fixes a checkout issue where Google address suggestions could fail or miss key address details because Google does not always list address types in the same order. The update selects recognized address information more reliably and adds support for postal towns used in some countries, improving address completion for online shoppers.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I…
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I haven't been able to reproduce it myself, but others have. > It appears that the order Google provides place types isn't always the same. Issue ----- You may get a `KeyError`, trying to fetch `standard_data['country']`. Cause ----- The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`. The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1]. For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it. [^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types Solution -------- 1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING` 2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning. 3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden. opw-4880651
Gantt view group headers now keep the right size so they remain visible and aligned while users scroll. This prevents layout issues, especially on mobile screens where headers can otherwise become wider than the display.
Original PR description
Gantt group headers could stop being sticky because their width was fixed based on the number and size of columns. Even though they were set to position: sticky, oversized headers could no longer remain aligned when scrolling, as they extended beyond the viewport and were constrained by the document width. This was especially noticeable on mobile, where group headers are often wider than the screen. The fix applies a max-width style to these headers, capping their size to the available space so they remain sticky without overflowing the document. task-4970992
Payments using SEPA direct debit mandates now correctly verify whether a mandate is still valid. This prevents valid future-expiring mandates from being rejected due to an incorrect date comparison.
Original PR description
The check to ensure that the mandate used in a token payment is still valid had two issues: - It was comparing a date (the mandate's end date) with a datetime. - It was incorrectly rejecting mandates expiring in the future, while it should have done the opposite. Forward-Port-Of: odoo/enterprise#96143
Manufacturing orders for finished products now correctly include the operations defined on a selected kit variant. This prevents missing production steps when a kit component has variant-specific work instructions, helping teams follow the right process on the shop floor.
Original PR description
### Steps to reproduct: - Create 2 products: Final Product (FP), Kit Product (KP) - On KP add a Color attribute with 2 values: Blue, Red - Create a KIT bom for KP wtih 2 operations: - OP: paint it…
### Steps to reproduct:
- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
- OP: paint it Blue, apply on Color: Blue
- OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
- 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom
### Cause of the issue:
Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.
opw-5080856
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228032Spanish point-of-sale orders now keep the cashier’s selected tax setup when an order is validated. This prevents incorrect tax amounts from appearing as change on receipts when the default tax position was intentionally changed.
Original PR description
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- *…
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- * Install l10n_es_pos, switch to es company * In the config of a shop, use fiscal position, set some as available, one as default * Open shop session * Add a product that has taxes * Switch fiscal position to one that has 0% taxes * There should not be taxes in the cart at this point * Go to pay the order (cash or bank) > Observation: On the receipt the previous tax value is counted as change Why the fix: ------------ The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929 The fiscal position is updated with the partner's fiscal position or the default one if none on the partner. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995 Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp. opw-5051231
Early payment discount loss lines are now correctly created for each partner when reconciling batch payments. This prevents discounts from being grouped under only one partner, improving the accuracy of accounting entries.
Original PR description
Steps: - create two invoices with a different partner (epd + no tax on the lines) - register for each a payment (payment method with no outstanding account) - select the two payments and create a batch - create a transaction with an amount equal to two payments (discounted amount) - reconcile it with the batch payment Issue There is only one epd discount loss line for one partner Cause: in https://github.com/odoo/odoo/blob/ecb4de3fea463d6524bb2aab8d2388c679dc2ed7/addons/account/models/account_move.py#L4638 The two lines share a common grouping dict key with the same `account_id`. `setdefault` returns the value if the key is existing. opw-5057109
Users who can print and send SEPA direct debit mandates can now also generate, send, and later access the related PDF attachments. This resolves a permission issue that blocked some authorized users from emailing mandate documents or viewing attachments they had created.
Original PR description
Removing the groups restriction from the `mandate_pdf_file` field in model `sdd.mandate` because it was causing issues when using the `sdd.mandate.send` wizard. Any user who has access to the `sdd.mandate` model can use this wizard to print and send the record. During this process, the system generates a PDF and stores it in the `mandate_pdf_file` binary field, linking the resulting attachment to the record. The previous group restriction prevented users who were not part of the `account.group_account_readonly` group from sending the email with the attachment. Even if the email was somehow sent, those users still couldn’t access the attachments they themselves had generated and sent. With this change, any user who is allowed to send and print `sdd.mandate` records will also be able to generate and later access the corresponding attachments.
Fixes an issue where removing formatting from a colored table cell could trigger an error and interrupt editing. The editor now handles table-level colors correctly so users can clear formatting without the page becoming stuck.
Original PR description
Problem: When having a `table` with `color` and selecting a cell to remove format, we get a traceback: "Infinite Loop in removeAllColor()." Cause: The color is applied on `table`, but we only process `td` for color removal. As the color remains on `table`, each attempt to remove it keeps reapplying, leading to an infinite loop. Solution: When removing color, also remove it from the `table`. Then apply the color to all child `td`. This ensures `td` colors are later removed automatically if selected, avoiding the loop. Steps to reproduce: 1. Add a `color` property to a `table` and `td`. 2. Select the `td`. 3. Click "remove format" from the toolbar. 4. Observe traceback. opw-5112088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale loyalty orders now only earn points when they meet the program’s configured eligibility rules, such as minimum item quantities. This prevents customers from receiving unintended points or losing excessive points when redeeming rewards like free products.
Original PR description
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative…
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product. > Setup of the Loyalty Program (Discount & Loyalty): Program Type : Loyalty Card Rule : minimum 5 items => 10 Loyalty Points per $ Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points Steps to reproduce: ------------------- * Open the pos Shop * Select a customer with loyalty points * Add a Simple Pen * Click on * Reward > Free Product - Loyalty Program > Observation: Customer shouldn't 'win' points here New Total is mathematically correct but not logic Why the fix: ------------ We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points. opw-4914774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221570