Monday, March 23, 2026
10 changes · saas-18.2
Resolved issues and error corrections
Products tagged as excluded from Pick Up in Store will no longer show that delivery option on their website product page. This prevents customers from seeing an option they cannot actually use at checkout and keeps the shopping experience consistent.
Original PR description
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page. Steps to produce: --- - Install…
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.
Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
- In the `Stores` tab, set your company warehouse.
- In the `Availability` tab, add the created tag to Excluded Tags.
- Publish the delivery method.
- Open the tagged product on the website.
Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.
Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.
Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
for that delivery method. This keeps the behavior consistent across
the website, avoids showing unavailable delivery options, does not
impact other flows and aligns with the existing behavior during
checkout.
[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194
opw-5921268
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250837Point of Sale screens now prevent users from confirming text prompts when the field is blank or contains only spaces. This avoids empty floor, table, gift card, or discount code entries and reduces correction work for store staff.
Original PR description
*= point_of_sale, pos_loyalty, pos_restaurant Before this commit: =================== - User was able to confirm `TextInputPopup` with an empty input value. Affected functionalities: - Add New Floor - Rename Floor / Table - Enter Code (Gift card or Discount code) - Generate a Gift Card After this commit: ================== - The confirm button will be disabled if the input value is empty or has only spaces so that an empty string will not be accepted. Task-6019160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254632 Forward-Port-Of: odoo/odoo#253307
This fix prevents users from seeing and using the add reaction button on messages that do not support reactions, such as mail group history messages. It avoids an error in Discuss and related messaging areas, improving reliability without changing supported reaction behavior.
Original PR description
*= im_livechat, portal, test_discuss_full **Steps to reproduce:** • Install the mail_group module • Open Discuss • Go to the History tab • Add a reaction on a message that has model `mail.group` •…
*= im_livechat, portal, test_discuss_full **Steps to reproduce:** • Install the mail_group module • Open Discuss • Go to the History tab • Add a reaction on a message that has model `mail.group` • Throws an error The error occurs because the `mail.group` model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579 Desired behavior after PR is merged: This PR fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as mail.group. enterprise: https://github.com/odoo/enterprise/pull/111271 Task-5098050 [Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Danish Nemhandel OIOUBL invoices now include the required DK prefix on CVR party identifiers. This helps ensure generated e-invoices follow the expected Danish identifier format and are accepted by trading partners.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
Cross-origin requests can now include a range request without being blocked during browser preflight checks. This helps external clients or embedded experiences load partial content, such as media or large files, more reliably when the route already allows cross-origin access.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This fixes an issue where users might not see the intended error message when PDF merging fails, such as with a malformed PDF. The change helps ensure reporting errors are handled cleanly and users receive clearer feedback instead of a technical crash.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#211611This update fixes a bug that prevented users from adding reactions to messages within the 'mail_group' module in Discuss. The fix ensures the 'add reaction' button isn't displayed for message types that don't inherit from the standard message structure, improving stability and usability.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050
This update resolves an issue where the CFDI payment method '99' was incorrectly displayed as 'False' in reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This ensures correct reporting for invoices generated with the mx company.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates, streamlining the portal experience.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#108339
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payslip data, which was resolved by recalculating the necessary information. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860