Odoo Changelog — 2026-01-07

Wednesday, January 7, 2026

15 changes · saas-18.3

Improvements(1)

Enhancements to existing features

[IMP] hw_drivers: normalise logs around actions

Coresaas-18.3hw_driversMEDIUM

This update enhances the longpolling controller by adding detailed logging and performance monitoring. These changes improve system stability and allow our team to quickly identify and address any performance issues related to this critical component. This proactive approach ensures a smoother user experience and more reliable service.

Original PR description

This PR adds logging and performance check for the longpolling controller

Related PR for >= saas-18.3: https://github.com/odoo/odoo/pull/241467

Forward-Port-Of: odoo/odoo#241469

#performance#logging#stability

Bug Fixes(14)

Resolved issues and error corrections

[FIX] sign: make search in sign templates work again

PR #102749

Enterprisesaas-18.3signMEDIUM

A bug preventing users from searching within sign templates has been fixed. The issue stemmed from a technical setting that was blocking input into the PDF search box. This update ensures users can now effectively search for content within sign templates, improving workflow efficiency.

Original PR description

Currently when the user is viewing sign templates, they are unable to search within a PDF.

**Steps to replicate:**
* Install `sign` with demo data
* Sign > Templates > Open a template
* Try searching using the magnifying glass button

**Observed Behavior:**
* User is unable to type anything in the PDF search box.

**Root cause:**
* This error happens because `preventDefault()` is called during a `keydown` event. At [1], calling `event.preventDefault()` stops the key’s normal behavior, so the typed character is not added to the input field.

**Solution:**
* Remove the `preventDefault` call which allows the search to work again.

[1]:
https://github.com/odoo/enterprise/blob/3df585779e6ede664279331c4531043688dadf17/sign/static/src/backend_components/editable_pdf_iframe_mixin.js#L623

opw-5366074

#sign templates#search#PDF

[FIX] mail: Fix truncate all related table data

PR #242194

Coresaas-18.3mailMEDIUM

This update resolves an issue where database neutralization unintentionally wiped out user records due to a broad database truncation. The fix now only deletes the 'mail.partner.device' records, preventing data loss during testing and upgrades. This ensures a more stable and predictable database environment.

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#241535

#database#neutralize#data loss

[FIX] event{,_booth}_sale: prevent traceback when close the select event option

PR #242298

Coresaas-18.3event_salesaleMEDIUM

This update resolves an issue where closing the event registration modal in a sales order would sometimes leave the event product incorrectly attached. The fix ensures that the product is properly removed from the order line when the event selection is dismissed, preventing data inconsistencies. This improves order accuracy and user experience.

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 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#238061

#sales#events#order management

[FIX] mail: avoid error on service worker push subscription change

PR #242374

Coresaas-18.3mailMEDIUM

This update fixes a bug that occurred when push notifications were re-enabled, preventing errors in the service worker. It also enhances the system's ability to handle invalid push notification endpoints, specifically those using the `.invalid` top-level domain, ensuring notifications continue to function correctly.

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 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

#push notifications#reliability#mobile

[PERF] account_edi_format: Speedup product search

PR #241206

Coresaas-18.3accountMEDIUM

This update significantly speeds up product searches used in EDI processing, particularly for large invoice imports like those from PEPPOL. By restructuring the database query, the system now utilizes indexes more effectively, dramatically reducing processing times from over 8 minutes to just a few seconds.

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 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

#edi#performance#product search

[FIX] pos_sale: Manage products paid on ecommerce in the POS

PR #242250

Coresaas-18.3pos_saleMEDIUM

This update fixes a previous issue where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made on ecommerce, creating a down payment line for existing orders. Additionally, fully paid orders that aren't yet invoiced will no longer appear in the POS, preventing 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
Original Task-5138081

