Wednesday, January 7, 2026
13 changes · saas-18.4
Enhancements to existing features
This update enhances the restaurant POS system by allowing administrators to more flexibly control the redirection to floor plans when orders are removed. The change extracts this logic into a separate method, providing greater customization options and improving the overall user experience. This aligns with previous enterprise development efforts (odoo/enterprise#102992).
Original PR description
To allow overriding the condition to redirect to the floor plan when removing an order, we extract it in its own method. see odoo/enterprise#102992 Task: 5433405
This update automatically clocks employees in before they can use the Point of Sale (POS) system. Previously, users were prompted to manually clock in, which has now been automated. This streamlines the POS process and reduces potential delays for customers.
Original PR description
Instead of telling the user he must clock in before using its pos, we now do it for him. see odoo/odoo#241542 Task: 5433405
Resolved issues and error corrections
This update resolves an issue where the neutralization process unintentionally deleted records from the res.users table, causing problems during testing. The change replaces a database truncation command with a targeted deletion, ensuring only the mail partner device data is removed and preventing data loss.
Original PR description
### Step to reproduce: 1. Create db in version 17.0 and create a many2one field with ``mail.partner.device`` 2. neturalize the db. All records of res.users will be vanish due to ``TRUNCATE…
### Step to reproduce:
1. Create db in version 17.0 and create a many2one field
with ``mail.partner.device``
2. neturalize the db. All records of res.users will be vanish due to ``TRUNCATE mail_partner_device CASCADE;``
### Issue:
during neutralize if there is any custom/studio field many2one with ``mail.partner.device`` even if the mail partner device
record won't used it in particular model still it will wipe out all the records of that model on neutrilizing
which can issue during testing on neutrlized db
**To fix it :**
[here](https://github.com/odoo/odoo/pull/133560/files#diff-284b40b100919f9b1d4f7bee50740387fea5f11815210baa5f6de9cbf317ca6dR14) want to delete only partner device. So, adjusted query using ``DELETE FROM mail_partner_device`` instead of truncate.
below traceback will generate due to this during upgrade.
```
Traceback (most recent call last):
File "/home/odoo/bin/misc/update_module_list.py", line 25, in <module>
env["ir.module.module"].update_list()
File "<decorator-gen-87>", line 2, in update_list
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 71, in check_and_log
log_data = (method.__name__, self.sudo().mapped('display_name'), user.login, user.id, origin)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1188, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: res.users(1,), User: 1)
[ERROR]::Error during the upgrade:
```
opw-5443072
upg-3712726
Forward-Port-Of: odoo/odoo#242081
Forward-Port-Of: odoo/odoo#241535This update resolves an issue where closing the event registration selection in a sales order would sometimes leave the product incorrectly listed. The fix ensures that the product is properly removed from the order line when the event selection is dismissed, preventing data inconsistencies.
Original PR description
**Steps to produce:** - Install `Events and Sales` modules. - Go to `sale > sale order > Open any SO > Add product > Event registration`. - When the wizard opens, dismiss it by either clicking the X…
**Steps to produce:**
- Install `Events and Sales` modules.
- Go to `sale > sale order > Open any SO > Add product > Event registration`.
- When the wizard opens, dismiss it by either clicking the X button in the
top-right corner of the modal or by pressing the `Escape` key.
**Traceback:**
`TypeError: Cannot convert undefined or null to object.`
**Root cause:**
- In this [commit], the `{ dismiss: true }` option was added to the `dismiss` call.
- At [1], when `onClose` is triggered, we only check `!closeInfo || closeInfo.special`.
Since `{ dismiss: true }` does not satisfy either condition, the code falls into the `else` branch,
where `update` is called with an `undefined` value.
**Solution:**
- Now, we also check the condition `closeInfo.dismiss`.
- So, now that we have closed the selection of the event, our product is also removed from the SO line.
[commit]: https://github.com/odoo/odoo/commit/31c00161fd3a77c9fbd260754cb8c142fcb0d652
[1]https://github.com/odoo/odoo/blob/01a896557ec2bada04db60195926c6fa61375b10/addons/event_sale/static/src/js/sale_product_field.js#L40
**opw-5349732**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238061This update fixes a bug that prevented users from registering for event slots from pages other than the event registration page. Now, attendees can easily find and book available time slots on any page related to an event, improving the event booking experience. This change ensures consistent registration options across all event-related content.
Original PR description
* = event, event_booth, event_exhibitor, event_track, event_track_quiz The "register" button displays open slots only on the registration page of an event, and not on the other pages of this one. This PR fixes this issue by making available the open slots from the event.event model for the modal_slot_registration template as an instance of this one is always present in the context of those pages. Reproduce: Create an event with the "Multiple Slots" option checked and link it to a slot of tomorrow. The "register" button will display the slot on the registration page of the event but not on the page of the talks. Task-5083175 Forward-Port-Of: odoo/odoo#226635
This update fixes a bug that could cause push notifications to fail when users manage their notification settings. Specifically, it handles cases where the system doesn't receive prior subscription information, and addresses issues with invalid domain names used for push notifications, ensuring reliable delivery.
Original PR description
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring…
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring inside the service worker. Steps to reproduce: 1. Enable notification in Odoo. 2. Reset the permission in the Chrome interface 3. Re-enable the permission inside the discuss systray by clicking on the Odoobot message. => The pushsubscriptionchange is called without an oldSubscription [FIX] mail: ir_cron_web_push_notification are now more robust With a user having 5 registered devices for push notifications if a browser registers with an endpoint that has a wrong domain such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX the cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. [FIX] mail: push_to_end_point method to support .invalid TLD if a browser registers with an endpoint that has a TLD `.invalid` such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX The TLD `.invalid`[1] is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. So we need to unregister a device with an endpoint with a `.invalid` TLD. [1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242013 Forward-Port-Of: odoo/odoo#240502
This update significantly speeds up product searches used in EDI processing, particularly for large invoice volumes. By restructuring the database query, the system now efficiently utilizes indexes, dramatically reducing search times. This improvement is crucial for handling high-volume EDI transactions like PEPPOL, ensuring faster invoice processing.
Original PR description
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents…
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow. This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one. This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line. Benchmarks: Importing a peppol document of 173 invoice lines. | Num products | Num invoice lines | Before | After | | ------------ | ----------------- | -------- | ------- | | 864873 | 173 | 868.18 s | 19.43 s | | 397005 | 173 | 468.91 s | 20.68 s | | 8064 | 173 | 125.08 s | 20.1 s | | 564 | 173 | 119.9 s | 20.21 s | opw-5245007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240753 Forward-Port-Of: odoo/odoo#238853
This update ensures that the Odoo Enterprise system accurately calculates and applies Belgian withholding taxes for payroll up to the year 2026. The change corrects a discrepancy in tax rules, ensuring compliance with the latest regulations and accurate financial reporting. This fix impacts the l10n_be_hr_payroll module.
Original PR description
TaskID: 5403525 Forward-Port-Of: odoo/enterprise#103271 Forward-Port-Of: odoo/enterprise#103215
This update resolves an issue preventing customers in French territories like La Réunion from using Stripe Connect. The change adjusts how Odoo maps company countries to Stripe, aligning with Stripe's policies for supported regions. This ensures seamless payment processing for all users, regardless of their location.
Original PR description
## Versions 17.0+ ## Issue Customers located in French territories (e.g. La Réunion) can't use Stripe Connect. ## Steps to reproduce *Ensure Stripe payment provider is installed* - From the Settings'…
## Versions 17.0+ ## Issue Customers located in French territories (e.g. La Réunion) can't use Stripe Connect. ## Steps to reproduce *Ensure Stripe payment provider is installed* - From the Settings' app, access your company's data: - Change your company's country for "Réunion". - Go to Payment Providers and open Stripe: - Try to enable Stripe via Stripe Connect; - A message tells you your country is not supported by Stripe. ## Cause Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries). This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow. opw-5421185 Forward-Port-Of: odoo/odoo#242123 Forward-Port-Of: odoo/odoo#241269
This update fixes an issue where Odoo wasn't consistently showing the correct working schedule when employees had overlapping contract periods. Previously, it only displayed the latest schedule, regardless of the contract. Now, the system accurately reflects each employee's working schedule for each contract period, ensuring accurate attendance tracking.
Original PR description
Description of the issue/feature this PR addresses: Based on this feedback : https://www.odoo.com/odoo/project.task/5436300 . When I got two versions with different working schedules, normally, in…
Description of the issue/feature this PR addresses: Based on this feedback : https://www.odoo.com/odoo/project.task/5436300 . When I got two versions with different working schedules, normally, in Attendance, the gant view should show the unavaibilities by putting in gray days you're not working. . As the feedback shows, if you have two differents working schedules on two differents versions and two differents occupations period (contract dates), it's working fine. If, the two versions have the same occupation period (contract date), it's only considering the latest working schedule. . If both versions are under the same contract, then it only shows the working schedule on the latest version. This is not what we expect Instead, it should show the correct working schedule for each period Current behavior before PR: Desired behavior after PR is merged: . Modify _get_calendar_periods() method to return the correct working schedule for each period task-5473047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where product documents weren't being added to PDF quotes after they were confirmed. Previously, confirmed quotes didn't include selected documents. Now, a new setting allows users to ensure all desired documents are always included in the PDF quote, improving the accuracy of sales materials.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Add product documents, headers or footers to a quotation; 2. confirm quotation; 3. print quotation. Issue ----- Extra documents aren't added to the PDF, even though they show up as selected in the quotation builder. Cause ----- As of commit b02f53d, any quotation documents linked to a sales order are simply ignored for confirmed orders. Solution -------- Add a `sale.always_include_selected_documents` config parameter, allowing users to keep including the selected documents on confirmed orders. opw-5242743 Forward-Port-Of: odoo/odoo#235778
This update ensures that variant names are correctly displayed on POS orders when a product is included in a combo. Previously, the system didn't show variant information for combo products with instantly generated variants. This fix corrects a technical issue related to how the POS system retrieves product details, improving the user experience and accuracy of order information.
Original PR description
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create…
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create a combo choice and add one of his variants * Create a combo product and add the combo * Open an store that sells this combo * Select the combo and choose the product with variant and confirm the selection Issue : On the left size in the order the variant name will not appear. ### Observation: When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33 ------------ When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered. The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products. opw-5037355 Forward-Port-Of: odoo/odoo#239314 Forward-Port-Of: odoo/odoo#227176
This update fixes a previous issue where payments made on the website weren't properly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines for existing orders. Additionally, fully paid orders without invoices won't appear in the POS to prevent duplicate payments.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Community PR-[#232841](https://github.com/odoo/odoo/pull/232841) Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081 Forward-Port-Of: odoo/enterprise#103350 Forward-Port-Of: odoo/enterprise#98029