Daily updates from Odoo
Wednesday, October 8, 2025
228 changes
11 changes
Resolved issues and error corrections
UPS shipping rates can now be checked during express checkout using only the limited delivery details collected at that step. This prevents shoppers from being blocked by unnecessary street and phone requirements, making checkout smoother for ecommerce customers.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
Saving website settings with an invalid domain no longer causes an unexpected error. Users now receive a clear validation message, helping administrators correct the domain without disrupting configuration work.
Original PR description
Currently, an error occurs when user tries to save an invalid domain. Steps to replicate: - Install `website_sale`. - Go to `Settings > Website`. - In the domain field, give value as `[`. (any normal URL with a square bracket will also work). - Save and error will occur. Error: `ValueError: Invalid IPv6 URL` Cause: - The error happens because `config.get_base_url()` returns a malformed URL (like containing stray `[`), which makes urljoin [1] raise the error. Solution: - The solution prevents error by adding a constraint and raising a user-friendly `ValidationError` if the URL is invalid. [1]: https://github.com/odoo/odoo/blob/77398aefc291d33264b039e38681f0cd8f65483f/addons/website_sale/models/res_config_settings.py#L135 sentry-6805151048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223336
This fix corrects how service discounts are handled when calculating Brazilian taxes through Avalara. It prevents discounts from being subtracted twice, helping ensure more accurate tax amounts on affected service invoices.
Original PR description
Confusingly, Avalara's service API already accounts for the discount in lineNetFigure, whereas their goods API does not. In <saas-18.4 this was handled by _l10n_br_get_line_total(), but it got lost in the big refactor in saas-18.4 [1]. [1] https://github.com/odoo/enterprise/pull/82623 opw-5147143
This fixes an unreliable CRM automated tour by selecting the intended customer record and waiting until the opportunity name is properly filled in. It reduces false test failures and helps ensure CRM workflows remain stable during validation.
Original PR description
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults…
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults to `False`. - Before that PR, since we just `click` the first link we find in the dropdown, we might get a random company which exists in the database (if any) or we might hit the "create" option. In the latter case we have a non-zero chance of clicking `o_kanban_add` before the client has had the time to `name_create` the record, set the partner, call the onchange, and return with the opportunity's name, leading to an attempt to create a nameless opportunity and a "missing required field" error Selecting the very specific partner we created (correctly this time) and then actually waiting for the opportunity's name to be set should resolve the issue, and make problems in that step show up in the right location in the future rather than hit some sub-sub-sub-symptom 20 steps later. https://runbot.odoo.com/odoo/error/229719 Forward-Port-Of: odoo/odoo#230251
New user invitation emails now generate website and email links correctly. This prevents recipients from receiving malformed links, making account setup smoother and reducing support friction.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
Users with limited access rights now see the correct page title when previewing copied links. This prevents misleading generic previews and makes shared links clearer for everyday users.
Original PR description
Users without access for specific actions cannot see the right preview information, using sudo like the search for generic action but on specific model solve the issue. Steps: - Login with a user without window actions access - Copy a link somewhere to have preview dialog Actual result: - Preview title is Odoo due to access error Expected result: - Preview title is the one of the page opw-4933194 Forward-Port-Of: odoo/odoo#222435
The barcode scanning dialog no longer crashes if a user goes back or presses Esc before the camera preview is ready. This prevents an error screen and keeps the scanning workflow stable when users close the dialog quickly.
Original PR description
Steps to reproduce: 1. Install `barcode` 2. Barcode > 'click to scan' 3. Before the camera preview loads, click the back button of the dialog Issue: A traceback occurs: `OwlError: The following error occurred in onMounted: 'Cannot set properties of null (setting 'srcObject')' ` Cause: Clicking the back button triggers `onWillUnmount`, which clears the stream and sets `this.videoPreviewRef.el` to null. However, some asynchronous functions in `onMounted` are still pending and try to access the video element, leading to a crash. Solution: Add a safe check based on component status before accessing `this.videoPreviewRef.el` opw-5055566 Forward-Port-Of: odoo/odoo#229937 Forward-Port-Of: odoo/odoo#226068
Saudi Arabia localization taxes are now correctly linked to fiscal positions. This prevents invoice taxes from being unintentionally removed when a tax localization is applied, helping ensure accurate tax calculation and invoicing.
Original PR description
Starting 18.4, if the tax position linked to an invoice is not set to any tax => it removes the taxes from the invoice (RD task 5017278). For l10n_sa, no tax is linked to a tax position so if a tax localization is set then product taxes will be removed. This commit set fiscal positions to l10n_sa taxes to avoid this. opw-5011877 
The Indian withholding process now checks whether any records were selected before continuing. If nothing is selected, users receive a clear error instead of encountering an unexpected failure, improving reliability in this workflow.
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190579 Forward-Port-Of: odoo/odoo#190324
ISO 20022 payment files for Danish banks can now include the required local clearing instruction, preventing bank rejections when this information is needed. Businesses can configure whether payments use overnight or same-day clearing; if left unset, files remain unchanged.
Original PR description
The denmark banks were refusing ISO20022 documents because there was a missing field: "//PmtInf/PmtTpInf/LclInstrm/Cd" or "//PmtInf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd". One of those field should be filled by either 'ONCL' or 'SDCL' which means 'Over Night Clearing' or 'Same Day Clearing'. To fix this we added a config parameter with a key: account_iso20022.local_instrument_code where we can set OCNL or SDCL to add the required field to the iso document. If nothing is set, the field will not be added. opw-5073076 Forward-Port-Of: odoo/enterprise#96190 Forward-Port-Of: odoo/enterprise#95903
This update fixes a web interaction issue that could cause crashes when certain wait actions returned no value. It makes the behavior more reliable for developers and helps avoid interruptions in website or app interactions.
Original PR description
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 Forward-Port-Of: odoo/odoo#229029
20 changes
Resolved issues and error corrections
Website settings now catch invalid domain entries before they cause a system error. Users receive a clear validation message instead of encountering an unexpected crash when saving malformed website domains.
Original PR description
Currently, an error occurs when user tries to save an invalid domain. Steps to replicate: - Install `website_sale`. - Go to `Settings > Website`. - In the domain field, give value as `[`. (any normal URL with a square bracket will also work). - Save and error will occur. Error: `ValueError: Invalid IPv6 URL` Cause: - The error happens because `config.get_base_url()` returns a malformed URL (like containing stray `[`), which makes urljoin [1] raise the error. Solution: - The solution prevents error by adding a constraint and raising a user-friendly `ValidationError` if the URL is invalid. [1]: https://github.com/odoo/odoo/blob/77398aefc291d33264b039e38681f0cd8f65483f/addons/website_sale/models/res_config_settings.py#L135 sentry-6805151048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223336
This fix makes a CRM automated tour select the intended customer and wait until the opportunity name is ready before continuing. It reduces false test failures caused by timing issues, helping keep CRM changes validated more reliably.
Original PR description
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults…
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults to `False`. - Before that PR, since we just `click` the first link we find in the dropdown, we might get a random company which exists in the database (if any) or we might hit the "create" option. In the latter case we have a non-zero chance of clicking `o_kanban_add` before the client has had the time to `name_create` the record, set the partner, call the onchange, and return with the opportunity's name, leading to an attempt to create a nameless opportunity and a "missing required field" error Selecting the very specific partner we created (correctly this time) and then actually waiting for the opportunity's name to be set should resolve the issue, and make problems in that step show up in the right location in the future rather than hit some sub-sub-sub-symptom 20 steps later. https://runbot.odoo.com/odoo/error/229719 Forward-Port-Of: odoo/odoo#230251
Users with restricted access rights will now see the correct page title when previewing copied links. This avoids generic “Odoo” previews caused by permission checks, making shared links clearer and more useful.
Original PR description
Users without access for specific actions cannot see the right preview information, using sudo like the search for generic action but on specific model solve the issue. Steps: - Login with a user without window actions access - Copy a link somewhere to have preview dialog Actual result: - Preview title is Odoo due to access error Expected result: - Preview title is the one of the page opw-4933194 Forward-Port-Of: odoo/odoo#222435
The new user invitation email now creates website and email links correctly. This prevents recipients from receiving broken links and helps ensure a smoother signup experience.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
The barcode scanning dialog now closes safely if a user goes back or presses Esc before the camera preview finishes loading. This prevents an unexpected error message and keeps the scanning workflow smoother for users.
Original PR description
Steps to reproduce: 1. Install `barcode` 2. Barcode > 'click to scan' 3. Before the camera preview loads, click the back button of the dialog Issue: A traceback occurs: `OwlError: The following error occurred in onMounted: 'Cannot set properties of null (setting 'srcObject')' ` Cause: Clicking the back button triggers `onWillUnmount`, which clears the stream and sets `this.videoPreviewRef.el` to null. However, some asynchronous functions in `onMounted` are still pending and try to access the video element, leading to a crash. Solution: Add a safe check based on component status before accessing `this.videoPreviewRef.el` opw-5055566 Forward-Port-Of: odoo/odoo#229937 Forward-Port-Of: odoo/odoo#226068
This fix prevents saved work order time tracking lines from being accidentally removed when their time periods overlap. It keeps displayed work order duration and saved time entries aligned, improving reliability for manufacturing teams reviewing production time.
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 confrim…
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 confrim it
3- Add a new work order to the MO
4- Add two time tracking lines:
- First one an arbitary duration
- Second one sub-duration of the first one
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 durationw, 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:
The issue can be fixed by overriding inverse method `_set_duration`:
```diff
- old_order_duration = sum(order.time_ids.mapped('duration'))
+ old_order_duration = order.get_duration()
```
In order to not repeat unchanged logic in override, the unchanged part is packed into `_sync_duration_changes`.
opw-5082477The Indian withholding tax workflow now checks whether any records were selected before continuing. If nothing is selected, users receive a clear error instead of running into an unexpected failure.
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190579 Forward-Port-Of: odoo/odoo#190324
UPS shipping rates can now be checked during express checkout using only the delivery details required at that early step. This prevents customers from being stopped because street address or phone details have not yet been entered.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
This fix prevents a crash when certain web interaction steps finish without returning a value. It makes the website behavior more reliable for users and safer for developers building interactive features.
Original PR description
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 Forward-Port-Of: odoo/odoo#229029
ISO20022 payment files for Danish banks can now include the required local clearing instruction code, helping prevent rejected payment submissions. Administrators can configure overnight or same-day clearing, while leaving it unset keeps the previous behavior.
Original PR description
The denmark banks were refusing ISO20022 documents because there was a missing field: "//PmtInf/PmtTpInf/LclInstrm/Cd" or "//PmtInf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd". One of those field should be filled by either 'ONCL' or 'SDCL' which means 'Over Night Clearing' or 'Same Day Clearing'. To fix this we added a config parameter with a key: account_iso20022.local_instrument_code where we can set OCNL or SDCL to add the required field to the iso document. If nothing is set, the field will not be added. opw-5073076 Forward-Port-Of: odoo/enterprise#96190 Forward-Port-Of: odoo/enterprise#95903
Event invitation and notification emails now format event description links more safely. This prevents Gmail from breaking the event URL, helping recipients access event pages without confusion.
Original PR description
When website_event is installed an anchor tag is added inside the event description which is guaranteed to break the url in the gmail client. We now quote the description appropriately so that there's no confusion. task-5092759 Forward-Port-Of: odoo/odoo#228359
This update changes how the AI module calls internal functions to make customizations easier and align behavior with a newer Odoo version. It is a minor internal fix that helps reduce compatibility issues for future overrides without changing the user experience.
Original PR description
To ease the override and compatibility with what is done in 19.0, we call the function with kwargs instead of args.
This fixes the appraisal skills list on mobile so users can scroll horizontally to see the justification field and the add or remove buttons. It restores access to important appraisal editing controls and removes unused styling that was no longer needed.
Original PR description
Horizontal scrolling has been disabled on the appraisal skills list. An unwanted side effect of that is that the justification field along with the add and remove buttons are not visible on mobile. This PR re-enables the scrolling and removes some dead css. task-5001344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230310 Forward-Port-Of: odoo/odoo#222161
The appraisal skills list now scrolls horizontally on mobile again, so users can see the justification field and the add or remove buttons. This restores access to important appraisal skill details and actions on smaller screens.
Original PR description
Horizontal scrolling has been disabled on the appraisal skills list. An unwanted side effect of that is that the justification field along with the add and remove buttons are not visible on mobile. This PR re-enables the scrolling and removes some dead css. task-5001344 Forward-Port-Of: odoo/enterprise#96527 Forward-Port-Of: odoo/enterprise#91882
Dashboard treemap charts no longer restart their animations unnecessarily when their underlying data has not meaningfully changed. This makes spreadsheet dashboards feel steadier and less distracting for users while preserving normal chart updates when data actually changes.
Original PR description
Charts animations are played every time the chart data changes in dashboards. But the treemap data contains callbacks, which mess up the deepEqual we use to check if the data changed, since new callbacks are created each time. This adds an argument to deepEqual to ignore functions. Task: [5003595](https://www.odoo.com/odoo/2328/tasks/5003595) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents Point of Sale test failures in setups where country information is required by installed localizations. It ensures automated checks are more reliable without changing day-to-day user behavior.
Original PR description
Before this commit, some tests would fail when localizations requiring a country were installed, because the created company did not have a country set. runbot-233158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230114
This fix ensures country-specific point of sale session fields are preserved when sessions synchronize between multiple devices. Businesses using Spanish electronic invoicing features avoid losing required session information after real-time updates.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/enterprise/pull/95455 opw-5073848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228419
Point of Sale sessions in Chilean and Peruvian localizations now keep their required fiscal fields when data is synchronized across multiple devices. This prevents those fields from disappearing after device updates, helping stores avoid disrupted checkout or compliance data issues.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/odoo/pull/228419 opw-5073848 Forward-Port-Of: odoo/enterprise#95455
This fix ensures spreadsheet-related tests load the full chart library they depend on. It prevents later tests from failing unpredictably when charts such as treemap or geo charts are needed, improving test reliability without changing user-facing behavior.
Original PR description
Some tests were loading Chart.js using loadJS, without the corresponding bundle. That means that the test that comes after could fail if they required treemap/geo charts, as they weren't loaded in ChartJs. Task: [5003595](https://www.odoo.com/odoo/2328/tasks/5003595)
This fix makes automated checks for the mail HTML editor use a more reliable save action instead of clicking a save button that may still be disabled. It helps reduce false failures in Odoo's testing pipeline, supporting more stable releases without changing everyday user behavior.
Original PR description
This commit tries to solve runbot issues with mail html fields widget. It seems clicking on the save button manually is not generating a call to the backend. This could be due to the fact the button is not enabled due to the data being invalid. Therefore using the clickSave util could be useful in those situation since waiting that the button becomes enabled. This solution is not 100% sure to fix the issue in all cases but manually disabling the button is creating the issue we can observe in those runbots. There is a good chance it might work. fixes-runbot-231582 fixes-runbot-233049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227484
4 changes
Resolved issues and error corrections
Gantt view group headers now keep their sticky behavior when users scroll, even when the schedule has many or wide columns. This prevents headers from drifting out of alignment or overflowing the page, with the biggest benefit on mobile devices.
Original PR description
Gantt group headers could stop being sticky because their width was fixed based on the number and size of columns. Even though they were set to position: sticky, oversized headers could no longer remain aligned when scrolling, as they extended beyond the viewport and were constrained by the document width. This was especially noticeable on mobile, where group headers are often wider than the screen. The fix applies a max-width style to these headers, capping their size to the available space so they remain sticky without overflowing the document. task-4970992 Forward-Port-Of: odoo/enterprise#96015
UPS shipping rate checks during ecommerce express checkout now work with only the limited address information collected at that step. This prevents customers from being blocked by unnecessary street and phone requirements before they have completed checkout.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
This fix restores support for valid accented characters, such as ü, in Mexican legal names used for electronic invoicing. It helps ensure invoices are accepted by Mexico's SAT when company or customer names include these legally recognized characters.
Original PR description
Previous commit (#95207) removed accents for names including character ü which indeed is a recognized character for SAT opw-5125107 Forward-Port-Of: odoo/enterprise#96043
Fixes a problem where users could see an error message after successfully reconciling the last available batch payment in the bank reconciliation widget. The reconciliation itself already worked, but this change prevents the confusing traceback and keeps the workflow smooth.
Original PR description
…batch In the bank reconciliation widget, after reconciling the last batch payment, a traceback will be shown to the user. Steps to reproduce: - Create and confirm a customer payment - Create a batch…
…batch
In the bank reconciliation widget, after reconciling the last batch payment, a traceback will be shown to the user.
Steps to reproduce:
- Create and confirm a customer payment
- Create a batch payment including the above payment (ensure this is the only batch payment available for reconciliation)
- Open Bank reconciliation widget
- Create a Bank transaction to reconcile with the batch payment
- Add the batch payment and click "Validate"
Issue: Reconciliation succeeds, but a traceback will be shown:
```
OwlError: The following error occurred in onWillUnmount: "Cannot set properties of undefined (setting 'exportState')"
Error
at wrapError (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11557:23) (/web/static/lib/owl/owl.js:2685)
at onWillUnmount (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11626:34) (/web/static/lib/owl/owl.js:2754)
at BankRecBatchPaymentsRenderer.setup (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:217012:9) (/account_accountant_batch_payment/static/src/components/bank_reconciliation/batch_payments_list_view.js:11)
at new ComponentNode (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11305:28) (/web/static/lib/owl/owl.js:2433)
at http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:14948:28 (/web/static/lib/owl/owl.js:6076)
at BankRecEmbeddedListController.slot7 (eval at compile (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:14679:20), <anonymous>:128:32) (/web/static/lib/owl/owl.js:5807)
at callSlot (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11922:37) (/web/static/lib/owl/owl.js:3050)
at Layout.template (eval at compile (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:14679:20), <anonymous>:39:10) (/web/static/lib/owl/owl.js:5807)
at Fiber._render (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:10655:38) (/web/static/lib/owl/owl.js:1783)
at Fiber.render (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:10647:18) (/web/static/lib/owl/owl.js:1775)
Caused by: TypeError: Cannot set properties of undefined (setting 'exportState')
at BankRecBatchPaymentsRenderer.saveSearchState (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:217039:32) (/account_accountant_batch_payment/static/src/components/bank_reconciliation/batch_payments_list_view.js:38)
at BankRecBatchPaymentsRenderer.<anonymous> (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11571:26) (/web/static/lib/owl/owl.js:2699)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11400:24) (/web/static/lib/owl/owl.js:2528)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode._destroy (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11404:23) (/web/static/lib/owl/owl.js:2532)
at ComponentNode.beforeRemove (http://127.0.0.1:8982/web/assets/debug/web.assets_web.js:11534:18) (/web/static/lib/owl/owl.js:2662)
```
This occurs because we want to hide the Batch Payments tab from the reconciliation widget when no more batches are available for reconciliation but the `saveSearchState` still expects the batch payments to be defined in the view.
opw-483046628 changes
Resolved issues and error corrections
This fixes an intermittent failure in automated tests for signed document cleanup. The change adds a small time buffer so expired trashed documents are consistently recognized for deletion, improving release confidence without changing user-facing behavior.
Original PR description
Steps to reproduce
==================
Launch the test `test_gc_clear_bin` a few times
It will eventually fail:
documents.document(544,) is not false :
trash document should be deleted after gc_clear_bin
Cause of the issue
==================
The domain for wether a record should be deleted contains `('write_date', '<=', fields.Datetime.now() - relativedelta(days=deletion_delay)`
The tests fails when the write_date is in the same second as the test run.
This is because fields.Datetime.now() replaces microseconds by 0.
https://github.com/odoo/odoo/blob/14073faf1fa272b8d3411b4fe6f42c279058459d/odoo/fields.py#L2378
Solution
========
Since records needs to be at least "deletion_delay" old, we add a margin of 30 seconds to make sure they match
runbot-224207
Forward-Port-Of: odoo/enterprise#95926This fix restores reliable lookup of SEPA Direct Debit payment transactions after a recent internal search change. It helps ensure incoming payment processing can match the right transaction and continue without unnecessary failures.
Original PR description
After commit 772d8a6f2e66b13f352b56621912e33e7edcccc2,transaction search was changed to rely only on `provider_code`, instead of `custom_mode`. However, the `sepa_direct_debit` logic was not updated accordingly, resulting in transactions no longer being found. This commit adapts the code to the new search logic by using `provider_code` for transaction lookup. Forward-Port-Of: odoo/enterprise#96418
Fixes an issue where customized Unrealized Currency Gains/Losses report grouping could incorrectly block adjustment entry creation with a “No adjustment needed” message. Businesses using custom report layouts can now generate the expected draft journal entries reliably.
Original PR description
**Steps to reproduce** - Edit "Unrealized Currency Gains/Losses" report configuration as follows: - Lines > Accounts To Adjust, set GroupBy to 'currency_id, partner_id, account_id, id' - Lines > Excluded Accounts, set GroupBy to 'currency_id, partner_id, account_id, id' - In Options, check 'Unfold All' - View the report > Click 'Adjustment Entry' **Issue** Instead of creating a draft journal entry an user error "No adjustment needed" will block the action **Solution** The issue occurs because when retrieving the lines we assume they are grouped as per default, by 'currency_id, account_id' In case users modify the expression line default grouping to something else, like 'currency_id, partner_id, account_id', we no longer collect values correctly. In order to fix the issue we can unfold all and manually group values by currency_id, account_id opw-4792502 Forward-Port-Of: odoo/enterprise#90894
The cohort reporting tests were updated to match recent changes in how Odoo reloads actions and breadcrumbs after a language change. This helps ensure users see correctly refreshed navigation and labels when switching languages.
Original PR description
This commit adapts a cohort test w.r.t. the changes done in odoo/odoo#230046. Forward-Port-Of: odoo/enterprise#96372
This fix prevents the AI assistant from crashing when users request pivot-style sales reports, such as rankings by revenue. It improves reliability for Sales and AI users by correctly validating report measures before running the query.
Original PR description
The system crashes with an error when a user adds a prompt in AI and searches. **Steps to produce:** - Install the `Sales and AI` module with demo data. - Go to sales and click on the AI button on…
The system crashes with an error when a user adds a prompt in AI and searches. **Steps to produce:** - Install the `Sales and AI` module with demo data. - Go to sales and click on the AI button on top. - Add query that used pivot view like `Top 5 sales reps by revenue also make pivot view`. - Try multiple times (error only comes in terminal). **Error:** ValueError: Measure 'price_subtotal:sum' not found in model 'sale.report' for menu ID 331. **Cause:** - Here at [1], we split the measure_str and assign the first element to `measure_name`. - At [2], we try to find a field in the model using this `measure_name`, which fails. - The issue is that `measure_name` can contain both the `field` and its `aggregation` function (e.g., product_qty:sum), which is not a valid field. **Solution:** - In this PR, a new method `validate_measures` has been added to ensure that the provided measures are valid and properly defined. [1] https://github.com/odoo/enterprise/blob/f838bbd0ce425d24444b510e49752c3da8068712/ai/models/ai_agent.py#L1244-L1245 [2] https://github.com/odoo/enterprise/blob/f838bbd0ce425d24444b510e49752c3da8068712/ai/models/ai_agent.py#L1264-L1265 **sentry-6917511363,6915439025** Forward-Port-Of: odoo/enterprise#96247
The ChatGPT plugin chat window now stays visible when opened over other pop-up windows. This fixes a usability issue that could prevent users from interacting with the chat feature.
Original PR description
This PR fixes an issue with the chatgpt plugin where the chat window was rendered beneath the modal, making it unusable. The fix modifies the z-index of modal windows when the `openDialog` function of the chatgpt plugin is called. Forward-Port-Of: odoo/enterprise#94909
The Spanish VAT Book report could fail to open due to an outdated interface reference. This update corrects that reference so users can access the report normally and continue reviewing VAT information without interruption.
Original PR description
Step to reproduce - setup company for l10n_es i.e. spain localization - Go to Accounting > Reporting > Spain > VAT Book. Observation: - Traceback found Issue: - Template `l10n_es_reports.VatBooksLineName` tries to replace a xpath https://github.com/odoo/enterprise/blob/d0c17835ecc4a911bc8c8c57946eaef9e73245ab/l10n_es_reports/static/src/components/vat_books/line_name.xml#L2-L6 which do not exists, after [1] Fix: - we fix the xpath to hide the chatter/annotation button. [1] odoo/enterprise@8fae6a058bc20732bccc6e3732144d4ea2aafdad opw-5106583 Forward-Port-Of: odoo/enterprise#95724
This fixes UK tax report submissions that could be rejected by HMRC because an invalid saved device identifier was being reused. Odoo now clears the bad saved value so a valid identifier can be used, helping affected users submit successfully.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335
The spreadsheet navigation bar now displays better on mobile screens. Long spreadsheet names are shortened cleanly with an ellipsis, and the saved status stays on one line for a tidier, easier-to-read experience.
Original PR description
When opening the spreadsheet on mobile, the navbar was not well styled: - the spreadsheet name was not truncated with ellipsis - the "saved" status would take two lines (one line for the icon, one line for the text) Task: [4996784](https://www.odoo.com/odoo/2328/tasks/4996784) Forward-Port-Of: odoo/enterprise#94928
This fixes an internal accounting report test that started failing after a new Credit Card line was added to the generic chart of accounts. The change helps keep automated checks reliable and reduces the risk of delays when validating future accounting report changes.
Original PR description
- The test cases for the balance sheet failed because we added a new line, 'Credit Card' in generic CoA. runbot error: 233206
This fix prevents the Shop Floor from showing the same manufacturing component movement twice after a bill of materials is changed. It avoids an error that could block users from opening the affected work center view and adds test coverage to prevent the issue from returning.
Original PR description
### Steps to reproduce: 1. Create a BoM with two components to be consumed in an operation 2. Create a Manufacturing Order with this BoM and confirm it 3. On the BoM, remove one of the products and save 4. Go to the Shop Floor 5. Select the workcenter used in step 1 6. Got duplicate key in t-foreach ### Before this commit: Stock moves without quality checks, that are linked to a workorder but not linked to a BoM line, are included twice in the view, resulting into a traceback. ### After this commit: Include only once the stock moves, removing duplicates from the view. opw-5029970 Forward-Port-Of: odoo/enterprise#96345 Forward-Port-Of: odoo/enterprise#93482
This update removes an unnecessary validation that could interfere with Indian GSTR tax return processing. Since the system already assigns the correct tax unit when creating these returns, this helps avoid avoidable blocking errors without changing the reporting workflow.
Original PR description
This commit removes a check of tax unit constraint. It is not useful for now because system creates the tax returns, and it sets the `tax_unit_id` according so we can remove the constraint. reference task task-4750259 Forward-Port-Of: odoo/enterprise#96476
This update ensures IoT payment terminal drivers send device information in a format the database now accepts. It prevents communication errors with connected payment devices after a recent platform change.
Original PR description
This PR fixes the bytestrings being sent as such when using ctypes C/C++ libraries in iot drivers. After the PR https://github.com/odoo/odoo/pull/206903 the bytestrings are not supported anymore in the requests sent to the database from the iot and need to be decoded first. Related PR for saas-18.4: https://github.com/odoo/enterprise/pull/96547 opw-5129596 Forward-Port-Of: odoo/enterprise#96537
This update makes an automated website sales rental comparison check more reliable by adjusting how the test interacts with the page. It helps reduce false test failures, supporting smoother maintenance and more dependable releases.
Original PR description
In this commit, we ensure tour succeed each time by clicking on hidden element. Forward-Port-Of: odoo/enterprise#96498
Employee records now show the correct number of documents by including files stored in subfolders of the employee folder. Folder entries are excluded from the count, giving users a clearer and more reliable view of employee-related documents.
Original PR description
Before this commit, the documents count on the employee form view showed only the count of documents (folders included) inside the employee folder but not the ones in subfolders. This commit fix that by showing the count of every documents (folders excluded) included in the employee folder or its subfolders. Task-4944895 Forward-Port-Of: odoo/enterprise#91009
ISO20022 payment files can now include the Danish bank clearing instruction required by some banks. This helps prevent payment file rejections when using overnight or same-day clearing, while leaving files unchanged if no setting is configured.
Original PR description
The denmark banks were refusing ISO20022 documents because there was a missing field: "//PmtInf/PmtTpInf/LclInstrm/Cd" or "//PmtInf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd". One of those field should be filled by either 'ONCL' or 'SDCL' which means 'Over Night Clearing' or 'Same Day Clearing'. To fix this we added a config parameter with a key: account_iso20022.local_instrument_code where we can set OCNL or SDCL to add the required field to the iso document. If nothing is set, the field will not be added. opw-5073076 Forward-Port-Of: odoo/enterprise#96190 Forward-Port-Of: odoo/enterprise#95903
The German Datev export no longer fails when sale or purchase receipts are created without a customer or vendor. This keeps accounting exports reliable for receipt workflows introduced in recent versions.
Original PR description
Since 18.4, there are purchase receipts as a function for vendor bills, where you can choose to put no vendor in the vendor field, the same is true for invoices with sale receipts. Making sure that partners are not Null task-5114562 Forward-Port-Of: odoo/enterprise#95649
Chilean electronic invoice emails containing accented characters could fail during XML processing. This change lets the XML parser handle the original invoice data directly, preventing those import crashes and improving reliability for affected invoices.
Original PR description
### Issue:
The invoice XMLs having special characters like "Ó" received in DTE emails will trigger a traceback.
### Cause:
`.decode('utf-8')` will try decoding the bytes in utf-8 but Ó is not UTF-8, so there is a traceback:
```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 1734: invalid continuation byte
```
In any case, it crashes at the next line: `xml_content = etree.fromstring(xml_dte)` because the XML specifies the encoding (i.e. unicode) but the true encoding is `utf-8` so an error is raised:
```
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
```
### Solution:
Remove `.decode('utf-8')` when decoding. The method `fromstring` accepts bytes and will use the encoding specified in the XML.
opw-5124661
Forward-Port-Of: odoo/enterprise#96410This fix prevents errors when users add files or binary content while creating records before they are fully saved. It ensures the AI feature handles those temporary files consistently, reducing interruptions during quick creation and uploads.
Original PR description
Before this fix, when unsaved binary fields are present in a record during quick creation or file uploading, the `ir.attachment` is not yet created for that record. This causes `raw bytes` to remain in `vals[fname]` and later crashes `_get_ai_context()` during `json.dumps()`. Now `_ai_read` always generates a proper `file_ref` for unsaved binaries, using the same logic as the non-attachment branch, ensuring consistent `files_dict` entries and preventing crashes. task-19060 Forward-Port-Of: odoo/enterprise#94470
Adds coverage to ensure rental products added from the shop use the correct default rental dates instead of falling back to a 24-hour period. It also helps prevent customers from mixing overnight rental periods with other rental periods, reducing checkout errors and pricing confusion.
Original PR description
task-5065762 Forward-Port-Of: odoo/enterprise#94283
Appointment bookings with multiple staff members now calculate manual confirmation thresholds using the combined capacity of all assigned users. This prevents bookings from being unnecessarily marked as requests when enough total capacity is still available.
Original PR description
ISSUE ===== Introduced in bce7e94650c337a9046958a7689c81db5b2a4c73, We now handle capacity when booking users. They have each a max capacity of user_capacity for each slot. However, when it comes to…
ISSUE ===== Introduced in bce7e94650c337a9046958a7689c81db5b2a4c73, We now handle capacity when booking users. They have each a max capacity of user_capacity for each slot. However, when it comes to the manual confirmation treshold, we do not account for the total capacity of all users combined, but consider the maximum to be user_capacity! This can lead to a lot of 'request' meetings as we reach the manual confirmation percentage very quickly. STEPS TO REPRODUCE ================== 1. Create an appointment type based on users, with 'manage capacities' enabled, 'manual confirmation' enabled and 'when over' 50% total capacity. Set 2 users and 3 'seats max'. This way, the total capacity of your appointment is 2 * 3 = 6 per slot. 2. As a public user, take an appointment for 2 capacity in the front end 3. The meeting will end up as a 'request', even though the capacity booked is 2/6 < 50%, and should be 'booked' FIX === We now multiply the number of users on the appointment type by the user_capacity when computing the total capacity and comparing it to the asked capacity on booking an appointment. A test is included Task-4930778 Forward-Port-Of: odoo/enterprise#94446 Forward-Port-Of: odoo/enterprise#89876
Swiss ISO20022 payment files generated for vendor payment batches have been corrected so they meet current Swiss bank validation requirements. This helps companies using Swiss bank payments avoid rejected payment files and payment processing delays.
Original PR description
Since July, the iso20022 payment method is to not be accepted by some Swiss banks anymore. How to reproduce? Install account_iso20022 and enable batch payments in the accounting settings. Configure your journal adding the payment method "Swiss ISO20022" in the outgoing payments and setting the XML format as "pain.001.001.09". Pay a vendor bill using the "Swiss ISO20022" payment method. Go to the journal payment, select the previous payment and create a batch. On the batch payment, you can find the XML file which is not validated by Swiss banks. test validation on: https://ubs-paymentstandards.ch/login opw-4976852 opw-4675667 opw-4996910 opw-4895258 opw-5006895 task-id: 5000729 Forward-Port-Of: odoo/enterprise#95379 Forward-Port-Of: odoo/enterprise#92532
Publishing and sending planning slots now respects the filters users selected in the planning view, such as role or team filters. This prevents unintended shifts from being published when users change the date range before publishing.
Original PR description
To reproduce: ============= -Reset all planning.slot to draft -Search "Dev" role -In weekly Gantt view, click on publish & send -Change date to match the current month (or any other period) -Publish Problem: ========= We filter only by datetime and ignore domain from context : https://github.com/odoo/enterprise/blob/20b45f6c65c78a572a3f26b78f6ed458accf7c9f/planning/wizard/planning_send.py#L31-L33 Solution: ========= - Get active domain from context and override only it's date_time since it changed. opw-5017014 Forward-Port-Of: odoo/enterprise#96207 Forward-Port-Of: odoo/enterprise#93295
This fixes cases where certain tax returns did not get marked as completed after reaching their final review or submission step. It also prevents the system from trying to finalize payments for returns that do not support a paid state, avoiding submission errors for affected localizations.
Original PR description
First. Returns that are generic_state_review and generic_state_review_submit weren't marked as completed once they reached their last state. Second, When submitting tax returns, we tried to automatically try to finalize the payment if there was nothing to pay. But some tax returns dont have a paid state since they use the generic_state_review_submit state_worfklow. This makes sure we are not trying to pay any returns that cannot be paid. Steps to reproduce: - Create a return with generic_state_review_submit or use a return with it, like l10n_lt_reports.vat_return_type - Validate every checks - Try to submit the return - 💥 Traceback 💥 Forward-Port-Of: odoo/enterprise#95655
Internal agents can now translate WhatsApp messages even when they are only viewing a conversation and are not listed as members. This removes an unnecessary limitation and helps support staff understand customer messages consistently.
Original PR description
Before this commit, when an agent that is not member of whatsapp but is peeking the conversation, the agent could not translate the message. This happens because the translation feature is limited to internal users, but this was determined based on the self member relational field. This works when the agent is a member but when not a member this was arbitrarily disabling the feature. This commit fixes the issue by looking at whether the user is internal or not, based on self persona independently on whether the agent is member or not of the conversation. Task-5111383 Forward-Port-Of: odoo/enterprise#96205 Forward-Port-Of: odoo/enterprise#95474
Opening Quality Points from a product in Point of Sale could fail when the wrong product list view was reused. The fix ensures the correct Quality Control view opens, so users can access quality points without an error.
Original PR description
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue**…
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue** `UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: ""quality.point"."product_variant_count" field is undefined."` **Root Cause** https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/point_of_sale/views/product_view.xml#L23-L25 - View reference is passed in the context. - When this context is propagated to `action_see_quality_control_point`, https://github.com/odoo/enterprise/blob/7b777bffbebfb6503bb348005e9ce076825926e4/quality_control/models/quality.py#L579-L584 https://github.com/odoo/enterprise/blob/2e08282ca275bf1e66c58e28391f11f8bd7884d2/quality_control/views/quality_views.xml#L859-L868 - Than traceback occurs because the action does not pass a `view_id`. - When the context contains `list_view_ref`, it attempts to load the product template list view with the `quality.point` model. - This leads to a traceback since the fields defined in that view do not exist on the `quality.point` model. **Solution** - Pass a proper `view_id` from the Python side to ensure the correct view is loaded, preventing `list_view_ref` from forcing to load an invalid template. **opw-** **5090505** Forward-Port-Of: odoo/enterprise#95040
UPS shipping rate checks during ecommerce express checkout now work when shoppers provide only the minimal delivery details required at that stage. This prevents checkout failures caused by unnecessary street and phone validation before the full address is collected.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#96572 Forward-Port-Of: odoo/enterprise#78788
This fixes Brazilian Avalara tax calculations for service invoices with discounts. Discounts are now handled consistently with Avalara's service tax data, preventing understated taxable amounts and incorrect tax totals.
Original PR description
Confusingly, Avalara's service API already accounts for the discount in lineNetFigure, whereas their goods API does not. In <saas-18.4 this was handled by _l10n_br_get_line_total(), but it got lost in the big refactor in saas-18.4 [1]. [1] https://github.com/odoo/enterprise/pull/82623 opw-5147143 Forward-Port-Of: odoo/enterprise#96585
30 changes
Resolved issues and error corrections
Moving a CRM opportunity into an empty pipeline stage with recurring revenues enabled no longer triggers an error. This keeps sales teams' pipeline views stable during normal drag-and-drop updates.
Original PR description
**Steps to reproduce:** 1.Install crm 2.Enable 'Recurring Revenues' from settings 3.Go to CRM > 'My pipeline' > Create a record here 4.Enable debug mode 5.Either create a new stage or move records from any stage to make an empty stage 6.Move created record to an empty stage **Issue:** This Traceback accurs : "Uncaught Promise > Invalid props for component 'AnimatedNumber': 'value' is not a number" **Cause:** https://github.com/odoo/odoo/blob/5ade756227abf58769ff904651628a3ccaf8e19a/addons/web/static/src/views/view_components/animated_number.js#L8-L21 AnimatedNumber expects a numeric value for its value prop. When moving to an empty stage, the aggregate value is false, which is not a valid number for the component. **Solution:** Check for the rrmAggregate value to render the component. opw-4972672 Forward-Port-Of: odoo/odoo#221705
The accounting dashboard's drag-and-drop buttons and upload areas now automatically adapt to light and dark themes. This removes mismatched hardcoded colors, improving visual consistency and readability for users who switch themes.
Original PR description
Current behavior before PR: - Drag & drop buttons and upload drop zones of dashboard cards had hardcoded backgrounds (#F2EDF0 / grey), which did not adapt to dark mode. Desired behavior after PR is merged: - Removed hardcoded background colors from drag & drop button and upload drop zone cards on dashboard and updated their background to adapt in light & dark modes. Changes implemented: - Removed hardcoded background color (`#F2EDF0`) from `account_drag_drop_btn` & `drag_to_card` CSS classes. - Removed overriding background-color property from `o_drop_area` CSS class. - Updated background-color of `o_drop_area` in `o_account_dashboard_kanban_view` CSS class to `o-view-background-color`. task-5092460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227707
Saving an invalid website domain now displays a user-friendly validation message instead of causing an unexpected error. This helps administrators quickly correct domain entries and prevents disruption when updating website settings.
Original PR description
Currently, an error occurs when user tries to save an invalid domain. Steps to replicate: - Install `website_sale`. - Go to `Settings > Website`. - In the domain field, give value as `[`. (any normal URL with a square bracket will also work). - Save and error will occur. Error: `ValueError: Invalid IPv6 URL` Cause: - The error happens because `config.get_base_url()` returns a malformed URL (like containing stray `[`), which makes urljoin [1] raise the error. Solution: - The solution prevents error by adding a constraint and raising a user-friendly `ValidationError` if the URL is invalid. [1]: https://github.com/odoo/odoo/blob/77398aefc291d33264b039e38681f0cd8f65483f/addons/website_sale/models/res_config_settings.py#L135 sentry-6805151048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223336
This fixes how the HTML editor recognizes background-related styling classes, including variants with custom prefixes. It prevents unrelated class names from being treated as color styles, making editor formatting more reliable.
Original PR description
The previous regex `/\bbg-[^\s]*\b/` did not correctly handle class names with prefixes and could incorrectly match strings like 'someprefix-bg-primary'. Updated regex: `/(?:^|\s)(?:text-)?bg-[^\s]+/` | Feature | Old Regex | New Regex | |:----------------------|:--------------|:-------------------------------| | 'bg-*' classes | ✅ Yes | ✅ Yes | | 'text-bg-*' classes | ✅ Yes | ✅ Yes | | Avoid 'someprefix-bg-*' | ❌ Incorrect | ✅ Correct | | Custom prefixes | ❌ No | ✅ Yes (e.g., 'foo-bg-*') | | Boundary detection | \b word | ^ or whitespace (?:^|\s) | This fix ensures accurate parsing of CSS class names in the codebase while supporting both standard and custom prefixes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a CRM test select the intended customer record and wait for the opportunity name to be ready before continuing. It reduces false test failures and helps keep CRM quality checks stable without changing customer-facing behavior.
Original PR description
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults…
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults to `False`. - Before that PR, since we just `click` the first link we find in the dropdown, we might get a random company which exists in the database (if any) or we might hit the "create" option. In the latter case we have a non-zero chance of clicking `o_kanban_add` before the client has had the time to `name_create` the record, set the partner, call the onchange, and return with the opportunity's name, leading to an attempt to create a nameless opportunity and a "missing required field" error Selecting the very specific partner we created (correctly this time) and then actually waiting for the opportunity's name to be set should resolve the issue, and make problems in that step show up in the right location in the future rather than hit some sub-sub-sub-symptom 20 steps later. https://runbot.odoo.com/odoo/error/229719 Forward-Port-Of: odoo/odoo#230251
Link previews now show the correct page title even for users who lack access to certain backend actions. This prevents confusing generic “Odoo” preview titles and gives users clearer context when sharing or pasting links.
Original PR description
Users without access for specific actions cannot see the right preview information, using sudo like the search for generic action but on specific model solve the issue. Steps: - Login with a user without window actions access - Copy a link somewhere to have preview dialog Actual result: - Preview title is Odoo due to access error Expected result: - Preview title is the one of the page opw-4933194 Forward-Port-Of: odoo/odoo#222435
The New User Invite email template now generates website and email links correctly. This prevents recipients from receiving malformed links, making onboarding invitations work as expected.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
This fix prevents an IoT device from immediately losing its server configuration after being paired again in a specific recovery scenario. It helps avoid failed setup loops and reduces manual reconfiguration for users managing IoT boxes.
Original PR description
Steps to reproduce: 1. Pair your IoT 2. From the IoT homepage, clear the server configuration 3. From the DB, delete the IoT box record 4. Pair your IoT again EXPECTED BEHAVIOUR: - IoT pairs succesfully ACTUAL BEHAVIOUR: - IoT pairs but then immediately clears the server configuration This commit introduces a simply sanity check to workaround the issue, by simply ignoring a `server_clear` message if it was received less than 5 seconds after connecting to the websocket. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230244
Closing the barcode scanning dialog before the camera preview finishes loading no longer causes an error. This improves reliability for users who navigate back or press Escape while opening the scanner.
Original PR description
Steps to reproduce: 1. Install `barcode` 2. Barcode > 'click to scan' 3. Before the camera preview loads, click the back button of the dialog Issue: A traceback occurs: `OwlError: The following error occurred in onMounted: 'Cannot set properties of null (setting 'srcObject')' ` Cause: Clicking the back button triggers `onWillUnmount`, which clears the stream and sets `this.videoPreviewRef.el` to null. However, some asynchronous functions in `onMounted` are still pending and try to access the video element, leading to a crash. Solution: Add a safe check based on component status before accessing `this.videoPreviewRef.el` opw-5055566 Forward-Port-Of: odoo/odoo#229937 Forward-Port-Of: odoo/odoo#226068
Credit notes created after a sales order down payment now correctly reverse the cost of goods sold. This keeps inventory and expense accounting accurate when customers are refunded after partial upfront payment.
Original PR description
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on…
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on ordered quantity - set the category of the product as avco and "inventory valuation" of the category as automated - set an onhand quantity and a positive cost - create a SO for 1 quantity of this product and confirm - click on create invoice, select downpayment percentage and 25% - click on create draft and confirm it - click on create invoice, select regular, create draft - confirm and select credit note - write something in the reason field and click on reserve - confirm it **Current behavior:** if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once) **Expected behavior:** There should be: - A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product. - A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product. **Cause of the issue:** Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131 Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164 As a consequence, - qty_to_invoice will become - qty_to_invoice - account_move will be populated - therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915 **fix** The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one : - SO for qty of 10 (product invoiced on delivered qty). - 100% downpayment. - deliver 6. - invoice. In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id. opw-5041783 Forward-Port-Of: odoo/odoo#229774 Forward-Port-Of: odoo/odoo#226809
This fixes ISO 20022 payment files for Danish banks by allowing the required local clearing instruction to be added when configured. Businesses using Danish bank payments can avoid rejected payment files by setting the appropriate clearing option, while behavior stays unchanged if no option is set.
Original PR description
The denmark banks were refusing ISO20022 documents because there was a missing field: "//PmtInf/PmtTpInf/LclInstrm/Cd" or "//PmtInf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd". One of those field should be filled by either 'ONCL' or 'SDCL' which means 'Over Night Clearing' or 'Same Day Clearing'. To fix this we added a config parameter with a key: account_iso20022.local_instrument_code where we can set OCNL or SDCL to add the required field to the iso document. If nothing is set, the field will not be added. opw-5073076 Forward-Port-Of: odoo/enterprise#96190 Forward-Port-Of: odoo/enterprise#95903
The German Datev export no longer fails when sale or purchase receipts are created without a customer or vendor. This helps businesses export accounting data reliably even when receipts do not require partner details.
Original PR description
Since 18.4, there are purchase receipts as a function for vendor bills, where you can choose to put no vendor in the vendor field, the same is true for invoices with sale receipts. Making sure that partners are not Null task-5114562 Forward-Port-Of: odoo/enterprise#95649
The sales dashboard spreadsheet now applies the selected medium filter to list sections as expected. This keeps dashboard list data consistent with the rest of the filtered sales report, improving reliability for users reviewing sales performance.
Original PR description
Before this commit, the medium global filter was not applied to the lists in the sales dashboard spreadsheet. Task: 5129301 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 update brings the spreadsheet engine up to its latest version with fixes for chart animations, dashboard chart menus, formatting conversion, sheet renaming, mobile formula access, headers, and pivot measures. Users should see smoother spreadsheet dashboards and fewer small interruptions when editing or presenting spreadsheet content.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/86fc4428f8 [REL] 19.0.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/86fc4428f8 [REL] 19.0.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/47bb54fc70 [FIX] chart: zoomable chart should be animated [Task: 5079057](https://www.odoo.com/odoo/2328/tasks/5079057) https://github.com/odoo/o-spreadsheet/commit/301b2ca0ec [IMP] carousel: allow full screen toggle in carousel [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831) https://github.com/odoo/o-spreadsheet/commit/975b3487fe [MOV] figures: rename `fullScreenChart` to `fullScreenFigure` [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831) https://github.com/odoo/o-spreadsheet/commit/0cea053f34 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306) https://github.com/odoo/o-spreadsheet/commit/a2df5684dd [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129) https://github.com/odoo/o-spreadsheet/commit/0c0386b3ec [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030) https://github.com/odoo/o-spreadsheet/commit/297ca4a894 [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626) https://github.com/odoo/o-spreadsheet/commit/030841ec5e [FIX] composer: show FX icon in inactive mobile composer [Task: 5092659](https://www.odoo.com/odoo/2328/tasks/5092659) https://github.com/odoo/o-spreadsheet/commit/23f44838cb [FIX] chart: fix button hover background in dashboard menu [Task: 5082189](https://www.odoo.com/odoo/2328/tasks/5082189) https://github.com/odoo/o-spreadsheet/commit/242c9a7966 [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Live chat visitors can no longer start calls or invite guests from chat threads. This prevents unsupported visitor actions and keeps live chat interactions aligned with intended permissions.
Original PR description
This commit removes the possibility for live chat visitors to start a call and invite guests. task-4849019 Forward-Port-Of: odoo/odoo#229924 Forward-Port-Of: odoo/odoo#228531
This fix prevents Chilean electronic invoice XMLs received by email from failing when they contain accented characters such as Ó. Businesses can process these vendor documents more reliably without manual intervention caused by import errors.
Original PR description
### Issue:
The invoice XMLs having special characters like "Ó" received in DTE emails will trigger a traceback.
### Cause:
`.decode('utf-8')` will try decoding the bytes in utf-8 but Ó is not UTF-8, so there is a traceback:
```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 1734: invalid continuation byte
```
In any case, it crashes at the next line: `xml_content = etree.fromstring(xml_dte)` because the XML specifies the encoding (i.e. unicode) but the true encoding is `utf-8` so an error is raised:
```
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
```
### Solution:
Remove `.decode('utf-8')` when decoding. The method `fromstring` accepts bytes and will use the encoding specified in the XML.
opw-5124661
Forward-Port-Of: odoo/enterprise#96410This fixes an inventory valuation issue where FIFO product costs could be updated from the manually set cost instead of the actual valuation average. After revaluation, product cost now stays aligned with inventory value, improving accuracy for stock accounting and reporting.
Original PR description
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on…
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on the on hand smart button and update the quantity to 2 - the value should be 500, which makes a 250 value per product - open Inventory/valuation and search your product - group by product, select your product and click on "+" icon to open the revaluation widget - add 200 (so +100 per unit) - go back to the product form **Current behavior:** the cost is now at 400 **Expected behavior:** the cost should be at 350 (250 + 100) If we change the standard_price we should change it in accordance with the valuation **Cause of the issue:** In action_validate_revaluation, during the update of the standard_price, the current standard_price (set by the user and disconnected from the valuation) is used in the computation. https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127 opw-5028848 Forward-Port-Of: odoo/odoo#229977 Forward-Port-Of: odoo/odoo#228457
The Point of Sale automated test tour now waits longer for the system to load when many localizations are installed. This reduces false test failures in slower setups and helps keep release validation stable.
Original PR description
Loading the PoS with all the localizations installed can take up to 15s to load, so we increase the timeout of the first step of the generic tour to 20s to make sure it doesn't fail. runbot-233059 Forward-Port-Of: odoo/odoo#229925
Fixes an issue where automatic replenishment could create purchase orders with slightly inflated quantities when product packaging used different unit multiples. This helps businesses avoid unnecessary over-ordering and keeps inventory purchases aligned with actual demand.
Original PR description
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as…
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as "units" - create a new storable product - next to "sale price" change the unit to "pack of 6" - in the sales tab add "pack of 2" in the packagings - in the purchase tab add a vendor - click on the reordering rule smart button and create a new one - set the min and max to 0 and set the replenishment multiple to "pack of 2" (you might have to make this column visible using the filters) - create and confirm a quotation for 1 pack of 6 **Current behavior:** a new Purchase Order is created for a quantity of 1.02 **Expected behavior:** it should be a quantity of 1 **Cause of the issue:** qty_multiple is rounded (in _compute_quantity) before the computation of remainder. https://github.com/odoo/odoo/blob/7a0a246016d50ae80e49f3502a97e82d414ab0b0/addons/stock/models/stock_orderpoint.py#L373-L376 In cases of repeating decimal numbers (like 0.3333333 in our example), this leads to the remainder not being 0 even though it should be 0. opw-5040144 Forward-Port-Of: odoo/odoo#230013 Forward-Port-Of: odoo/odoo#228014
Fixes minor visual issues when editing spreadsheet date filters on mobile. Active selections now show the check mark correctly, and navigation arrows remain visible and usable in the bottom sheet.
Original PR description
In mobile, the dropdown to edit a date filter value is now displayed in a bottom sheet. There was some minor issues in the styling: - the check icon for active item wasinside another icon - the arrow next/previous were grayed out since ":hover" doesn't really exist on mobile Task: [5092756](https://www.odoo.com/odoo/2328/tasks/5092756) 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
Appointment bookings with multiple staff members now calculate manual confirmation thresholds using the combined capacity of all assigned users. This prevents bookings from being unnecessarily marked as requests when enough total capacity is still available, and adds test coverage for this behavior.
Original PR description
While the fix has been already implemented in 19.0 in [1], this commit forwards-port the test of the original commit, as it differs from the one included (modified) in [1] and treats the case of…
While the fix has been already implemented in 19.0 in [1], this commit forwards-port the test of the original commit, as it differs from the one included (modified) in [1] and treats the case of managing capacity, and some other use cases not covered by the test in [1]. A small error is also corrected in a separate commit, as the appointment used to get the phone question was wrong in a test related to the original issue. ORIGINAL ISSUE ============== Introduced in https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73, We now handle capacity when booking users. They have each a max capacity of user_capacity for each slot. However, when it comes to the manual confirmation treshold, we do not account for the total capacity of all users combined, but consider the maximum to be user_capacity! This can lead to a lot of 'request' meetings as we reach the manual confirmation percentage very quickly. STEPS TO REPRODUCE ================== 1. Create an appointment type based on users, with 'manage capacities' enabled, 'manual confirmation' enabled and 'when over' 50% total capacity. Set 2 users and 3 'seats max'. This way, the total capacity of your appointment is 2 * 3 = 6 per slot. 2. As a public user, take an appointment for 2 capacity in the front end 3. The meeting will end up as a 'request', even though the capacity booked is 2/6 < 50%, and should be 'booked' FIX === We now multiply the number of users on the appointment type by the user_capacity when computing the total capacity and comparing it to the asked capacity on booking an appointment. 1 : https://github.com/odoo/enterprise/commit/b19e26b0333180ba7a487e14e06385693cf7ab16 Task-4930778 Forward-Port-Of: odoo/enterprise#89876
UPS shipping rate checks during ecommerce express checkout no longer fail when shoppers have only provided the limited address details required at that stage. This helps customers continue checkout smoothly before entering full street and phone information later.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
Adyen redirect payments now skip amount and currency checks that do not apply to that payment flow. This prevents valid redirect transactions from being blocked unnecessarily, helping checkout completion stay smooth.
Original PR description
Amount and currency validation is skipped for redirect transactions.
Fixes an error that could stop users from validating payments in Point of Sale when using Kenya OSCU electronic invoicing. This ensures sales can be completed normally for Kenyan companies without the checkout process failing.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ke_edi_oscu_pos`. 2. Set company to a Kenya (KE) company. 3. Open POS → Clothes shop → add a product → go to Payment → try to Validate → traceback occurs.…
**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment
→ try to Validate → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'services')
at OrderPaymentValidation.beforePostPushOrderResolve`
**Cause:**
- ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.
https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24
**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
`this.orm.call` to correctly access the environment and execute data calls
during payment validation.
> Reference:
https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10
[Related Community PR](https://github.com/odoo/odoo/pull/230069)
**opw - 5137557**Opening the Quality Points button from a product in Point of Sale no longer causes an error. The system now opens the correct quality control view, preventing disruption for users reviewing product quality rules.
Original PR description
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue**…
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue** `UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: ""quality.point"."product_variant_count" field is undefined."` **Root Cause** https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/point_of_sale/views/product_view.xml#L23-L25 - View reference is passed in the context. - When this context is propagated to `action_see_quality_control_point`, https://github.com/odoo/enterprise/blob/7b777bffbebfb6503bb348005e9ce076825926e4/quality_control/models/quality.py#L579-L584 https://github.com/odoo/enterprise/blob/2e08282ca275bf1e66c58e28391f11f8bd7884d2/quality_control/views/quality_views.xml#L859-L868 - Than traceback occurs because the action does not pass a `view_id`. - When the context contains `list_view_ref`, it attempts to load the product template list view with the `quality.point` model. - This leads to a traceback since the fields defined in that view do not exist on the `quality.point` model. **Solution** - Pass a proper `view_id` from the Python side to ensure the correct view is loaded, preventing `list_view_ref` from forcing to load an invalid template. **opw-** **5090505** Forward-Port-Of: odoo/enterprise#95040
This update fixes an internal website test that was failing when video snippets opened an unexpected media dialog. The test now skips video snippets in the same way it already skips image snippets, helping keep automated checks reliable without changing customer-facing behavior.
Original PR description
Since PR odoo/odoo#214984, the “test_03_snippets_all_drag_and_drop” test fails because the video snippet opens the media dialog and the test does not handle it. Solution: as with image snippets, we will ignore them in this test. Error: https://runbot.odoo.com/odoo/runbot.build.error/231594 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
Point of Sale now handles unusually large payment amounts without crashing during order validation. The fix also ensures the confirmation prompt closes correctly after approval, helping cashiers complete sales smoothly.
Original PR description
**Steps to reproduce:** 1. Install the POS module. 2. Open POS and add a product. 3. Proceed to the payment page. 4. Make a payment greater than (total cost of order * 1000). 5. Try to validate the…
**Steps to reproduce:**
1. Install the POS module.
2. Open POS and add a product.
3. Proceed to the payment page.
4. Make a payment greater than (total cost of order * 1000).
5. Try to validate the payment → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'utils')
at OrderPaymentValidation.isOrderValid `
**Cause:**
- ` this.env` is not directly accessible in `OrderPaymentValidation`.
> Reference:
https://github.com/odoo/odoo/blob/33c789eeed3b307e40c0f7ab2c6bc07c33867498/addons/pos_online_payment/static/src/app/utils/order_payment_validation.js#L25-L28
**Solution:**.
- Use `this.pos.env` instead of `this.env` to correctly access the environment
during payment validation,
> NOTE
- After fixing the traceback, the 'Large Payment Amount' confirmation dialog
appears correctly. However, when clicking 'OK', the dialog was not closing
because the callback function `validateOrder` returned `False` even for valid
orders. This caused the dialog to reopen in an infinite loop.
https://github.com/odoo/odoo/blob/d309b52e5b19727b3e91ed91afd44e392a3b851a/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L71-L91
- Add return `True` in `validateOrder`, because even when the order was valid,
it returned `False`, causing the `ConfirmationDialog` to reopen repeatedly
when clicking "OK". Returning `True` ensures the dialog closes properly after
successful validation.
> Reference:
https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/point_of_sale/static/src/app/utils/order_payment_validation.js#L108-L138
[Related Enterprise PR](https://github.com/odoo/enterprise/pull/96284)
opw-5137557The website builder now clearly disables the remove button when a carousel has only one slide left. This prevents users from seeing an action that appears available but cannot actually remove the final required slide.
Original PR description
Steps to reproduce: - Drop a carousel snippet - In the builder options, click on the "-" button to remove all items except the last one. => The button is still displayed as working (not disabled), even though clicking on it won't remove the last slide. To clarify that this is the expected behavior, we disable the button if there is only one carousel item left. Forward-Port-Of: odoo/odoo#226877
This fixes Indian HR leave calculations so sandwich leave counts all applicable non-working days around a leave period, not just the nearest day. It also ensures half-day leave is recorded as 0.5 days instead of a full day, improving payroll and absence accuracy.
Original PR description
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off >…
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off > configuration > 'Time off Types', - Create a Time off type with - 'Sandwich leave' ticked and `Take Time Off in` to half a day - Go to Time off > Management > Time off - Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 - Case 2: Create a paid time off with any date and mark it as a half-day **Observation:** - Case 1: You will see Duration 3 days with the sandwich leave policy. - Case 2: Half-day leave shows 1 day instead of 0.5 **Root Cause:** - Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46 - Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19 **Solution:** - Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found. - Case 2: Fixed duration calculation to add 0.5 for half-day leaves. opw-5025766 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226883
This update prevents a crash when website interaction code waits on an action that intentionally returns no value. It makes the web interface more reliable for developers building interactive pages, with no expected change for everyday users except fewer errors.
Original PR description
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 Forward-Port-Of: odoo/odoo#229029
3 changes
Resolved issues and error corrections
UPS shipping rates can now be checked during express checkout using only the limited delivery details available at that step. This prevents shoppers from being blocked unnecessarily when street address or phone number information has not yet been collected.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
New User Invite emails now generate website and email links correctly. This prevents recipients from receiving malformed links, making account setup smoother and reducing support friction.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
Shop floor users without HR app access can now see and add employees as operators in the shop floor app. This keeps production workflows moving without requiring broader HR permissions.
Original PR description
**PROBLEM** If a user doesn't have access to the hr.employee, they can't add any operators to the shop floor app, even if they are a shop floor user. **STEP TO REPRODUCE** 1. On a fresh db, install the mrp module. 2. Restrict Marc Demo's access to the hr app. 3. Switch to Marc Demo, and go to the shop floor app. 4. Click the + Add Operator button, and notice the pop up view doesn't show employee. **FIX** Switch the model shown by the view to hr.employee.public. opw-4887229
4 changes
Resolved issues and error corrections
New user invitation emails now generate website and email links correctly. This prevents recipients from receiving malformed links and helps invited users access Odoo without confusion.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
This fixes a rounding issue that could make fully prepaid Saudi invoices show a negative zero amount, causing the invoice data and QR code to disagree. Businesses using Saudi e-invoicing can now submit these affected invoices to ZATCA successfully instead of receiving a rejection.
Original PR description
Issue: Doing down payment up to 100% can create a -0.00 PayableAmount that won't match the QR Code value, as it's set to absolute. Step to reproduce: 1 Install l10n_sa_edi 2 Navigate to Accounting >…
Issue: Doing down payment up to 100% can create a -0.00 PayableAmount that won't match the QR Code value, as it's set to absolute. Step to reproduce: 1 Install l10n_sa_edi 2 Navigate to Accounting > Configuration > Taxes. 3 Select the 15% tax and copy it. 4 In the Advanced Configuration tab, select the "Included in Price" option. 5 Navigate to Sales. 6 Select NEW 7 Add ARAMCO (default customer in l10n_sa) as a customer 8 Click into ARAMCO and change contact type to an Individual. 9 Navigate back to Sale Order. 10 Add the following products: - a Booking Fees. 1 quantity. Unit price 225.4 15% tax (price included) - b Burger Menu Combo. 1 quantity. Unit price 180 15% tax (price included) - c Booking Fees. 1 quantity. Unit price 300 15% tax (price included) - d Burger Menu Combo. 1 quantity. Unit price -101.43 15% tax (price included) 11 Select Confirm. 12 Select Create Invoice, then Down payment of 100%. 13 Confirm the invoice. 14 Navigate back to Sale order. 15 Select Create Invoice, then Regular Invoice. 16 Confirm the invoice. 17 Select "Process now" in the blue banner. 18 Receive error. Current behavior: - Message: "Invoice was rejected by ZATCA" - ZATCA return an error 400 and states the QR Code is invalid as the BT-115 in the invoice (XML) and QRCode doesn't match Expected behavior: - Message: "Invoice Successfully Submitted to ZATCA" Cause of the issue: - Some issues with floating point operations create a difference in value between a 100% down payment and the value of the invoice it covers. This results in a -1e-13 `payable_amount` that ends up being a -0.00 PayableAmount after going through `float_rounding`. Solution: - By rounding the `payable_amount` as per currency limit, the `payable_amount` fall back to -0.00. Then it goes through `float_rounding` which return 0.00. opw-5059795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes incorrect tax mappings in the Maltese localization for EU and non-EU partner fiscal positions. Businesses using Maltese accounting will now have sales and purchase taxes mapped to the correct tax type and rate, reducing the risk of wrong tax treatment on transactions.
Original PR description
### Steps to reproduce: - Install "l10n_mt" and switch to a Maltese company - Check the fiscal position "EU Partner", it maps Sales taxes to Purchase ones - "Partner outside the EU" maps Purchase taxes to Sales ones ### Solution: Fix the CSV. We map the taxes respecting Sales/Purchase and with the same percentage. opw-5065298
This fix sends the extra payment details required by some Adyen payment methods, such as customer country and order line information. It helps transactions using services like Klarna complete successfully instead of being blocked by missing required data.
Original PR description
Some payment methods eg. Klarna require 'country code' and 'line items' in order to process the transaction. opw-5077617