Backport-[#230809](https://github.com/odoo/odoo/pull/230809)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#233851
Forward-Port-Of: odoo/odoo#232841

#ecommerce#payments#pos#sales

[FIX] pos_sale: Manage products paid on ecommerce in the POS

PR #103350

Enterprisesaas-18.3pos_saleMEDIUM

This update fixes a problem where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for previously paid amounts, creating down payment lines for ecommerce orders. Additionally, fully paid orders that aren't yet invoiced will no longer appear in the POS, preventing 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#98498
Forward-Port-Of: odoo/enterprise#98029

#ecommerce#payments#pos

[FIX] html_editor: prevent traceback on failed metadata fetch

PR #242369

Coresaas-18.3html_editorMEDIUM

This update resolves an issue where the HTML editor would crash if a URL couldn't be fetched (like due to website restrictions). The change ensures that errors during metadata retrieval are handled gracefully, preventing the editor from freezing and improving the user experience. This improves stability and reliability of the editor.

Original PR description

Problem:
When a fetch request fails (for example due to CORS restrictions), a traceback occurs in the editor.

Solution:
Backport 971d88121968c85a86c805458d5d9dbbb305995c and ensure the error handling check is applied for both internal and external metadata fetching.

Steps to reproduce:
- Create a tracked link.
- Copy the tracked link.
- Create a link in the editor and use the copied URL.
- Apply.
- Traceback occurs.

task-5394908

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#240712

#html_editor#stability#user experience

[FIX] hr_holidays_contract: Recompute duration after changing contracts

PR #242372

Coresaas-18.3hr_holidays_contractMEDIUM

This update fixes an issue where time-off durations weren't accurately calculated after changing an employee's contract. The fix ensures that the employee's working schedule is fully updated before calculating leave durations, preventing incorrect totals. This improves the reliability of time-off tracking for employees.

Original PR description

### Steps to reproduce: - define a time-off type in hours - create working schedules : standard 40h (fixed hours) standard 20h (fixed hours) Flexible 40h (flex hours) Flexible 20h (flex hours) -…

### Steps to reproduce:
	- define a time-off type in hours
	- create working schedules :
		standard 40h (fixed hours)
		standard 20h (fixed hours)
		Flexible 40h (flex hours)
		Flexible 20h (flex hours)
	- create 2 employees: employee 1 with fixed hours ; employee 2 with flexible hours
	- create contract 1 Fix 100% (start in 01/01/2025 - standard 40h) and set it to running
	- create contract 2 Flex 100% (start in 01/01/2025 - Flexible 40h) and set it to running
	- register a 1st week t-o for each employee (ex: 08/03/2025-08/09/2025) ==> 40h and validate
	- register a 2nd week t-o for each employee (09/07/2025-09/13/2025) ==> 40h and validate
	- expire current contract (100%) for each employee and launch a new contract (50%) : 
		- Standard 20h (Fixed hours) for employee 1 ; 
		- Flexible 20h (flex hours) for employee 2 (start on 08/24/2025)
			==> set them to running

### Cause:
While we are recomputing the duration of the overlapping leaves
the resource_calendar for the employee is not yet changed so when
getting the work_intervals we are calculating it using the old hours_per_day.

Also since we are still writing to the contract and it is not yet
in running state so we won't be able to use _get_calendars_validity_within_period


### Fix:
We add the number of days and duration display to the compute queue
so it will be recomputed after we already change the employee's resource_calendar

opw-5010995

Forward-Port-Of: odoo/odoo#227298

#hr#time-off#contracts

[FIX] account: prevent error when opening the tax return

PR #239814

Coresaas-18.3accountMEDIUM

This update fixes an error that occurred when users set a negative value for the fiscal year end day in the Tax Returns view. The fix prevents invalid data from being saved, ensuring the Tax Returns functionality operates correctly. This resolves a potential disruption to financial reporting.

Original PR description

Currently, an error occurs when user tries to open the Tax Return view.

**Steps to Reproduce:**
- Install the `Accounting` module.
- Go to `Tax Returns` and set the `Fiscal Year End Day to negative value`, then click `Apply`.

**Error:**
`ValueError: day is out of range for month.`

**Cause:**

- The field is related to the `company's fiscalyear_last_day` [1].
- When the user enters a `negative value`, that invalid value is written directly to the `company's fiscal year last day`[2] .
- When the user opens the `Tax Returns`, it going to compute the `fiscal year dates` [4]. Since the day value is negative, it raises error [5] because the day is out of range for the month.

**Fix:**
- This commit ensures that a validation error is raised when a user enters zero or negative fiscal year date.
- In 18.3, setting the value to 0 falls back to the previously defined company value [2].
- In 19.0, however, the value 0 is incorrectly saved on the company [3], causing an error.
- This fix restores the correct behavior and resolves the issue in 19.0 as well.

[1]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L17-L18

[2]: https://github.com/odoo/odoo/blob/45ca03fcb77febf4f373fe35f0242720e88cb85b/addons/account/wizard/setup_wizards.py#L49

[3]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L54-L56

[4]: https://github.com/odoo/enterprise/blob/99642bdf62f8b1c653dfefdbdcd0e9258cc9e307/account_accountant/models/res_company.py#L174-L175

[5]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/odoo/tools/date_utils.py#L242

sentry-7102968735

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#accounting#tax#fiscal year

[FIX] pos_hr : An TB occurs at opening and closing without any details

PR #234692

Coresaas-18.3point_of_salepos_loyaltyMEDIUM

A technical error occurred when switching between POS configurations with and without employee login. This fix ensures the system correctly updates its data storage (IndexedDB) to account for the 'Log in with employees' option, preventing errors during opening and closing processes. This improves the stability and reliability of the POS functionality.

Original PR description

Before this fix, a traceback occurred on the frontend when switching from a POS configuration without the “Log in with employees” option enabled to one that had it enabled.

Steps to reproduce :
1. Open a PoS without "Log In With Employees" option activated
2. Close Register and go to the backend
3. Enable the "Log in with employees option" for this PoS and set some users
4. Re-open the PoS with a user and close it
5. A TB occured

This traceback occurred because the IndexedDB did not include the "hr.employee" module required by the "Log in with employees" option.

The fix was to upgrade the IndexedDB if a module is missing.

task: 5223393

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#POS#employee login#stability

[FIX] sale_pdf_quote_builder: allow extra documents on confirmed orders

PR #242412

Coresaas-18.3sale_pdf_quote_builderMEDIUM

This update fixes an issue where product documents, headers, or footers weren't being added to PDF quotes after they were confirmed. A new configuration setting allows users to ensure these documents are always included in the final PDF, regardless of whether the order is confirmed. This improves the accuracy and completeness of sales quotes.

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

#sales#quotes#pdf#documents

[FIX] web_editor: remove inline code when last character is deleted

PR #240798

Coresaas-18.3web_editorhtml_editorMEDIUM

This update fixes a persistent issue where inline code blocks were difficult to remove, particularly at the end of lists. The changes ensure code styles disappear cleanly when the last character is deleted, enhancing the editor's usability. It also addresses related problems with cursor placement and empty code block removal.

Original PR description

Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry.

This commit solves this by removing the code style when its last character is removed.

Steps to reproduce:
- Create a list
- Type some inline code
- Put the cursor in the middle
- Press Enter
- Type some text after the inline code on the second line
- Try to remove the inline code from the second line using backspace

=> The line is removed before the code style disappears

task-5375140

Forward-Port-Of: odoo/odoo#238552

#editor#code#editing#user experience

[FIX] stock_barcode: prevent validate multiple times

PR #102465

Enterprisesaas-18.3stockMEDIUM

This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix ensures that the validation process is only executed once, preventing data inconsistencies and saving time for users. This improves the reliability of transfer processing.

Original PR description

**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…

**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).

