Daily updates from Odoo
Thursday, October 30, 2025
157 changes
11 changes
Resolved issues and error corrections
Opening the duplicate transaction view without a linked journal no longer causes an error. This prevents an accounting setup or administration screen from crashing in this edge case, improving reliability for users managing bank synchronization data.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225
Forward-Port-Of: odoo/enterprise#97196This fix prevents users from disabling required Peppol electronic invoicing services, reducing the risk of compliance problems. It also corrects invoice format labels and improves access to print-related invoice actions so accounting workflows behave more reliably.
Original PR description
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS…
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0". 1. Ensure Peppol is activated (test mode or production; not demo) 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services 3. Any service can be disabled. This commit hides the button to open the service wizard. (Also in the wizard it is now not possible to disable services anymore.) #### [FIX] account: generation of print-related entries in cog menu Before this commit: The dynamic generation of the print related entries in the cog menu does not work correctly. Problem / Solutions: There is a check in the javascript that does not work as intended. Thus the entries are not added to the cog menu in all cases. The check was intended to only block it for "new" records (not saved yet); to avoid issues in case the move has no id yet. After this commit we just check the id directly. #### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce . There we improved the eInvoice format labels for clarity. But 2 label were formatted differently than the others. This commit fixes that. #### References task-4737164 Forward-Port-Of: odoo/odoo#233629 Forward-Port-Of: odoo/odoo#233382
Restoring a database no longer breaks when the built-in OAuth provider record has previously been deleted. This prevents avoidable restore failures and helps administrators recover or duplicate databases more reliably.
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#233633This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
Original PR description
This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
This fixes an issue that prevented website editors from changing the main heading on the blog landing page. Businesses can now update the default blog title directly in the website editor, keeping public-facing content easier to customize.
Original PR description
*: html_builder, website Since [1] and [2] reverting it by mistake, the blog landing title was not editable anymore. Steps to reproduce: - Open /blog in the website editor. - Try to edit the "Our Latest Posts" heading. After this commit the heading becomes editable in the website editor. [1]: https://github.com/odoo/odoo/commit/ec49429d0d405948fcb93228e7350dfea585246f [2]: https://github.com/odoo/odoo/commit/f503f98915ab39efff80a5904494c879805bb057
The Chilean electronic invoicing flow now selects only one matching company when several share the same tax ID. This prevents processing errors for businesses with branches or duplicate company records using the same RUT.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
The attendance management filter for items needing approval now also shows records with no overtime. This helps managers review, edit, or approve all relevant attendance entries instead of missing some because they had zero overtime.
Original PR description
Currently attendances having 0 overtime are hidden by the filter "To approve", which is weird because managers might want to manually edit them, or approve them. task-5189190 Forward-Port-Of: odoo/odoo#232796
This fix restores Swedish POS blackbox validation so orders can be properly checked and synced under current POS flows. It also corrects receipt reprint tracking and organisation number formatting, helping Swedish businesses stay compliant and avoid failed order validation.
Original PR description
Before this commit, the Swedish blackbox was completely broken in 18.0 because the `push_single_order` function is no longer used. To fix this, the same approach as `pos_blackbox_be` was used, where the `preSyncAllOrders` function was overridden instead. In addition, the old receipt reprinting logic was no longer working, and so it now uses the `nb_print` field to keep track of the number of reprints. Finally, we also forward port a fix from 17.0 (ddbc1fc) to correct the format of the organisation number, which for some reason was not forward ported originally. task-5077448 Forward-Port-Of: odoo/enterprise#98179 Forward-Port-Of: odoo/enterprise#98139
This fix prevents an error when saving a changed cost on an expense category that uses vendor taxes from multiple companies. It helps users working in multi-company setups update expense categories without being blocked by company-specific tax settings.
Original PR description
Steps to reproduce: - Create 2 companies - Create a tax one each - Create an expense category - Set the 2 taxes as Vendor Taxes - Select only one of the companies - Change the cost of the expense category - Try saving --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232291
Deleting a signer role from a Sign template now works correctly even when that role has radio buttons on the template. This prevents an unexpected error and lets users clean up or adjust signing templates without interruption.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925 Forward-Port-Of: odoo/enterprise#96097
This fixes how product unit prices are shown in electronic invoices when tax-included pricing is used. It helps invoices pass Peppol validation by keeping calculated line totals consistent with the submitted subtotal.
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
16 changes
Resolved issues and error corrections
Opening the duplicate transaction wizard without a linked journal no longer causes an error. This improves reliability for Accounting users and avoids a disruptive traceback when accessing the view.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225
Forward-Port-Of: odoo/enterprise#97196This 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#233633This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
Original PR description
This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
The Chilean electronic invoicing process now selects a single matching recipient company when multiple companies share the same tax ID. This avoids processing errors for businesses with branches or duplicate RUT records.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
The attendance management "To approve" filter now shows records even when they have zero overtime. This lets managers review, edit, or approve all relevant attendances instead of missing entries that may still need attention.
Original PR description
Currently attendances having 0 overtime are hidden by the filter "To approve", which is weird because managers might want to manually edit them, or approve them. task-5189190 Forward-Port-Of: odoo/odoo#232796
Fixes Swedish point-of-sale fiscal blackbox validation so orders are correctly checked and synced again. It also restores reliable receipt reprint tracking and corrects the organization number format, helping businesses stay compliant with Swedish POS requirements.
Original PR description
Before this commit, the Swedish blackbox was completely broken in 18.0 because the `push_single_order` function is no longer used. To fix this, the same approach as `pos_blackbox_be` was used, where the `preSyncAllOrders` function was overridden instead. In addition, the old receipt reprinting logic was no longer working, and so it now uses the `nb_print` field to keep track of the number of reprints. Finally, we also forward port a fix from 17.0 (ddbc1fc) to correct the format of the organisation number, which for some reason was not forward ported originally. task-5077448 Forward-Port-Of: odoo/enterprise#98179 Forward-Port-Of: odoo/enterprise#98139
This fixes an issue where users could not save a changed cost on an expense category when vendor taxes from multiple companies were configured. Businesses using multiple companies can now update expense category costs without being blocked by company-specific tax settings.
Original PR description
Steps to reproduce: - Create 2 companies - Create a tax one each - Create an expense category - Set the 2 taxes as Vendor Taxes - Select only one of the companies - Change the cost of the expense category - Try saving --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232291
Live chat session reports now display the rating label when sessions are grouped by rating, instead of showing the underlying rating value. This makes grouped views easier for teams to read and interpret when reviewing customer feedback.
Original PR description
The group by rating in the live chat session views shows the last rating value instead of the rating text. This commit fixes the issue. task-4770430 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed 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-5082477A leftover call to a removed function was eliminated from the self-ordering service. This prevents avoidable errors in point-of-sale self-ordering flows and helps keep the customer ordering experience stable.
Original PR description
Before this commit, there was still a call to the resetTableIdentifier, even though the function had been removed, which could cause errors. opw-5166737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This 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
Calendar events created in week view now display the correct start and end times when they span multiple days. This prevents misleading times from appearing on each day segment, helping users read schedules more accurately.
Original PR description
When creating an event in week view spanning over multiple days, all parts of the event display 12pm as end date (except the last one) and 00am as the start date (except the first one). This fix allow calendar views to display the correct hour in week view when the event spans multiple days. task-4700158 Forward-Port-Of: odoo/odoo#230624
Deleting a signer role in Sign templates now works correctly when that role has radio button fields. This prevents an error that could interrupt template editing and lets users manage signing roles more reliably.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925 Forward-Port-Of: odoo/enterprise#96097
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
1 change
Resolved issues and error corrections
The Chilean electronic invoicing process now selects only one matching company when several share the same tax ID. This avoids processing errors for businesses with branches or duplicate company records using the same RUT.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
18 changes
Resolved issues and error corrections
A supporting spreadsheet filter check was moved to the shared Odoo codebase where it is now needed. This prevents issues when community features use spreadsheet-style global filter operators without the enterprise-only declaration.
Original PR description
THe method `has_searchable_parent_relation` was declared in spreadsheet_edition but it's been used in Odoo community since the introduction of operators for the global filters in http://github.com/odoo/odoo/pull/215217. Task-5189262 Forward-Port-Of: odoo/enterprise#97938
Quality checks linked to a camera now correctly trigger the connected IoT Box to take a picture instead of opening a manual file upload. The update also improves retrieval of measurements from IoT devices, helping shop floor checks run as intended.
Original PR description
Even after linking a camera to a quality control point, we still ended up in the file uploader instead of calling the *take picture* action on the IoT Box. This commit fixes the issue by restoring the call to the IoT Box, updating it to use the `iot_http` service. It also ensures measurements are correctly fetched from the IoT Box. Forward-Port-Of: odoo/enterprise#98071
A payroll accounting test for the United Arab Emirates localization was updated so its test user always has the needed payroll permissions. This prevents environment-specific test failures when demo data is not installed, improving reliability of automated validation.
Original PR description
The test `TestPayslipValidation` in `l10n_ae_hr_payroll_account` was failing on runbot without demo data:
AccessError: You are not allowed to access 'HR Work Entry Type'
This happens because the test user does not belong to a group with access to `hr.work.entry.type`. With demo data, the user inherits the necessary rights, but without demo data it fails.
This commit explicitly grants the test user the `hr_payroll.group_hr_payroll_user` group to ensure consistent access across environments.
[RB-232462](https://runbot.odoo.com/odoo/error/232462)
Forward-Port-Of: odoo/enterprise#96102Companies in Belgium that are not subject to VAT can now connect to CodaBox even when their VAT number is marked as non-applicable. The system will use the company registry number instead, reducing setup issues for eligible businesses.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155 Forward-Port-Of: odoo/enterprise#98277 Forward-Port-Of: odoo/enterprise#98025
Batch payments now show a clear warning when SEPA Credit Transfer partners are missing required country or city details for structured addresses. This helps users fix partner records before generating payment XML files that would become invalid under the upcoming rules.
Original PR description
Starting from November 15th, 2026, SEPA Credit Transfer (SCT) payments require both the partner's country and city to be defined when using structured addresses. If missing, the generated XML file will be invalid. This change adds a non-blocking red banner on the batch payment form to warn users and provide a link to review the affected partners. task-5156613 Forward-Port-Of: odoo/enterprise#97598
Opening the duplicate transactions wizard without a linked journal no longer causes an error. This improves reliability for Accounting users and prevents an unexpected crash in a setup or administrative view.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225
Forward-Port-Of: odoo/enterprise#97196This fix aligns Enterprise and Studio navigation behavior with a related core platform change. It helps ensure page state is updated at the right time when screens load, reducing the risk of inconsistent navigation in the web interface.
Original PR description
*web_enterprise,web_studio This commit is the counter-part of odoo/odoo#233446 which changes the way the router state is updated by the action service when an action is mounted into the DOM. Some tests could be adapted and/or simplified.
This fix prevents users from creating a new workplace directly from certain employee and contract screens when that shortcut could trigger an error. Users can still select existing workplaces, reducing confusion and avoiding failed data entry in Swiss payroll workflows.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#98173 Forward-Port-Of: odoo/enterprise#93424
The Chilean electronic invoicing process now selects a single matching company when multiple companies share the same tax ID. This avoids processing errors for organizations with branches or duplicate tax identifiers.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
Default values set on salary input rules now appear automatically when those rules are selected for employees or payslips. This prevents payroll teams from having to re-enter expected default amounts and reduces the risk of incorrect payroll data.
Original PR description
## Steps to reproduce 1. Make a new salary rule with condition based on 'salary input'. 2. Enable 'Input on' employee and payslip both and set a default value. 3. Go to employees 'Payroll tab' and 'add inputs', then select the rule. 4. Similary in 'Payslip' on 'Salary inputs' tab, 'add inputs' and select the rule. ## Issue - The default values on the employee and payslips were not being reflected on selection of the rule. ## Fix - Modified '_update_payroll_properties'. It now fetches active_id and updates properties based on the default values of input rules. - Updated '_compute_payslip_properties'. Ensures that payslips without common payroll properties fall back to the default values of the related input rules. task-5072646
Deleting a signer role from a Sign template now works correctly even when that role includes linked radio buttons. This prevents an error that could interrupt template editing and improves reliability for users preparing documents for signature.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925 Forward-Port-Of: odoo/enterprise#96097
The Sign app now creates new signer fields in a more reliable order, avoiding occasional display issues caused by timing delays. This helps users add signers without inconsistent or missing form elements.
Original PR description
Refactor setTimeout usage in sign_template_sidebar.js to prevent non-deterministic behavior. The previous implementation introduced potential timing issues by relying on a fixed 100ms delay, causing span and input components to not render consistently. The refactored code ensures proper rendering order and resolves the timing-related problem. task-4926187 Forward-Port-Of: odoo/enterprise#89741
Assets created from vendor bills now calculate their original value using only the deductible portion of the related bill line. This prevents overstating asset values when part of an expense is not deductible, improving accounting accuracy.
Original PR description
We allow the user to create an asset from a bill with lines which are not fully deductible but the created asset's original value is the based on the entire balance of the journal item. It should be only the deductible part. task-5156256 Forward-Port-Of: odoo/enterprise#98327 Forward-Port-Of: odoo/enterprise#97505
Changing a contact's email address only from uppercase to lowercase, or the reverse, no longer triggers previously sent signature requests to be emailed again. This prevents duplicate messages to customers and reduces confusion around already issued signing requests.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
Appointment shared links now handle invalid booking URL entries gracefully instead of triggering an error. This prevents users from being blocked by a crash when an incorrect extra link is entered, improving reliability during appointment setup.
Original PR description
This error occurs when a user provides an invalid URL (e.g., one containing characters like “:”, “..”, etc.) in the link field. Steps to reproduce: --- - Install `appointment` module - Appointment >…
This error occurs when a user provides an invalid URL (e.g., one containing characters like “:”, “..”, etc.) in the link field. Steps to reproduce: --- - Install `appointment` module - Appointment > Shared Links > New - Fill `Appointment Types` > Link: `testurl:` (provide wrong link in Extra link) Traceback: --- `ValueError: Extra URL must use same scheme and host as base, and begin with base path` At [1], this error occurs because during computation, the method calls `urljoin`. If the URL contains a colon (e.g., ‘:’), it is compared with the base URL, and when they differ, a `ValueError` is intentionally raised at [2]. This leads to the observed error. This commit resolves the issue by catching the error when an invalid URL is provided. [1]: https://github.com/odoo/enterprise/blob/fc931c81ca7b2ebad220cf057e15583e046810b9/appointment/models/appointment_invite.py#L280 [2]: https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/odoo/tools/urls.py#L55-L58 sentry-6941171133 Forward-Port-Of: odoo/enterprise#97353
This fixes an automated test that was failing because it depended on parts of the system that were not actually available in its test setup. The test now uses available related apps, helping keep the validation pipeline reliable without changing customer-facing behavior.
Original PR description
Purpose: -------- Commit [1] added a test tour relying on the ai_app app which is not a dependency of test_discuss_full_enterprise (only ai is). This commit replaces usages of the views of the ai_app by the views of crm and im_livechat, which are dependencies of the module. Fixes https://runbot.odoo.com/odoo/runbot.build.error/233603 [1]: https://github.com/odoo/enterprise/commit/a7b6eb985e85477f38f15c0e269c2b5ae10d37f6 Forward-Port-Of: odoo/enterprise#98371
This update adjusts spreadsheet edition tests so they remain reliable after recent styling changes. It helps ensure list and pivot spreadsheet autofill behavior continues to be validated without affecting day-to-day users.
This fix prevents the Italian Point of Sale from crashing when a cashier deletes a product line from an order. It improves checkout reliability for Italian POS setups using fiscal printer localization, avoiding interruptions during sales.
Original PR description
Currently POS crashes with the Italian localization if they delete a product line. Steps to reproduce: ------------------- * Install l10n_it_pos and switch to the IT company * Create a pos and…
Currently POS crashes with the Italian localization if they delete a product line. Steps to reproduce: ------------------- * Install l10n_it_pos and switch to the IT company * Create a pos and configure Italian printer * Open shop * Add a product to cart * On the numpad try deleting the line > Observation, pos crashes Traceback: TypeError: Cannot read properties of undefined (reading 'tax_details') Why the fix: ------------ When first hitting the delete button we will put the price unit to 0. With that we have ``` const reduced_base_lines = Object.values(base_line_map).filter( (base_line) => !floatIsZero(base_line.price_unit, base_line.currency_id.decimal_places)); ``` returning an empty list. Utlimately making `reduce_base_lines_to_target_amount` return an empty list. `[][0]` returns `undefined` and we were passing `[undefined]` in parameters of `fix_base_lines_tax_details_on_manual_tax_amounts`, we enter the loop with undefined and try to access some variables. We also set `l10n_it_epson = False` in order to avoid recursively looping. opw-5184113 Forward-Port-Of: odoo/enterprise#98229
34 changes
Resolved issues and error corrections
Fixes a checkout editor issue where adding a field to the Extra Info form could crash after the form's dedicated submit button was removed. New fields are now placed at the end of the form when the usual insertion point is unavailable, allowing website editors to continue configuring checkout forms reliably.
Original PR description
Steps to reproduce: =================== 1. Add an element to the cart. 2. Enable the “Extra Info” step. 3. Try to add a field in the “Extra Info” form. → Traceback occurs. Cause: ====== In previous versions, the “Extra Info” form contained a submit button, and when adding a new field, the code attempted to insert it relative to that button. Starting from version 19.0, this button was removed and replaced by the common “Confirm” button used in other checkout steps. As a result, the element used to determine the field insertion location (`locationEl`) was `null`, causing a crash when trying to insert a new field. Solution: ========= If no target element is found, the field is now inserted relative to the last element of the form instead, preventing the traceback. opw-5160322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website shop editor now keeps product list page options visible when switching to the Style tab. This removes the need for users to click on the page first, making shop page customization more predictable and easier to use.
Original PR description
Before this PR, the ProductsListPageOption component only became visible after clicking on the web page (By example, clicking on a product). Now, by adapting the selector to target <main>, the page options remain visible when navigating to the "Style" tab.
Assets created from vendor bills with partially deductible lines now use only the deductible portion to calculate their original value. This prevents overstated asset values and helps keep depreciation and accounting records accurate.
Original PR description
We allow the user to create an asset from a bill with lines which are not fully deductible but the created asset's original value is the based on the entire balance of the journal item. It should be only the deductible part. task-5156256 Forward-Port-Of: odoo/enterprise#97505
Batch payments now show a clear warning when SEPA Credit Transfer partners are missing required country or city information for structured addresses. This helps users fix affected partner records before generating payment XML files that would become invalid under the upcoming SEPA rules.
Original PR description
Starting from November 15th, 2026, SEPA Credit Transfer (SCT) payments require both the partner's country and city to be defined when using structured addresses. If missing, the generated XML file will be invalid. This change adds a non-blocking red banner on the batch payment form to warn users and provide a link to review the affected partners. task-5156613 Forward-Port-Of: odoo/enterprise#97598
Requests for quotation created from approvals now use the currency configured for the selected vendor instead of defaulting to the company currency. This keeps purchasing amounts consistent with other RFQ creation flows and avoids currency mismatches when updating existing purchase orders.
Original PR description
Issue: When creating an RFQ from an approval, the created purchase order does not use the currency set on the vendor of the product. Rather, it uses the currency of the company, with the value converted based on the vendor's currency to get the price. This is not consistent with other ways we create RFQs, which all respect the vendor currency. Solution: Pass the vendor's currency into the values sent when creating the purchase order. In the case of modifying an existing purchase order, only modify purchase orders matching vendor's currency. opw-4549937 Forward-Port-Of: odoo/enterprise#97069
Opening the duplicate transactions wizard without a linked journal no longer causes an error. This prevents an unnecessary crash in Accounting setup or administrative workflows and lets users access the view normally.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225
Forward-Port-Of: odoo/enterprise#97196Restoring a database could fail if the built-in Odoo OAuth provider had been deleted. This fix makes the restore process handle that missing provider gracefully, avoiding an unnecessary restore error.
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#233633Odoo now blocks attempts to unbuild manufacturing orders created through subcontracting. This prevents incorrect accounting entries and helps keep stock valuation and financial records balanced.
Original PR description
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost…
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost - create a storable product (the final product), set a cost and set a vendor - for the final product set the category as avco and automated - for the final product create a bill of materials subcontracted and set the same vendor - for the components add the comp for a quantity of 1 - create a Purchase order for the final product and the same vendor and confirm - validate the receipt - From the receipt click on the valuation smart button and click on the book widget of the line of the final product - notice how there is 3 journal items line including one crediting "stock interim (Received)" - unarchive the operation type "subcontracting" - open Manufacturing/Manufacturing Orders, delete the "to do" filter and search for a Manufacturing order with your final product - unbuild it - Open accounting/journal entries and select the journal entry for the unbuild **Current behavior:** There is only two account lines. There is no line balancing the "Stock Interim" line of the manufacturing order. **Cause of the issue:** The override of _generate_valuation_lines_data in mrp_subcontracted_account adds the stock interim line on the manufacturing order. However when unbuilding, the qty is negative so we exit the function https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20 **fix** Because subcontracted Manufacturing orders are not meant to be unbuilt, we prevent it opw-4998137 Forward-Port-Of: odoo/odoo#230062
Fixes a small typo in the Manufacturing split process that prevented the wizard from completing. This helps users split manufacturing orders without encountering the reported endpoint-related error.
Original PR description
Description of the issue/feature this PR addresses: Issue Mentioned on #233410 Current behavior before PR: Issue Mentioned on #233410 Desired behavior after PR is merged: The split wizard completes successfully. <img width="1920" height="903" alt="mrp_split_wizard_solved" src="https://github.com/user-attachments/assets/9a693ecd-f84f-4d71-b861-902d46276258" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where creating a new user from a project task could accidentally turn that user's onboarding todo into a project task. This keeps onboarding reminders separate from project work, avoiding confusion in task lists and reporting.
Original PR description
Before this commit, when the user creates a new user from the user_ids field of a task, an onboarding todo will be created with the context given by Framework JS, which means, if the context contains `default_project_id` the onboarding todo will become a task inside the project instead of being a real todo (task with no project set). This commit makes sure the context is reset before creating the onboarding todo. task-5217306
This fix updates an internal automated test so it uses apps that are already included with the test module. It helps prevent false build failures and keeps quality checks reliable without changing customer-facing features.
Original PR description
Purpose: -------- Commit [1] added a test tour relying on the ai_app app which is not a dependency of test_discuss_full_enterprise (only ai is). This commit replaces usages of the views of the ai_app by the views of crm and im_livechat, which are dependencies of the module. Fixes https://runbot.odoo.com/odoo/runbot.build.error/233603 [1]: https://github.com/odoo/enterprise/commit/a7b6eb985e85477f38f15c0e269c2b5ae10d37f6
Appointment shared links now handle incorrectly formatted booking URLs without causing an error. This prevents users from hitting a crash when an invalid extra link is entered, improving reliability for appointment setup.
Original PR description
This error occurs when a user provides an invalid URL (e.g., one containing characters like “:”, “..”, etc.) in the link field. Steps to reproduce: --- - Install `appointment` module - Appointment >…
This error occurs when a user provides an invalid URL (e.g., one containing characters like “:”, “..”, etc.) in the link field. Steps to reproduce: --- - Install `appointment` module - Appointment > Shared Links > New - Fill `Appointment Types` > Link: `testurl:` (provide wrong link in Extra link) Traceback: --- `ValueError: Extra URL must use same scheme and host as base, and begin with base path` At [1], this error occurs because during computation, the method calls `urljoin`. If the URL contains a colon (e.g., ‘:’), it is compared with the base URL, and when they differ, a `ValueError` is intentionally raised at [2]. This leads to the observed error. This commit resolves the issue by catching the error when an invalid URL is provided. [1]: https://github.com/odoo/enterprise/blob/fc931c81ca7b2ebad220cf057e15583e046810b9/appointment/models/appointment_invite.py#L280 [2]: https://github.com/odoo/odoo/blob/9900375bc0bac2754150fd8cd6a1e45ecad8da83/odoo/tools/urls.py#L55-L58 sentry-6941171133
The Add to Cart button in the product options popup now appears in the shopper's selected website language. This improves the buying experience for non-English customers and keeps the checkout flow consistent across languages.
Original PR description
- t-out is used for variables, so static text inside it isn’t picked up for translation. - Replaced it with a direct <span> so the text is automatically translatable **Before Fix:** <img width="1185" height="915" alt="image" src="https://github.com/user-attachments/assets/dc035e6a-25d1-4b88-9b8f-c013a0aeb75b" /> **After Fix:** <img width="1185" height="915" alt="image" src="https://github.com/user-attachments/assets/80bd5e7b-c705-49a8-a785-86e32bc54daf" /> **Steps to reproduce before the fix:** Go to Website → change the website language to any non-English language. Add any product to the cart. A Product Configuration wizard (for options) will open. The “Add to Cart” button for options is not translated. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This restores the demo company data needed by the Mexican payroll module when it is installed on its own. It prevents installation errors caused by payroll demo records referring to a company that was no longer included.
Original PR description
In the pr #95221 the data from the demo company where no new fields were added was deleted. This decision was made to standardize the demo data in the smallest number of modules. However, the l10n_mx_hr_payroll module does not depend on any other l10n_mx module, as it does not need any of the information added by the other modules, but it does add information about departments and other items based on the company's demo data. This caused an error when installing this module alone, as it attempted to add this information to a company that did not exist. To fix this, the company information is also added as demo in this module, as it was before. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an outdated upgrade step that could block database upgrades for French point-of-sale certification. The needed sequence update is already handled elsewhere, so upgrades can proceed without hitting missing-field errors.
Original PR description
- In Odoo 19, the pos.config fields sequence_id and sequence_line_id were renamed to order_seq_id and order_line_seq_id. The removed migration script…
- In Odoo 19, the pos.config fields sequence_id and sequence_line_id were
renamed to order_seq_id and order_line_seq_id. The removed migration script
https://github.com/odoo/odoo/commit/2ead34e974f55dadf791ff6b2924edbf43442b34#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44R98-L132
still referenced the old field names, causing UndefinedColumn errors during
upgrade. The logic is already handled by the main migration script using the
https://github.com/odoo/upgrade/pull/8197/files#diff-d415d26b86040ad22ab82c184e6db20ec4e9a61058d9a9dbf3668ca21bcbaf19R42-R50
new field names, so this file is no longer required.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1509, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 185, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 449, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 217, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/19.0/addons/l10n_fr_pos_cert/upgrades/1.1/post-sequence-no-gap.py", line 2, in migrate
cr.execute("""
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.errors.UndefinedColumn: column pconfig.sequence_id does not exist
LINE 9: AND (pconfig.sequence_id = iseq.id or pconfig.sequen...
^
```
opw-5152559
upg-3179288
tbg-2205
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe mailbox search panel now uses the full screen width on mobile instead of appearing squeezed beside the message list. This makes searching inbox, starred, and history messages easier and more usable on phones.
Original PR description
Before this commit, the search panel in mailboxes (inbox, starred, history) took only part of the screen in mobile. This happens because the template being used in mobile for mailbox is the same as…
Before this commit, the search panel in mailboxes (inbox, starred, history) took only part of the screen in mobile. This happens because the template being used in mobile for mailbox is the same as desktop UI for discuss app. This component `DiscussContent` is used because mailboxes are not supported in chat windows, and full-screen conversations in discuss on mobile are actually chat windows. Reusing the `DiscussContent` component is almost the desired UX/UI. The side panel however was not designed for small screen, thus action panel is very narrow and is hard to use in mobile. This commit fixes the issue by making the action panel mutually exclusive to message list in mobile, so that when search panel is open it takes the whole width of screen. We don't need to see message list in mobile, and thanks to chat window also using search panel that takes the whole screen, the search panel is already designed to auto-close itself and jump to a message. Part of Task-4967066 Before / After <img width="383" height="672" alt="Screenshot 2025-10-28 at 18 16 10" src="https://github.com/user-attachments/assets/f7a0bd0d-33ff-4e65-8b0e-0d3a0611b82c" /> <img width="382" height="673" alt="Screenshot 2025-10-28 at 18 15 52" src="https://github.com/user-attachments/assets/79f85cf1-e758-43fd-bc02-8e809e9795e3" />
The Chilean electronic invoicing process now uses only one matching company when several records share the same tax ID. This avoids processing errors for organizations with branches or duplicate company records using the same RUT.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
Lithuanian payroll now avoids charging the pension contribution twice when an employee participates in the pension accumulation system. This helps ensure payslips reflect the expected employee social security contribution and prevents overstated deductions.
Original PR description
**Issue**
When generating a payslip for an employee with the `l10n_lt_pension` setting enabled on the contract ("Participate to pension accumulation system"):
- the SSC is raised from 19.5% to 22.5%
- a 3% pension contribution ("Pension Scheme") is added This effectively doubles the expected contribution.
Various sources (e.g. https://taxsummaries.pwc.com/lithuania/individual/other-taxes) seem to show this is not correct.
opw-5067664
Forward-Port-Of: odoo/enterprise#98276
Forward-Port-Of: odoo/enterprise#95880Users can now open the inventory valuation report for future dates without hitting an error. This matters for businesses reviewing projected or forward-dated inventory values, especially when purchases use lot tracking and average costing.
Original PR description
Currently, an error occurs when a user attempts to access the stock valuation report for a date beyond today. **Steps to replicate:** - Install `stock_account`, `purchase_stock`, `accountant`. - Go…
Currently, an error occurs when a user attempts to access the stock valuation report for a date beyond today. **Steps to replicate:** - Install `stock_account`, `purchase_stock`, `accountant`. - Go to settings, set `Inventory Cost Method` to Average Cost(AVCO) and Turn on `Lots and Serial Numbers`. - Go to Products and create a new one with name `test`, set `Track Inventory` - `by lots`. - On the `Inventory` page turn on `Valuation by Lots/Serial`. - Open RFQs, Create a new one with test product and Click `Confirm Order` > Click `Receive`. - Set the Lot name by clicking the `Details` button on the move lines. - Click `Validate`, go to `Purchase > Orders > Purchase Orders`. - Select the currently made Purchase Order (It will be in the `Waiting Bills` state) and Click on the `Create bills` Button, Confirm it (it should be in the paid state now). - Now go to `Accountant > Review > Inventory Evaluation` and select and date ahead of today, the error will occur. **TL;DR:** - Install `stock_account, purchase_stock, and accountant`. - Create a product tracked by lots with AVCO costing and `Valuation by Lots/Serial` enabled. - Create a Purchase order and receive it (assign a lot), then create and confirm the bill for the same. - Finally, go to `Accountant > Review > Inventory Valuation`, select a future date — the error occurs. **Error:** `TypeError: can't compare datetime.datetime to datetime.date` **Cause:** - The error occurs because of recent commit [PR] where `aml.date` is typecasted from `datetime.date` to `datetime.datetime`, but the `at_date` is received as `datetime.date` [1] and this causes the error. - The `at_date` is converted to `datetime.date` from string at line [2]. **Solution:** - Now we don't convert `aml.date` to datetime since both `aml.date` [3] and `at_date` [4] are instances of `datetime.date`. Additionally, `account.move` are based on date rather than datetime. [PR]: https://github.com/odoo/odoo/pull/227567/commits/aec7d3244aa25af626cefd875f021d0d24ce418d [1]: https://github.com/odoo/odoo/blob/7e0cc5ec686a52b8c1f8270213acac54575ed469/addons/purchase_stock/models/stock_move.py#L157 [2]: https://github.com/odoo/odoo/blob/7e0cc5ec686a52b8c1f8270213acac54575ed469/addons/stock_account/report/stock_valuation_report.py#L32 [3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/account/models/account_move_line.py#L69-L73 [4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_account/report/stock_valuation_report.py#L32 sentry-6933268158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Dimona-related employee fields are now shown only for Belgian employees instead of appearing for everyone. This reduces confusion for companies managing employees in multiple countries and keeps employee forms relevant to each worker's location.
Original PR description
Before this commit, the fields about dimona were shown for all employees, now these fields will be displayed only for belgian employees. task-5148931 Forward-Port-Of: odoo/enterprise#96703
This fixes electronic invoicing settings so required Peppol services can no longer be disabled, reducing the risk of compliance issues. It also corrects invoice format labels and restores some print menu entries so users see the expected invoice actions.
Original PR description
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS…
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0". 1. Ensure Peppol is activated (test mode or production; not demo) 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services 3. Any service can be disabled. This commit hides the button to open the service wizard. (Also in the wizard it is now not possible to disable services anymore.) #### [FIX] account: generation of print-related entries in cog menu Before this commit: The dynamic generation of the print related entries in the cog menu does not work correctly. Problem / Solutions: There is a check in the javascript that does not work as intended. Thus the entries are not added to the cog menu in all cases. The check was intended to only block it for "new" records (not saved yet); to avoid issues in case the move has no id yet. After this commit we just check the id directly. #### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce . There we improved the eInvoice format labels for clarity. But 2 label were formatted differently than the others. This commit fixes that. #### References task-4737164 Forward-Port-Of: odoo/odoo#233629 Forward-Port-Of: odoo/odoo#233382
This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
Original PR description
This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
The attendance management approval filter now includes records with zero overtime, so managers can still review, edit, or approve them when needed. This prevents relevant attendance entries from being hidden simply because no overtime was recorded.
Original PR description
Currently attendances having 0 overtime are hidden by the filter "To approve", which is weird because managers might want to manually edit them, or approve them. task-5189190 Forward-Port-Of: odoo/odoo#232796
The recruitment app no longer includes the AI widget in the applicant refusal reason screen because that widget has been moved into a separate bridge module. This keeps the recruitment module aligned with the new module structure and avoids showing a widget that is now managed elsewhere.
Original PR description
The ai widget was moved to a new bridge module. Task-5079755 Forward-Port-Of: odoo/odoo#227988
This fix ensures landed costs applied to manufacturing orders are reflected in the finished product's unit cost and stock move value. Businesses using average cost and perpetual valuation get more accurate inventory valuation for manufactured goods, matching the behavior already available for purchase receipts.
Original PR description
**Problem:** landed cost does not work with MO **Steps to reproduce:** - in settings, enable the landed cost setting - create two storable product (the final prod and the comp) - set a positive cost…
**Problem:** landed cost does not work with MO **Steps to reproduce:** - in settings, enable the landed cost setting - create two storable product (the final prod and the comp) - set a positive cost on both - set an on hand quantity for the comp - set the category of the final product as avco perpetual - create a BOM for the final prod where the component is the comp product. - create a third product (the landed cost) - for the product type select service - in the purchase tab check 'is landed cost' - create a manufacturing order for the final product - confirm and produce all - navigate to Inventory/reporting/stock, search for your product and notice the unit cost. - open landed costs and click on New - select the manufacturing order and add the landed cost - validate - navigate to Inventory/reporting/stock **Current behavior:** the unit price of your product has not changed. I you navigate to Inventory/reporting/move analysis and check the move with the reference of the MO, the value of the move has not changed either. **Expected behavior:** Both these value should have been impacted by the landed cost like they would have if we were adding the landed cost to a picking. **Cause of the issue:** When calling _get_value_data on a move, - If there is no production_id, the return value is computed in the super method. There, when _get_value_from_account_move is called, https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_account/models/stock_move.py#L299 the override in sotck_landed_costs adds the landed costs to 'value' https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/stock_landed_costs/models/stock_move.py#L18-L22 - But if the move has a production_id the return is computed in the mrp_account override. https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/mrp_account/models/stock_move.py#L14-L19 But there is no mechanism to take into account the landed cost. opw-5170554
The salary package test setup was corrected to rely only on access groups from modules it already depends on. This prevents test failures caused by referencing payroll groups that may not be installed, improving reliability without changing user-facing behavior.
Original PR description
Before this commit: Running `hr_contract_salary` tests were failing, due to groups used from the module `hr_payroll`, which is not part of the dependencies. After this commit: Use groups from the dependencies. runbot-233547
This fixes a small configuration typo in Indian Payroll that could cause an error when the system looked for the wrong access group. The change helps payroll-related screens or actions load correctly without unnecessary interruptions.
Original PR description
Before this commit an error would trigger caused by a small typo where instead of referencing the hr_payroll module it referencd the hr module which did not define that group. The first appearance is odoo/enterprise#90795. task-5129283
This fix helps the Attendance app handle missing overtime-related day information safely. It reduces the chance of unexpected errors when processing attendance rules, improving reliability for HR operations.
Original PR description
add extra guard for access unusual_days dict using `.get(key, None)` instead of normal `dict[key]` Task: 5107868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deleting a signer role from a Sign template now works even when that role has radio buttons on the template. This prevents an error that could interrupt template editing and helps users manage signer roles more reliably.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925 Forward-Port-Of: odoo/enterprise#96097
The Sign app now handles the steps for adding a new signer in a more reliable order. This prevents occasional display issues where signer fields might not appear correctly, improving consistency for users preparing documents for signature.
Original PR description
Refactor setTimeout usage in sign_template_sidebar.js to prevent non-deterministic behavior. The previous implementation introduced potential timing issues by relying on a fixed 100ms delay, causing span and input components to not render consistently. The refactored code ensures proper rendering order and resolves the timing-related problem. task-4926187 Forward-Port-Of: odoo/enterprise#89741
This fix allows users to update an expense category's cost when vendor taxes from multiple companies are configured. It prevents a save error in multi-company setups, making expense category maintenance smoother for finance and HR teams.
Original PR description
Steps to reproduce: - Create 2 companies - Create a tax one each - Create an expense category - Set the 2 taxes as Vendor Taxes - Select only one of the companies - Change the cost of the expense category - Try saving --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232291
The scheduled SAT status check for Mexican electronic invoices now avoids repeatedly processing the same first batch of invoices. This helps ensure all eligible received invoices are checked over time, so cancellations or status changes from SAT are less likely to be missed.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.
Forward-Port-Of: odoo/enterprise#93205This fixes an issue in the HTML editor where typing next to a linked portion of formatted text could lose the intended formatting. Users editing website or email content should now see more consistent text styling around links, reducing accidental visual inconsistencies.
Original PR description
Problem: If we add a link on a slice of formatted text we end up being able to type unformatted content at the link edges. Cause: After https://github.com/odoo/odoo/commit/3bcbd6f34facb9c88290dbd6496cc5103665a0a2 the `span` can be split and `feff`s are placed around the link, precisely between the link and the `span`. This allows writing unformatted content at the caret when placed between them. Solution: Ensure that the link is created inside the `span`. Also prevent the formatting applied by `.btn` when the link is inside a `span`. Steps to reproduce: 1. Add "abc". 2. Format all the text: set font size 48 (or whatever). 3. Select "b". 4. Create a link on "b" only. 5. Put caret before "a". 6. Press Arrow left. 7. Type any character. → The character is not formatted as the link content. task-5092298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231980 Forward-Port-Of: odoo/odoo#228353
This fixes an internal test issue where demo products could interfere with online shop product filter checks. The change keeps test data isolated so validation results are more reliable, without changing customer-facing shop behavior.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Set up a database with demo data; 2. run `:TestWebsiteSaleProductFilters.test_latest_sold_filter`. Issue ----- Test fails. Cause ----- The filter retrieves demo products that aren't part of the test suite. Solution -------- In `setUpClass`, execute a SQL query archiving all nonrelevant product templates/variants, bypassing any ORM-level constraints. runbot-233399 Forward-Port-Of: odoo/odoo#232793
15 changes
Resolved issues and error corrections
The Chilean electronic invoicing flow now only selects one recipient company when multiple company records share the same tax ID. This prevents errors in cases such as branch structures where duplicate RUT values exist, helping email-based document processing run more reliably.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
This fix ensures Turkish Nilvera e-invoice tax setup only runs for main companies, not their branch companies. It prevents duplicate tax records during setup, reducing accounting configuration errors for businesses using branch structures.
Original PR description
Adds parent_id check on the domain to ensure taxes are only loaded for root companies. This prevents duplicate tax creation on branch (child) companies when initializing tax templates. task-5176333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restoring a database no longer fails if the default Odoo OAuth provider was previously deleted. This prevents an avoidable restore error and helps keep database recovery operations reliable.
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#233633This fix lets Point of Sale users settle customer balances when Saudi ZATCA e-invoicing is enabled. Settlement payments will no longer be incorrectly treated as new invoices, avoiding blocked payments and duplicate e-invoice attempts.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98353 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98353 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when a cashier starts a Settle Due payment in Point of Sale but backs out before completing it, the order is no longer treated as an account settlement. This prevents normal sales from being incorrectly flagged, reducing checkout and compliance issues in related integrations.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where Point of Sale users in Saudi Arabia could not settle customer balances when ZATCA e-invoicing was enabled. Settlement payments will no longer be forced to create a new invoice, allowing users to complete the payment correctly while avoiding duplicate e-invoices.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98456 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98456 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a cashier starts a Settle Due payment and then backs out, the order is now returned to normal sale status. This prevents regular purchases from being mistakenly treated as account settlements, reducing checkout and reporting errors.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents sales order lines from overstating invoiced quantities when product and unit-of-measure rounding settings differ. Businesses get more accurate invoice status tracking, reducing the risk of billing confusion or incorrect follow-up actions.
Original PR description
Rounding of quantity of product is no longer done during calculation of invoiced field of sale order line. Rounding was leading to incorrectly round up the quantity if the decimal precision of product units of measure was different than rounding of used unit of measure. opw-4866333 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase orders are now protected from errors caused by deleting a unit of measure that is still used on an order line. This keeps order confirmation reliable and guides users to keep required measurement data available while it is in use.
Original PR description
When a user deletes the UoM used in a purchase order line and then tries to confirm the purchase order. Steps to reproduce: --- - Install `purchase_stock` module(without demo) - Create a New PO > Add a product in Line (with UoM=Units) - Remove UoM in order line and select `Dozen` in it > Save - Settings > Units of Measure Categories > Open `Units` > Remove `Dozen` - Orders > Requests for Quotation > Open PO > `Confirm Order` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0` This error occurs because, after the UoM is deleted, the `product_uom` field becomes empty, which leads to an error. Solution: --- This commit resolves the error by restricting the deletion of a UoM when it is still in use. sentry-6746792383 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale session names now only advance after cash details are posted successfully. This prevents skipped session numbers when an error occurs, making records easier to track and audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/enterprise/pull/98157 opw-5180712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian POS session numbering now only advances after cash details are posted successfully. This prevents missing session names after failed operations, supporting cleaner records and easier compliance checks.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/odoo/pull/233183 opw-5180712
The website loading progress bar now uses the site's primary color instead of black. This improves visibility in dark mode and creates a more consistent branded experience for visitors.
Original PR description
This commits changes the website loader progress bar color, from black to `$primary`. This provides a better contrast in dark mode as well as better consistency. task-5170115 | Before | After | |--------|--------| | <img width="1920" height="1186" alt="image" src="https://github.com/user-attachments/assets/cd9525cf-b9d6-40dd-9ffb-ed0027020ab5" /> | <img width="1920" height="1172" alt="image" src="https://github.com/user-attachments/assets/3f7d9a4b-4a3e-4fbd-a1be-826c898466cd" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When loading a sales order in Point of Sale, canceling a lot selection for tracked products now leaves the order line unchanged. This prevents incorrect lot information from being added and helps keep sales and inventory records accurate.
Original PR description
Before this commit, when loading a sale order containing an order line tracked by lot, the system prompted the user to select a lot. However, even if the user canceled the selection, the lot was still added to the order line. After this commit, the lot will no longer be set if the user cancels the selection. opw-5162487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices linked to Point of Sale orders can now be moved back to draft when changes are needed, rather than being fully blocked. Users will see a warning notification, supporting localization requirements where invoice details must be adjusted before government submission.
Original PR description
After this commit, it becomes possible to make an invoice linked to a PoS order draft, showing only a warning notification instead of blocking the action. This is required in some localizations where invoices must be modified before being sent to the government. opw-5218715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents internal product references from appearing before product names after a product is edited and saved in Point of Sale. It keeps the product display consistent without requiring staff to refresh the page.
Original PR description
In PoS, when editing and saving a product’s information, there was a bug where the product reference was shown before its name. Steps to reproduce: ------------------- * Add a reference to a product available in PoS * Open PoS * Click on the 'i' on the top right of that product * Click on Edit * Click on Save (no need to do any modification) > Observation: The reference appears before the name. Refreshing the page removes, as it triggers a new read. Why the fix: ------------ Reference are never shown in pos thank to this context key `display_default_code: false` opw-5001355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This fixes an issue where undoing or reverting edits in the web editor could restore text or child elements in the wrong sequence in some Firefox cases. The change helps preserve the original content order, reducing confusing editing results for users.
Original PR description
Problem: Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`). Cause: In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the…
Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).
Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.
Example (processed in reverse order):
```js
[
{ type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
{ type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
node: { textValue: 'b' } },
{ type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
{ type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
{ type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.
Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.
Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.
opw-5139795
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe website header now only creates the language selector area when more than one language is available. This prevents an empty menu spot from adding unwanted borders or spacing, keeping the header cleaner for single-language sites.
Original PR description
This PR calls the language selector placeholder only when multiple languages exist, avoiding an empty header list item that creates an unnecessary border or empty space. task-5150808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Reordering from a past portal order no longer changes the customer on an existing shopping cart to OdooBot. This prevents incorrect cart ownership and helps customers continue checkout without unexpected account or order details changing.
Original PR description
Versions -------- - 16.0 - 17.0 - 18.0 Steps ----- 1. Have a product that cannot be sold out of stock (but is in stock); 2. have a confirmed sales order for a portal user with said product; 3. as…
Versions -------- - 16.0 - 17.0 - 18.0 Steps ----- 1. Have a product that cannot be sold out of stock (but is in stock); 2. have a confirmed sales order for a portal user with said product; 3. as portal user, add the product to your cart; 4. go to My Account / Your Orders; 5. open the confirmed sales order; 6. click Order Again. Issue ----- The cart that was opened by the portal user now has OdooBot as Customer. Cause ----- The `_document_check_access` method returns a sale order record with `SUPERUSER_ID` in its env[^1]. Meanwhile, the `website.sale_get_order` method checks the current user's partner, and if it's different from the order's partner, it gets reassigned, assuming an address change[^2]. [^1]: https://github.com/odoo/odoo/blob/9eb0b12/addons/portal/controllers/portal.py#L439-L459 [^2]: https://github.com/odoo/odoo/blob/9eb0b12/addons/website_sale/models/website.py#L386-L404 Because `SUPERUSER_ID` is the user in the environment, the order's partner gets changed to OdooBot. Solution -------- After `_document_check_access`, add the request's user to the record's env. opw-5097915 Forward-Port-Of: odoo/odoo#233204
This fixes how IoT display devices start the Chromium browser by using the executable name expected in the latest device image. It helps ensure customer-facing displays continue to launch correctly after updating to image version 2025.11.02.
Original PR description
To ensure compatibility with the last image version 2025.11.02, we need to update `chromium-browser` executable name to `chromium`
Users can now convert very large Excel files to Odoo spreadsheets without hitting an error. This improves reliability for teams working with complex workbooks that contain many sheets.
Original PR description
Steps to reproduce: - upload a large xlsx file (e.g. with >1000 sheets) - open it and convert it to o-spreadsheet => traceback Task: 5222481