Wednesday, May 20, 2026
6 changes · saas-18.4
Resolved issues and error corrections
Customers who choose in-store pickup during guest checkout are now correctly kept as followers on the related delivery order. This ensures they receive the expected email confirmation when their pickup delivery is validated.
Original PR description
Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed 1. Install eCommerce and Sales 2. Go to Settings >…
Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed 1. Install eCommerce and Sales 2. Go to Settings > Website > Delivery and enable "Click & Collect" 3. Go to Settings > Inventory > Shipping and enable "Email Confirmation" 4. Go to Website > Configuration > Payment Providers and Install Demo 5. Go to Website > Configuration > Delivery Methods and open "Pick up in store", set YourCompany as warehouse and publish it 6. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units 7. Log out 8. Go to the shop, add product "Office Lamp" to the cart and checkout 9. Fill in the address form and continue checkout 10. Select "Pick up in store" as delivery method and select a location 11. Confirm the order and pay with Demo 12. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order 13. Open the related delivery with the smart button and validate it 14. No delivery order confirmation was sent to the customer (check emails) Issue: Confirming an order with a "Pick up in store" delivery method replaces the `partner_shipping_id` of the sale order with an archived partner https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/delivery/models/sale_order.py#L178-L192 which updates the `partner_id` of the related `stock.picking` with the archived partner https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/sale_stock/models/sale_order.py#L130-L132 This will unsubscribe the old `partner_id` on the `stock.picking` and try to subscribe the archived partner https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/stock/models/stock_picking.py#L1120-L1125 Because the partner we want to subscribe is archived, he will be filtered out and the subscribe action will have no effect, preventing him from receiving the delivery confirmation https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/mail/models/mail_thread.py#L4367-L4369 Solution: Subscribe the parent of the archived partner when we write a `partner_id` on pickings with "in_store" `delivery_type`. This ensures the unarchived partner is subscribed to the picking allowing him to receive the mail confirmation. opw-6095396 Forward-Port-Of: odoo/odoo#265066 Forward-Port-Of: odoo/odoo#263005
When website orders with custom product text are settled in Point of Sale, the customer's entered text now carries over correctly instead of showing a generic placeholder. This helps staff see the exact customization requested and reduces order handling mistakes.
Original PR description
When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text…
When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer. Steps to reproduce: ------------------- * Create a product with a free text attribute (create_variant='no_variant', is_custom=True) * Go to the website's shop (works best in a new private tab) * Fill the free text attribute and add the product to the cart * Click on checkout * In POS, open Quotation/Order and settle the order > Observation: the order line shows "Custom" instead of the text Why the fix: ------------ `SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text. The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime. opw-5958678 Forward-Port-Of: odoo/odoo#264370 Forward-Port-Of: odoo/odoo#251993
Fixes an issue where archived sales teams, users, tags, and stages could appear when creating an opportunity from a contact. Users still see archived opportunities where expected, but selection lists now stay focused on active records to avoid choosing outdated options.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801
Forward-Port-Of: odoo/odoo#263283
Forward-Port-Of: odoo/odoo#261300Invoices using early payment discounts with 0% tax now generate compliant electronic invoice tax breakdowns. This prevents Peppol validation failures and helps ensure affected invoices can be exchanged successfully.
Original PR description
Before this commit, creating an invoice with an Early Payment Discount (EPD) as a payment term could cause the schematron validation of the generated invoice to fail when an invoice line had a 0% tax. The issue was caused by generating two TaxSubtotal nodes for the same TaxCategory (0%, exemption code 'E'): - one for the 0% VAT - one for the EPD discount applied to the total amount However, Peppol requires a single VAT breakdown (TaxSubtotal) per VAT category (in this case: E) Additionally, when VAT was set to 0%, the allowance charge TaxSubtotal incorrectly used 'S' as a hardcoded tax category code. This commit fixes both issues. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263501 Forward-Port-Of: odoo/odoo#254199
This update fixes an error in the Luxembourg Annual VAT Declaration report that resulted in inaccurate calculations for Appendix E 1a. The fix ensures that key financial data is correctly included in the formula, guaranteeing accurate reporting for Luxembourg businesses. This improves the reliability of the VAT declaration process.
Original PR description
### Issue: The formula `L10N_LU_TAX_163` in the Luxembourg Annual VAT Declaration was incorrect: - `L10N_LU_TAX_791.year_start` was added twice - `L10N_LU_TAX_993.year_start` was missing As a result, the computed total in Appendix E 1a was incorrect ### Steps to reproduce: - Install `l10n_lu_reports` - Open the `Report: Annual VAT Declaration (LU)` - Go to `Appendix E` - Use the `Start of Financial year` pencil icons to manually set values for fields `791` and `993` - Check the computed value of field `163` After the fix, both values are included exactly once in the formula opw-6158950 Forward-Port-Of: odoo/enterprise#117214
This update fixes an error that occurred when selecting shift templates on planning slots, specifically when dealing with long periods of leave. The change ensures the system gracefully falls back to a previously calculated end date if the template duration cannot be accurately determined, preventing the application from crashing. This improves the reliability of shift planning.
Original PR description
Currently, an error occurs when a user selects a shift template on a planning slot. **Steps to Reproduce:** - Install the `Planning` module with demo data. - Create a `Resource Time Off` record with…
Currently, an error occurs when a user selects a shift template on a planning slot. **Steps to Reproduce:** - Install the `Planning` module with demo data. - Create a `Resource Time Off` record with `start` and `end date` separated by more than `1400 days (around 3.9 years)`, and Set the Working Hours field to Standard 40 hours/week. - Go to `Planning` > `Configuration` > `Shift Templates`, open an `existing record` or create a `new one`, and set the `Working Days` to more than 1 day. - Create a new `planning slot`, Assign the resource `Abigail Peterson`, and select the above `shift template`. `AttributeError: 'bool' object has no attribute 'replace'` This error occurs because when the user sets the shift template, the compute method runs to calculate the start and end datetimes [1]. It computes the end datetime by adding the template duration in working days from the given start datetime using the resource working calendar within a searchable range of around 1400 days [2]. During this computation, leaves and non-working days are skipped [3]. If no valid working interval is found within the searchable range, then it returns False [4], which raises the error [5]. This commit ensures that if plan_days returns False, the computation falls back to the previously calculated end date. [1]: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L662-L671 [2]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L826-L835 [3]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L533-L537 [4]: https://github.com/odoo/odoo/blob/a439bd305112f6efc752ce900f7782e7faaf7312/addons/resource/models/resource_calendar.py#L835 [5]- https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/planning/models/planning.py#L653-L654 sentry-7472958590 Forward-Port-Of: odoo/enterprise#117073