**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line

**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').

opw-4948696

Forward-Port-Of: odoo/enterprise#101868
Forward-Port-Of: odoo/enterprise#95329

#stock#barcode#transfer#validation

Currently when the user is viewing sign templates, they are unable to search within a PDF. **Steps to replicate:** * Install `sign` with demo data * Sign > Templates > Open a template * Try searching using the magnifying glass button **Observed Behavior:** * User is unable to type anything in the PDF search box. **Root cause:** * This error happens because `preventDefault()` is called during a `keydown` event. At [1], calling `event.preventDefault()` stops the key’s normal behavior, so the typed character is not added to the input field. **Solution:** * Remove the `preventDefault` call which allows the search to work again. [1]: https://github.com/odoo/enterprise/blob/3df585779e6ede664279331c4531043688dadf17/sign/static/src/backend_components/editable_pdf_iframe_mixin.js#L623 opw-5366074

### 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#241535

**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#238061

[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

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

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 Original Task-5138081 Backport-[#230809](https://github.com/odoo/odoo/pull/230809) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233851 Forward-Port-Of: odoo/odoo#232841

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#98498 Forward-Port-Of: odoo/enterprise#98029

Problem: When a fetch request fails (for example due to CORS restrictions), a traceback occurs in the editor. Solution: Backport 971d88121968c85a86c805458d5d9dbbb305995c and ensure the error handling check is applied for both internal and external metadata fetching. Steps to reproduce: - Create a tracked link. - Copy the tracked link. - Create a link in the editor and use the copied URL. - Apply. - Traceback occurs. task-5394908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240712

### Steps to reproduce: - define a time-off type in hours - create working schedules : standard 40h (fixed hours) standard 20h (fixed hours) Flexible 40h (flex hours) Flexible 20h (flex hours) - create 2 employees: employee 1 with fixed hours ; employee 2 with flexible hours - create contract 1 Fix 100% (start in 01/01/2025 - standard 40h) and set it to running - create contract 2 Flex 100% (start in 01/01/2025 - Flexible 40h) and set it to running - register a 1st week t-o for each employee (ex: 08/03/2025-08/09/2025) ==> 40h and validate - register a 2nd week t-o for each employee (09/07/2025-09/13/2025) ==> 40h and validate - expire current contract (100%) for each employee and launch a new contract (50%) : - Standard 20h (Fixed hours) for employee 1 ; - Flexible 20h (flex hours) for employee 2 (start on 08/24/2025) ==> set them to running ### Cause: While we are recomputing the duration of the overlapping leaves the resource_calendar for the employee is not yet changed so when getting the work_intervals we are calculating it using the old hours_per_day. Also since we are still writing to the contract and it is not yet in running state so we won't be able to use _get_calendars_validity_within_period ### Fix: We add the number of days and duration display to the compute queue so it will be recomputed after we already change the employee's resource_calendar opw-5010995 Forward-Port-Of: odoo/odoo#227298

Currently, an error occurs when user tries to open the Tax Return view. **Steps to Reproduce:** - Install the `Accounting` module. - Go to `Tax Returns` and set the `Fiscal Year End Day to negative value`, then click `Apply`. **Error:** `ValueError: day is out of range for month.` **Cause:** - The field is related to the `company's fiscalyear_last_day` [1]. - When the user enters a `negative value`, that invalid value is written directly to the `company's fiscal year last day`[2] . - When the user opens the `Tax Returns`, it going to compute the `fiscal year dates` [4]. Since the day value is negative, it raises error [5] because the day is out of range for the month. **Fix:** - This commit ensures that a validation error is raised when a user enters zero or negative fiscal year date. - In 18.3, setting the value to 0 falls back to the previously defined company value [2]. - In 19.0, however, the value 0 is incorrectly saved on the company [3], causing an error. - This fix restores the correct behavior and resolves the issue in 19.0 as well. [1]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L17-L18 [2]: https://github.com/odoo/odoo/blob/45ca03fcb77febf4f373fe35f0242720e88cb85b/addons/account/wizard/setup_wizards.py#L49 [3]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L54-L56 [4]: https://github.com/odoo/enterprise/blob/99642bdf62f8b1c653dfefdbdcd0e9258cc9e307/account_accountant/models/res_company.py#L174-L175 [5]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/odoo/tools/date_utils.py#L242 sentry-7102968735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this fix, a traceback occurred on the frontend when switching from a POS configuration without the “Log in with employees” option enabled to one that had it enabled. Steps to reproduce : 1. Open a PoS without "Log In With Employees" option activated 2. Close Register and go to the backend 3. Enable the "Log in with employees option" for this PoS and set some users 4. Re-open the PoS with a user and close it 5. A TB occured This traceback occurred because the IndexedDB did not include the "hr.employee" module required by the "Log in with employees" option. The fix was to upgrade the IndexedDB if a module is missing. task: 5223393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

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

Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140 Forward-Port-Of: odoo/odoo#238552

**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs). **Steps to Reproduce:** - In the Barcode app, create a new internal transfer - Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode) - Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible - See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line **Fix:** Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate'). opw-4948696 Forward-Port-Of: odoo/enterprise#101868 Forward-Port-Of: odoo/enterprise#95329