Tuesday, November 18, 2025
35 changes · saas-18.4
Resolved issues and error corrections
This change makes the web client more resilient when a browser no longer exposes the platform information it used to provide. By checking for the feature instead of assuming it is always present, Odoo avoids unnecessary errors and improves compatibility with modern browsers.
Original PR description
This commit uses "Feature detection" to avoid some error when the platform key is not available from navigator. > The platform property indicates the platform/OS the browser is running on. > Theoretically this information is useful for detecting the browser and serving code to work around browser-specific bugs or lack of feature support. However, this is unreliable and is not recommended for the reasons given in User-Agent reduction and Browser detection using the user agent. > Feature detection is a much more reliable strategy. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/platform https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Testing/Feature_detection task-4420689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235958
This fix corrects where the QRIS payment fields are placed on the bank account form so they appear consistently. As a result, users in Indonesia can now see and complete the QRIS API key and MID fields when needed.
Original PR description
**Description of the issue/feature this PR addresses:** This issue occurs because the XPath targeting the `currency_id` field is placed inside a `<div>` that becomes invisible under certain conditions. The `view_partner_bank_form_inherit_hr` view is loaded first due to its sequence, and the `l10n_id` view is applied afterward, causing the QRIS fields to be inserted into that hidden `<div>` from `view_partner_bank_form_inherit_hr`. **Current behavior before PR:** The fields l10n_id_qris_api_key and l10n_id_qris_mid are not visible. **Desired behavior after PR is merged:** The fields l10n_id_qris_api_key and l10n_id_qris_mid are visible by changing XPath target Task: [5247678](https://www.odoo.com/odoo/project.task/5247678) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235949
This update prevents an error when shoppers switch between product variants on subscription-enabled products in the online store. If pricing data is missing, the system now handles it safely instead of triggering a page traceback, improving storefront reliability.
Original PR description
Step to reproduce: - install website_sale_subscription - create a product, add few variants and tick 'Subscriptions' option. - open that product from /shop - toggle between variants Cause: - In case the pricing is not present, 'False' is passed(not an iterable) - `_onChangeCombinationSubscription` expects a iterable, causing traceback Fix: - we pass empty list instead of False opw-5241612 Forward-Port-Of: odoo/enterprise#99160
This update prevents Belgian tax report generation from failing during migration when a company’s fiscal year ends on February 29. It now calculates the start date correctly for any year, so reports continue to generate without errors, including in leap-year-related setups.
Original PR description
``` File "/tmp/tmpm_3a__2e/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 340, in migrate generate_or_refresh_all_returns(company) File…
```
File "/tmp/tmpm_3a__2e/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 340, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 228, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 24, in _generate_all_returns
super()._generate_all_returns(country_code, main_company, tax_unit=tax_unit)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 281, in _generate_all_returns
report_type._try_create_returns_for_fiscal_year(main_company, tax_unit=tax_unit)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 353, in _try_create_returns_for_fiscal_year
period_date_from, period_date_to = self._get_period_boundaries(main_company, date_pointer)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 530, in _get_period_boundaries
start_day, start_month = self._get_start_date_elements(company_id)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_return.py", line 16, in _get_start_date_elements
fiscal_year_date = date(2025, int(main_company.fiscalyear_last_month), main_company.fiscalyear_last_day)
ValueError: day is out of range for month
```
```
(Pdb) main_company
res.company(3,)
(Pdb) main_company.fiscalyear_last_month
'2'
(Pdb) main_company.fiscalyear_last_day
29
(Pdb) date_from
datetime.date(2025, 3, 1)
```
- During the migration process the system calls [_generate_or_refresh_all_returns](https://github.com/odoo/upgrade/blob/e20a9e2edec4441b2c7aa5858db2a53fb2e9b215/migrations/account_reports/saas~18.3.1.0/end-account-returns.py#L340) which internally uses [_get_start_date_elements](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L14) to compute the fiscal year start date.
- The customer has configured fiscalyear_last_month = February and fiscalyear_last_day = 29 Because of this configuration, the method attempts to construct 29th February 2025, which is invalid since 2025 is not a leap year. The issue occurs because the method uses a hardcoded year [(2025)](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_be_reports/models/account_return.py#L16) instead of determining the year dynamically.
- I reviewed implementations in other localizations and found that this logic has [1](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_uk_reports/models/account_return.py#L33), [2](https://github.com/odoo/enterprise/blob/ebdc2fe2ade72b1505dac5490b7df2a1d06fcb4b/l10n_nz_reports/models/account_return.py#L8) already been corrected there to compute the appropriate start date dynamically.
- I’ve updated this localization to follow the improved implementation used in other countries, so the start-date calculation now works correctly in all cases, including leap years and any fiscal year settings the customer may configure.
opw-5249243
Forward-Port-Of: odoo/enterprise#99353This change prevents an error when portal users open a shared project task and try to use the message box before the task is saved. It keeps the chatter inactive until the task has been created, avoiding a broken experience for collaborators.
Original PR description
Currently, an error occurs when a portal user opens a `shared project` and tries to `mention(@)` someone in the chatter of a `new(unsaved) task`. **Steps to produce:** - Install the `project` module.…
Currently, an error occurs when a portal user opens a `shared project` and tries to `mention(@)` someone in the chatter of a `new(unsaved) task`. **Steps to produce:** - Install the `project` module. - Open the project app and create a new project with at least one task. - From the project’s `dropdown menu(⋮)`, select `Share Project`. - Add a `collaborator: Joel Willis`, with `Edit access` mode, copy the public link, and click `Share Project`. - Open the shared link in an incognito window and sign in as a portal user. - Open the `project folder` > open any task > click `New` > type `'@'` in the chatter. **Error**: `ValueError: Expected singleton: project.task()` **Root cause:** The `composer(message box)` allows typing and mention suggestions even when the task record is not yet saved (`self.thread.id` is `undefined`). At [1], the method is called on an `empty` recordset, causing an `error`. **Fix:** This commit prevents users from writing in the chatter by stopping the composer initialization when the record(thread) is `unsaved`. [1]: https://github.com/odoo/odoo/blob/5cf96828652c2388808b3e49ae67e188c401ec63/addons/project/models/project_task.py#L2051-L2071 sentry-6982269693 Forward-Port-Of: odoo/odoo#235184
The employee org chart button now opens the Hierarchy view on mobile devices instead of the Kanban view. This makes the org chart work as expected on smaller screens and helps users quickly see reporting lines.
Original PR description
Steps to Reproduce: - Open an employee record. - Set managers for the employee. - Open the employee’s form view on mobile. - Click org chart stat button. Before: - On mobile, the org chart button opened the Kanban view by default. After: - On mobile, the org chart button now opens the Hierarchy view by default. task-5245129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235228
This change prevents long product attribute values from spilling outside the product card in the catalog view. It keeps the layout tidy and consistent, so users can browse and select products without the screen becoming misaligned or harder to use.
Original PR description
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. Issue: - The product image and attribute value text overflow outside the product card in the kanban view, causing layout misalignment and breaking the UI design. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/afc592bb-e25a-4d81-882b-0e7cc7ad1064" /> Cause: - The inner div containing the attribute text lacked overflow control, allowing long text to exceed the container width and pushing other elements. Solution: - Added the Bootstrap class `overflow-hidden` to the div element to ensure the image and text remain properly contained within the card layout. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/580ce1e5-42bd-4c2d-b6bf-14315759626d" /> opw-5222002 Forward-Port-Of: odoo/odoo#235680 Forward-Port-Of: odoo/odoo#235214
This update fixes an issue on mobile websites where a hidden mega menu could still block taps on the page. As a result, customers can reopen the menu normally after closing it, improving the browsing experience on mobile devices.
Original PR description
Steps to reproduce: ==================== 1. Add a mega menu. 2. Add effects to the mega menu columns ex (Animation on appearance, Fade, direction from bottom) 3. Switch the website display to mobile view. 4. Click on the mega menu. 5. Go back and try to click again. → The mega menu cannot be opened again. Cause: ====== When the mega menu is hidden, its section remains in the DOM and still captures pointer events. As a result, clicks on the screen (including attempts to reopen the mega menu) are intercepted by the hidden element instead of reaching the intended target. Solution: ========= Disable pointer events on the mega menu section once it is hidden to ensure subsequent clicks behave correctly. opw-5129316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233636
This change removes an overly strict rule that prevented some tax groups from being copied or edited if their linked payable or receivable accounts had a different type. It makes the system more flexible while still allowing users to adjust account types afterward if needed.
Original PR description
**Issue:** A constraint has been added to "account.tax.group" model some month ago, forcing a type for "Tax Payable Account" and "Tax Receivable Account" fields. However, some users had changed the type of these accounts or selected another one and they cannot do it anymore. They can't copy these tax groups neither. The constraint is too restrictive as we want to be more permissive. It's still possible to change the type of the account after selecting it for the tax group. Therefore, the constraint has some flaws. **Solution:** Remove the constraint. **Community PR:** https://github.com/odoo/odoo/pull/235548 opw-5231379 Forward-Port-Of: odoo/enterprise#99421
This update removes an overly strict rule on tax group accounts, so users can again reuse, change, or copy tax groups even if the linked accounts were adjusted before. It makes the system more flexible while still allowing account types to be changed after selection when needed.
Original PR description
**Issue:** A constraint has been added to "account.tax.group" model some month ago, forcing a type for "Tax Payable Account" and "Tax Receivable Account" fields. However, some users had changed the type of these accounts or selected another one and they cannot do it anymore. They can't copy these tax groups neither. The constraint is too restrictive as we want to be more permissive. It's still possible to change the type of the account after selecting it for the tax group. Therefore, the constraint has some flaws. **Solution:** Remove the constraint. **Enterprise PR:** https://github.com/odoo/enterprise/pull/99421 opw-5231379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235548
The salary configurator no longer rewrites the contract template when creating a new version. This prevents missing recalculations and helps ensure contract-related values update correctly.
Original PR description
Writing the contract template on the new version created by the salary configurator is not necessary and caused some computes to not trigger.
This update fixes several Viva Wallet payment issues in Point of Sale, including incorrect payment matching when multiple terminals are used at once, payments affecting the wrong order, and payments getting stuck after a page refresh. It makes confirmations more reliable so customers and staff see the correct payment status.
Original PR description
This commit fixes various issues when using Viva Wallet, including the following: - When two Viva Wallet terminals had a payment in process at the same time in the same POS, one of the payments would…
This commit fixes various issues when using Viva Wallet, including the following: - When two Viva Wallet terminals had a payment in process at the same time in the same POS, one of the payments would fail on Odoo even when it succeeded on the terminal. - When a previous Viva Wallet payment was stuck (never completed or failed), trying to make a new payment would mistakenly affect that previous order instead of the new order. - When refreshing the page during a payment, it becomes stuck and never confirms or fails. To fix these issues, there are two main changes: 1. Stop using the `getPendingPaymentLine` method to retrieve the Viva Wallet payment line. This method is flawed as it assumes there is only one pending payment at a time. 2. Store the Viva session ID for a payment in the payment line's UI state, instead of on the plain JS object. This allows it to persist after a refresh. opw-5226966 opw-5248178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236004 Forward-Port-Of: odoo/odoo#235695
This update prevents an error that could appear when opening a stock quantity record without a location selected. It makes the Inventory screen more reliable by handling incomplete records safely instead of crashing.
Original PR description
Currently, an error is produced when accessing the stock quant form view without a location set. **Steps to Reproduce:** 1. Install the Inventory module. 2. Create a product with tracking enabled (By Unique Serial Number). 3. Click **"Update Quantity"** (opens list view). 4. Click **New**, click View on the unsaved record (opens form view). 5. Remove the Location field. **Error:** `TypeError - sequence item 0: expected str instance, bool found` **Cause:** In the display name computation at [1], the system attempts to join name parts where one of them can be `False` if the location is not set. **Fix:** Before generating the display name, it now checks whether the record is saved (record.ids). If the record is unsaved (no ID), it sets an empty `display_name` and skips the name-joining logic. [1] - https://github.com/odoo/odoo/blob/16e889bf5885c4d827b8c2c5dce102f98aad689f/addons/stock/models/stock_quant.py#L599 sentry-6717759358 Forward-Port-Of: odoo/odoo#234552
The POS floor plan will now only show booking notifications for the appointment type configured in that POS setup. This prevents incorrect bookings from appearing briefly and disappearing after refresh, making table management more reliable for staff.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v17.0: [#93714](https://github.com/odoo/enterprise/pull/93714) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset. Forward-Port-Of: odoo/enterprise#98887 Forward-Port-Of: odoo/enterprise#93636
This update prevents hidden line breaks from being included in Swiss QR code fields. That helps ensure the QR code is formatted correctly and accepted by banks or payment systems.
Original PR description
Swiss QR codes have required information for each line of the QR code. Newline characters present in a field's content shift the content to a different line than intended, causing the QR code to be rejected. This commit removes newline characters from the field elements and alters a unit test to check if this issue occurs again. opw-5095997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233880
This update fixes the Reviews smart button on employee profiles so it now shows the relevant contract review records instead of an empty page. It restores the expected behavior for both active and inactive records, making it easier to review employee contract history.
Original PR description
Issue:
When an offer is created and signed by the employee, the `Reviews` smart button appears on the employee profile. Although it indicates that there are records, clicking the button redirects to an empty list.
Reason:
After converting contracts to the versioning system, the action for the Reviews button does not properly display contract versions, regardless of whether they are active or inactive, as it did in the previous version.
Fix:
Added a context `{"active_test": False}` to show active or inactive records.
task-5155455This change fixes an issue where imported French accounting entries could stop being automatically reconciled in some accounts after a previous reconciliation. It helps ensure the matching process works consistently, so imported records are reconciled as expected and accounting data stays in sync.
Original PR description
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items. The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206 Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them. This commit provides a test to reproduce this issue. opw-5086823 Forward-Port-Of: odoo/enterprise#98855
Odoo now matches Mollie’s actual account setup more closely by no longer enabling iDEAL as a default payment option for new Mollie accounts. It also removes Sofort from the linked payment methods because that payment method has been deprecated by Mollie, helping avoid confusion and unsupported options.
Original PR description
**[FIX] payment_mollie: remove iDEAL from the default payment methods** When a new Mollie account is created, it only accepts card payments out of the box. In Odoo, both the Cards and iDEAL payment methods were activated by default upon enabling the payment provider, while iDEAL required manual activation from Mollie's dashboard. --- **[FIX] payment_mollie: remove Sofort from the linked payment methods** See https://help.mollie.com/hc/en-us/articles/20904206772626-SOFORT-Deprecation-30-September-2024ard. Forward-Port-Of: odoo/odoo#236044
This change prevents imported accounting entries from losing their import-related matching markers too early. As a result, automatic reconciliation now works correctly for all relevant entries, even when similar imported items exist on different accounts.
Original PR description
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the…
When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items. The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206 Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them. This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider. opw-5086823 Forward-Port-Of: odoo/odoo#234481
This change fixes an issue where Bancontact payments could be marked as failed when the customer needed to complete an extra verification step. With this update, those payments stay pending during the check, so the customer can finish the payment normally and avoid unnecessary errors.
Original PR description
When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.…
When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.
Example of recevied webhook:
```
{
'apiFullVersion': 'v1.1',
'apiVersion': 'v1',
...
'payment': {
'status': 'AUTHORIZATION_REQUESTED',
'statusOutput': {
'isAuthorized': False,
'isCancellable': False,
'isRefundable': False,
'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
'statusCode': 51
}
},
'type': 'payment.authorization_requested'
}
```
Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.
But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235847The VoIP app now avoids trying to reconnect when a page is being closed normally. This prevents a registration conflict that could cause errors during logout or when leaving the page, improving call service reliability.
Original PR description
On page unload, two conflicting things happen: - A REGISTER request with expires=0 is sent to invalidate the registration - The WebSocket disconnects, triggering the reconnection mechanism that attempts to reissue a registration These two concurrent and conflicting REGISTER requests result in the following error: > RequestPendingError: REGISTER request already in progress, waiting for final response This commit prevents the reconnection mechanism from occurring in the event of a "natural" disconnection, such as one triggered by a page unload. This way, the two conflicting REGISTER requests aren't sent on page unload. [Task-5261940](https://www.odoo.com/odoo/project/5778/tasks/5261940) Forward-Port-Of: odoo/enterprise#99560 Forward-Port-Of: odoo/enterprise#99376
This change fixes an intermittent issue in the manufacturing work order tour by making the “Add Component” flow more stable. It also ensures the intended product appears first, which helps the process run consistently during tests and for users following the same steps.
Original PR description
The search in the "Add Component" dialog caused a re-render race, making the tour ``test_add_component_from_shop_foor_in_multi_step_manufacturing`` fail intermittently. This fix removes the search steps and marks the “Courage” product as favorite so it appears first in the catalog. runbot-227694 Forward-Port-Of: odoo/enterprise#92403
This fix prevents quality checks from appearing for items that were not actually selected for delivery or receipt, including cases where a lot or serial number has not yet been assigned. As a result, users only see and complete the checks that apply to the goods that will really be processed, avoiding confusion and unnecessary work.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764
Forward-Port-Of: odoo/enterprise#99565Website editor now correctly saves style settings for every mega menu on a page, not just the first one. This ensures design changes like menu size are applied consistently across multiple mega menus after saving.
Original PR description
The implementation of `save_handlers` for mega menus only saved the classes of the first mega menu found. Thus, customization of the "Size" of the second menu was not saved. This commit change the handler to select all mega menus. Steps to reproduce: - Open website builder - Create multiple mega menus - Set "Size" to "Narrow" on each mega menu - Save - Bug: Only the first mega menu is narrow task-5248206 Fixes #234222
Products that are not available on the current website will no longer appear in the add-to-cart pop-up. This prevents shoppers from seeing optional products they cannot actually buy on that website, reducing confusion and improving the shopping experience.
Original PR description
Steps to reproduce: =================== 1- Create another website 2- Sales app > Products > Open any product's form 3- In the Optional Products field, select any other product in your database for this field 4- Open the product form of the optional product you selected 5- Set the Website field to only be one of your websites, rather than All 6- Navigate to the Website app > Select the non set website in the other Steps 7- Open your shop > Select your main product > Click the add to cart button -> See the optional product appear in the pop-up. Cause: ====== _should_show_product function doesn't validate if a product is available on the website from which the request originates when handling multiple websites. Solution: ========= Update the function to take multiple websites into consideration opw-5179894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233170
When changing the account on a vendor bill line, the linked non-deductible product line now updates to match it automatically. This keeps related accounting entries consistent and avoids mismatches that could affect invoice processing and follow-up work.
Original PR description
When you have a vendor bill with an invoice line linked to a journal item with the display type "non_deductible_product", if you modify the account_id of the invoice line, then the account_id of the…
When you have a vendor bill with an invoice line linked to a journal item with the display type "non_deductible_product", if you modify the account_id of the invoice line, then the account_id of the linked line should change to have the same value.
How to reproduce?
1. Create an asset model (Accounting > Configuration > Accounting > Asset Models)
2. Set the asset_model_id on an account (on the tab "Automation", set "Automate Asset" as "Create in draft" then set the "Asset Model" field with the created asset model
3. Duplicate the account having the created asset model
4. Create a vendor bill with an invoice line having:
- A strictly positive price unit
- A deductible_amount (Professional %) lower than 100 (this field is hidden by default)
5. Modify the account_id of the invoice line
6. Observe the journal items: the line with the non- deductible product should have the same account_id than the invoice line but it's not the case.
task-5156256
Forward-Port-Of: odoo/odoo#232121This update corrects how exchange rates are calculated in the Uruguay electronic invoicing flow. It now always uses the Uruguayan peso as the reference, which helps ensure consistent and accurate values regardless of the company’s main currency.
Original PR description
This PR fixes the currency rate calculation in the Uruguay EDI module to always compute the rate relative to UYU (Uruguayan Peso) regardless of the company's base currency. * Replaces the previous logic that calculated rates based on company currency with a direct UYU conversioni * Simplifies the rate calculation by removing the amount-based fallback logic * Ensures consistent UYU rate computation for all non-UYU currencies LATAM Task 1358 / Adhoc task 51716 Forward-Port-Of: odoo/enterprise#99374 Forward-Port-Of: odoo/enterprise#93144
This update makes Flutterwave payment references automatically unique by adding a timestamp to each one. It helps prevent payment requests from being rejected when the same reference could otherwise be reused, especially in test or reset environments.
Original PR description
The `/payments` endpoint of the Flutterwave v3.0.0 API expects unique `tx_ref` parameters (matching Odoo's payment transaction `reference` field) to be passed. This is guaranteed by a UNIQUE() SQL constraint in Odoo, but testing sometimes involves dropping the database, leading to transaction references being repeated at the provider level for a given merchant account. This commit singularizes all transaction references by suffixing them with the current timestamp, ensuring that the `tx_ref` API parameter remains unique across transaction reference sequences. Forward-Port-Of: odoo/odoo#235799
This change fixes an automated HR test that was failing because it did not set a contract start date before running date calculations. It ensures the test runs reliably on the targeted branch and helps prevent false failures in the validation pipeline.
Original PR description
The test_version_cron_update_no_fields from hr/tests/test_hr_employee.py didn't pass on runbot saas-18.4 due to the lack of explicitly defined start date of contract leading to an error when trying to substract False to a datetime object. I explicitly added a contract_date_start on the hr.version creation and modified the assigning line as the create_version function returns the new version object but doesn't attribute it to the employee directly. Runbot error: 233590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor batch payments will now use the correct numbering sequence when they are validated. This prevents supplier batches from being assigned the wrong name, which could cause confusion and make payment records harder to track.
Original PR description
Currently when creating a vendor batch payment, the system may incorrectly use the inbound batch payment sequence to generate the batch name Steps to reproduce: - Create a Vendor payment. - Create a Vendor batch payment, add the payment, validate it. Issue: Name has been set using the incoming batch payment sequence This occurs because `batch_type` is set to readonly when a payment is added to the list. As result, the current batch type is never sent to the backend that will use the default 'inbound'. opw-5128426 Forward-Port-Of: odoo/enterprise#99570
This update corrects the website builder test setup so it works consistently in Firefox. It prevents a test-only behavior from blocking builder tests, which helps keep automated testing reliable across browsers.
Original PR description
In the website builder test suite, Chrome doesn't load the initial iframe (we load a dummy iframe instead) and never goes through `preparePublicRootReady` from the `WebsiteBuilderClientAction`. On the contrary, Firefox does load the initial iframe. We already have a partial fix for it in the html_builder test helpers (see `originalIframeLoaded`), but it stopped working at some point. As Firefox loads the iframe and goes through `preparePublicRootReady`, it re-assigns `this.publicRootReady` to a deferred that is never resolved in tests, which prevents any Hoot builder test from working. Solution: completely override `preparePublicRootReady` with an empty method in tests. task-5266212
When viewing a module’s information page, tabbed sections in the index.html file are now clickable and behave as expected. This brings the module info experience in line with the behavior users already see in the Odoo app store, making it easier to review content in organized sections.
Original PR description
* Before: if we have a block contain multiple tab in index.html file we can not click on it to switch between tab, unlike the behiviour in odoo apps store description https://github.com/user-attachments/assets/ab7f8213-2112-46e2-bb72-5e01cc1f7883 * After: Make the nav tabs work as it should be https://github.com/user-attachments/assets/12c05abc-84f6-495e-ae5b-b6eca4d81a92 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#186568
Users can now export records even when the list is grouped by a property field. This fixes a crash that occurred during export and ensures grouped data can be downloaded normally.
Original PR description
Step to reproduce
- open a task
- add a property field , say test
- add values for this field in few records
- go to list view and group by test
- select a record from result and export it (from Action btn)
Observation:
- traceback
```
File "/home/odoo/17.0/addons/web/controllers/export.py", line 486, in base
groupby_type = [Model._fields[x.split(':')[0]].type for x in groupby]
~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: 'task_properties.b60ee9baefee14a8'
```
Cause:
- The issue is caused by splitting, which didn't considered property field
- it tried to look for `task_properties.b60ee9baefee14a8` in _fields which causes KeyError
FIx:
- split the field name properly to bring out actual field name while considering granularity as well as the property fields
opw-5159155
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235979
Forward-Port-Of: odoo/odoo#235209Customers using restaurant self-order takeout will now receive the order confirmation email as expected. This fixes an issue where the message was not sent for users who were not logged in, improving reliability of the ordering process.
Original PR description
When using the takeout preset with the self order, we're supposed to send a confirmation email to the customer. Currently, this mail does not get sent. Steps to reproduce: ------------------- * Open…
When using the takeout preset with the self order, we're supposed to send a confirmation email to the customer. Currently, this mail does not get sent. Steps to reproduce: ------------------- * Open the Restaurant config, make it only use the takeout preset (by default) and enable self ordering + QR * Log out * Open the mobile menu * Make an order * Fill out the information for takeout (slot, name, mail) and continue * Check the mails > Nothing being sent Cause: ------------ The email is supposed to be sent after entering the takeout informations and selecting the button "continue". https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L131-L135 The call to the db is made here: https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L156-L162 Which utlimately resolves in calling: https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/point_of_sale/static/src/app/services/data_service.js#L526 This uses the call_kw route which requires the user to be connected. https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/web/controllers/dataset.py#L28-L29 However the usecase we describe is mainly used by non connected users. If a user is not connected we will never call `action_send_self_order_receipt` which sends the email. Why the fix: ------------ We do not want to use a public route to send the email. What we want is to send the email directly from the backend when the order is created. In order to achieve this we need to send the email given by the customer when sending the order. To do that we need to override `serializeForORM` as the email is a computed field. Currently we cannot send the receipt by email as we cannot render it from the backend. This is currently a limitation but does not induce a stepback compared to using a public route as the route to send the email would usually be executed before the payment of the order, in which case we didn't sent a receipt. opw-5164546
This update adjusts Swiss payroll transmission tests so they can run without requiring accounting-specific setup on the payslip structure. It makes the test data more self-contained and reliable, which helps prevent unrelated accounting settings from causing payroll test failures.
Original PR description
Forward-Port-Of: odoo/enterprise#99264 Forward-Port-Of: odoo/enterprise#98672