Thursday, October 30, 2025
11 changes · saas-18.3
Enhancements to existing features
VoIP browser tabs now try to unregister when closed, and idle registrations expire sooner if that cleanup does not succeed. This helps avoid provider registration limits being reached when users have multiple or recently closed Odoo tabs.
Original PR description
Some providers like OnSIP allow for a limited number of registrations per user. This is a problem in Odoo because each tab opened creates a new registration for one hour. This commit mitigates the problems in two ways: - Sends an "unregister" request onbeforeunload to try to invalidate the registration upon closing the tab. - Reduces the TTL of registrations so that they get invalidated quicker in case the unregistration failed. Forward-Port-Of: odoo/enterprise#98305 Forward-Port-Of: odoo/enterprise#97963
Journal item searches in Accounting now find matching accounts and partners more efficiently, avoiding slow database scans on large datasets. This can significantly reduce wait times for users working with high volumes of accounting entries, with benchmarks showing multi-second searches becoming much faster.
Original PR description
Description ----- Currently, the default journal items view searches ilike over `account_id` and `partner_id`. This generates subqueries and causes Postgres to use a sequential scan instead of hitting the trigram indexes when OR'd. Instead we can leverage the fact that the number of accounts and partners are usually low compared to the number of aml's, by resolving the many2one domain first and injecting the matched ids into the final domain. We make use of the existing `search_account_id` field and apply a similar logic for a new `search_partner_id` field. Since the number of partners can be much larger than the number of accounts, we fall back to the original domain if too many ids are returned. Benchmarks ----- |Counts |Before|After| |------------------------------------|------|-----| |700k amls, 80k partners, 5k accounts|2.87s |0.45s| |7M amls, 800k partners, 50k accounts|29s |4s | opw-5047423
Resolved issues and error corrections
This fixes a database restore error that could happen if the default Odoo OAuth provider had been deleted. Restores can now complete normally in that case, reducing avoidable downtime and support intervention.
Original PR description
**Description of the issue/feature this PR addresses:** When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database. **Current behavior before PR:** You'll get this…
**Description of the issue/feature this PR addresses:**
When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database.
**Current behavior before PR:**
You'll get this error:
```
odoo.service.db.restore_db(dbname, backup, copy, **extra_kwargs)
File "<decorator-gen-27>", line 2, in restore_db
File "/opt/ou/odoo/odoo/service/db.py", line 44, in if_db_mgt_enabled
return method(self, *args, **kwargs)
File "/opt/ou/odoo/odoo/service/db.py", line 360, in restore_db
env['ir.config_parameter'].init(force=True)
File "/opt/ou/odoo/addons/auth_oauth/models/ir_config_parameter.py", line 13, in init
oauth_oe = self.env.ref('auth_oauth.provider_openerp')
File "/opt/ou/odoo/odoo/api.py", line 611, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2059, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/opt/ou/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2052, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: auth_oauth.provider_openerp
Error: External ID not found in the system: auth_oauth.provider_openerp
```
**Desired behavior after PR is merged:**
No error will occur
The afflicted versions are AFAIK, **16.0**, **17.0**, **18.0**, and **19.0**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233633Fixed an issue in Manufacturing where overlapping work order time entries could be removed or adjusted after saving. This keeps tracked production time accurate and prevents loss of work order history.
Original PR description
Issue: In this bug, workorder duration inverse is causing some time_ids to be deleted. To reproduce: 1- Create a db with mrp installed, and enable work orders in Setting 2- Create a MO, and confirm…
Issue:
In this bug, workorder duration inverse is causing some time_ids to be deleted.
To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
- First one 10:00 -> 12:00
- Second one 10:00 -> 11:00
5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked
Cause:
The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.
To be specific this is the compute function override:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766
In which duration is calculated using get_duration:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837
Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.
However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400
As a result, if time_ids overlap:
new_order_duration < old_order_duration
As a result some time_ids will be unlinked and some will have duration changed.
Fix:
Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```
As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899
The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.
In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.
opw-5082477This fixes an issue where overlapping time tracking entries on manufacturing work orders could be wrongly removed after saving. Work order duration calculations now stay consistent, helping manufacturers keep accurate production time records.
Original PR description
#### Issue: In this bug, workorder duration inverse is causing some time_ids to be deleted. To reproduce: 1- Create a db with mrp installed, and enable work orders in Setting 2- Create a MO, and…
#### Issue:
In this bug, workorder duration inverse is causing some time_ids to be deleted.
To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
- First one 10:00 -> 12:00
- Second one 10:00 -> 11:00
5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked
#### Cause:
The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.
To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766
In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837
Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.
However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals: https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400
As a result, if time_ids overlap:
new_order_duration < old_order_duration
As a result some time_ids will be unlinked and some will have duration changed.
#### Fix:
Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```
As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899
The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.
In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.
However, this might cause another issue:
If `order.duration` is not computed yet, and inverse method `_set_duration` is called, then `get_duration` inside `_set_duration` will be called before the `get_duration` in compute method. As a result there might be a small unexpected time difference between `old_order_duration` and `new_order_diuration`. To avoid that inside `get_working_duration` we can use cursor now instead:
```diff
+ now = self.env.cr.now()
- now = datetime.now()
```
opw-5082477This fix lets point of sale users search for products whose variants are created dynamically from template attributes. It prevents products from being missed at checkout just because their specific variant has not been generated yet.
Original PR description
Before this commit, it was not possible to search a product that had a dynamic attribute configured on its template, since no product variant was created yet. opw-5188725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes incorrect leave duration calculations for Indian HR holidays when sandwich leave rules include weekends or public holidays. Employees and HR teams now see accurate leave balances, avoiding negative or inflated durations when leave spans non-working days or linked leave requests change.
Original PR description
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases…
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases (where Saturday and Sunday are considered non-working days): - Friday - Monday across weekend - counted (4 days). - Hour-based leave types: weekend bridging increases hours accordingly - Public holiday in the middle (Tue-Thu with Wed PH) - counted (3 days). - Stop/Start exactly on a public holiday(Tue-Wed(Public holiday), or Wed(Public holiday)-Thu) - trimmed to 1 day. - Public holiday only - 0 days. - Two single-day leaves around a Public holiday - When the second leave is created, it bridges via a public holiday (2 days), - The first one remains 1 day if it stands alone - Mixed leave types: - If the linked leave type doesn’t have sandwich enabled, no sandwich rules. - If both leave enable sandwich (with different types) - sandwich rule applies - Refusing/canceling a linked leave must immediately adjust the other side’s duration (e.g., Monday refused - Friday drops from 3 - 1 day) Task-4430044 Co-authored-by: @mepe-odoo Forward-Port-Of: odoo/odoo#233613 Forward-Port-Of: odoo/odoo#193186
This fixes electronic invoice generation so tax-included product prices are reported with enough precision to pass Peppol validation. Businesses using UBL/BIS3 invoicing should see fewer rejected invoices caused by small rounding differences.
Original PR description
At the moment, the UBL's Price/PriceAmount node is rounded to the same number of decimals as the database's product price precision. This causes a Peppol schematron validation error due to rule PEPPOL-EN16931-R120 in the case where the user uses tax-included prices. For example, if you have a tax-included unit price of 12.95, a quantity of 8 and a 21% tax, then the tax-excluded subtotal is 85.62. Divide 85.62 by 8 and you get a raw unit price of 10.7025. But if we round to 2 decimal places, we get 10.7 but `10.7 * 8 = 85.6 != 85.62`. Solution: We need to round the unit price to enough decimal places to ensure that unit price * quantity ~= line subtotal (with a tolerance of less than 0.02) opw-5072134 Forward-Port-Of: odoo/odoo#226869
Italian electronic invoices that combine ENASARCO with a regular withholding tax no longer fail validation incorrectly. This prevents valid invoices from being blocked during sending while keeping checks that avoid invalid tax combinations.
Original PR description
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the…
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the FatturaPA XML structure only allows global declarations for withholding and pension fund taxes — on the line level, it can only specify if those taxes apply, not which ones. To reflect this, we enforce one tax per kind per line. This validation was broken and recently fixed. However, ENASARCO is a special case: it acts both as a withholding and a pension fund tax. We added the Withholding flag recently (odoo/odoo#226968). In realistic cases (e.g., a line with VAT + withholding 23% RIT AG + ENASARCO), the validation fails and the user gets a blocking error in account.move.send. Since ENASARCO already has dedicated support through the AltriDatiGestionali tag on the line, we allow it to pass the check as if it were only a pension fund, restoring the previous behavior before we added the withholding flag. Some validation added and fields clear up in the tax editing phase, preventing invalid cases. Ticket [link](https://www.odoo.com/odoo/project.task/5154223) opw-5154223 Forward-Port-Of: odoo/odoo#232140
Corrects a rounding problem in Mexican electronic invoicing that could block global invoices when discounts created small decimal differences. This helps affected businesses validate and issue compliant invoices without receiving the CFDI40108 error.
Original PR description
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ```…
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ``` Code : CFDI40108 Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. ``` Why the fix: ------------ The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63. https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336 Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62. opw-5023597 Forward-Port-Of: odoo/enterprise#94438
Creating a new salary offer from an existing offer now produces a valid configurator link with a unique token. This prevents broken offer links showing an invalid token value, helping recruiters share salary offers reliably.
Original PR description
_______________________________________ ## Short functional explanation of the error When creating an offer on the page of another offer, the salary configurator url doesn't contain a token, but instead, contains token = false. ## Reproduction Steps 1. Open the recruitment module. If there's no job position nor application, create some. 2. Open an existing application and click on Generate Offer. 3. Click on New on the top left of the screen. 4. Fill the new application and click on save. ### Expected behavior The field 'Link' contains an URL with, at the end, &token=x, with x a randomly generated token. ### Unexpected behavior The field 'Link' contains an URL with, at the end, &token=False. ## Origin of the issue The token generation code wasn't called when creating a new offer the way described in reproduction steps. _________________________________________ opw-4885796 ---