Daily updates from Odoo
Tuesday, September 30, 2025
241 changes
13 changes
Resolved issues and error corrections
This change ensures an online shop pricing test has pricelists enabled before it runs. It prevents false test failures in databases without demo data, helping keep release validation reliable without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a database without demo data; 2. run `test_cart_new_pricelist_from_geoip`. Issue ----- Test fails, due to the order not having a pricelist. Cause ----- Pricelists aren't enabled by default without demo data. Solution -------- Call `self._enable_pricelists()` at the start of the test. runbot-232989 Forward-Port-Of: odoo/odoo#229224
This fix prevents sale orders linked to projects from becoming stuck when a related analytic account has been deleted. Users can update the project on affected sale orders without encountering a missing-record error, improving reliability in sales and project workflows.
Original PR description
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an…
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error. # Cause This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists. # Fix This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field. # Steps to reproduce - Install sale_project and accountant modules - Check "Analytic Accounting" in the Accounting settings - Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic") - Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order. - Delete the analytic.account "Test AC" - Go back on "Test SO", try to change the field "Project" - a Missing error is thrown --- Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore. Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224895
A sales and manufacturing test was corrected so kits can be invoiced before delivery when they are set to invoice based on ordered quantities. This helps keep automated checks aligned with the intended business flow and prevents build failures around kit invoicing validation.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796 Forward-Port-Of: odoo/odoo#227870
This fixes an issue where Discuss could fail when receiving an update for a call session that had already been removed. Users benefit from a more stable messaging and calling experience, especially when session events arrive out of order.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed. Forward-Port-Of: odoo/odoo#229166 Forward-Port-Of: odoo/odoo#229073
Spanish POS orders using TicketBAI now automatically retry the previously failed submission when a new order is paid. This helps prevent one failed tax report from creating a growing backlog of unreported sales, reducing manual follow-up for users.
Original PR description
Currently, the post failure of a single pos order can easily cause a backlog of more unposted orders since new orders will not be posted until the chain head is posted. Steps to reproduce ----- 1. Validate a pos order and have the TicketBAI post fail 2. Validate another pos order 3. The post for the second order is never attempted Cause ----- `_check_can_post()` ensures that new orders are not posted if the chain head was not posted successfully. During normal operation, it is common for many new orders to be paid before the user has a chance to manually retry the chain head post in the backend, causing a backlog of unposted orders. Solution ----- During `action_pos_order_paid()` retry the chain head post if is not sent. opw-4669823 Forward-Port-Of: odoo/odoo#228477
The POS now correctly shows that a self-order has already been sent for preparation when staff open it from the ticket screen. This avoids confusing staff with an unnecessary highlighted Order button and helps prevent duplicate preparation actions.
Original PR description
In the POS UI, the "Order" button was wrongly highlighted when loading a self-order, even though it had already been sent Steps to reproduce: - Create an order using self-order mobile (or kiosk). - Open the related POS terminal. - Load the self-order from the ticket screen. - Notice the "Order" button remains highlighted. Fix: - Ensure the last order changes updated when loading self-order in pos Task: 5005161 Forward-Port-Of: odoo/odoo#228682 Forward-Port-Of: odoo/odoo#223560
Creating a salesperson from a CRM opportunity no longer copies unrelated lead phone or mobile details into the new salesperson record. This prevents incorrect contact information from being saved and helps keep CRM and salesperson records accurate.
Original PR description
To reproduce: ============= 1- add a lead 2- add a phone and a mobile number 3- convert it to opportunity 4- create salesperson from that view 5- salesperson contains lead number Problem: ========= Before this fix, creating a Salesperson inherited the global context, which included unrelated values as active_model was set to crm.lead. This led to incorrect default values being applied. https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/web/models/models.py#L872C13-L872C21 The default values contained the lead phone and lead number and was applied in the creation of salesperson. Solution: ========== Since we have some synchronization of some fields (email, phone) that is automatically done normally, it's reasonable to remove the code and see what it gives. opw-4871069 Forward-Port-Of: odoo/odoo#229171 Forward-Port-Of: odoo/odoo#217545
Deleting a countdown snippet in the website editor no longer leaves background activity running after the block is removed. This prevents repeated errors and keeps the editing experience stable when users delete embedded website content.
Original PR description
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed…
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed by `DeletePlugin`, the interaction is not destroyed, and a recurrent interval keeps expiring every second triggering multiple errors. This commit introduces the following changes: 1. `EditInteractionPlugin.refreshInteractions`, which is called on normalization, now checks for every interaction and destroyes the ones linked to a disconnected DOM element. 2. `websiteEditService.refresh` now checks if the target element is disconnected, and in this case stops the interaction. 3. `Countdown` now uses the `waitForTimeout` function, which does not execute any callback if the interation has been destroyed. How to reproduce the problem with `s_countdown`: 1. Insert the snippet `s_text_block` 2. Insert the snippet `s_countdown` in the middle of the text 3. Place the cursor after the countdown 4. Press "backspace" until the countdown is deleted 5. The error appears (Alternatively, place the cursor before the countdown and press delete, or select a portion of text including the countdown and press backspace). task-4367641
Point of Sale now only shows paid orders from the current register setup or its trusted related setups. This prevents staff from seeing unrelated orders from other locations or configurations, reducing confusion and improving order accuracy.
Original PR description
Before this commit, when searching paid orders in the PoS UI, orders from other configs could appear even if they were not part of the trusted configs or the same PoS config. This commit ensures that only orders related to the current PoS configuration (or its trusted configs) are loaded and displayed. opw-5083747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228289 Forward-Port-Of: odoo/odoo#227709
This fix prevents rare crashes when users quickly change website shop page options that reload the editor. It improves reliability of the product page editing experience and strengthens automated checks so the issue is caught consistently.
Original PR description
*: website_sale __Current behavior before commit:__ Some builder actions (e.g `ProductPageImageLayoutAction`) reload the editor after being applied. If another button in the builder is pressed…
*: website_sale __Current behavior before commit:__ Some builder actions (e.g `ProductPageImageLayoutAction`) reload the editor after being applied. If another button in the builder is pressed rapidly, `refreshCurrentItem` might be called after the editor is destroyed leading to the following error in [`isApplied`]: `TypeError: Cannot read properties of undefined (reading 'getAction')`. The "Product page options" test fails in rare occasion due to this issue. __Description of the fix:__ - Add a safety guard to make sure the editor is not destroyed before calling `refreshCurrentItem`. - Add some checks at the end of the test in order for the crash to appear consistently (if the fix is not applied). - Make the test more robust (some code is backported from [this commit]). [this commit]: https://github.com/odoo/odoo/commit/670b1daa2254d76 [`isApplied`]: https://github.com/odoo/odoo/blob/f258b263136f606f7896/addons/html_builder/static/src/core/utils.js#L939 Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/232649
The rental schedule now correctly lists every rental order when the same serial-numbered item is rented more than once. This helps teams see accurate rental demand and availability instead of undercounting repeated rentals.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
The Field Service onboarding guide now works correctly even when a Field Service project already contains task templates. This helps new users complete setup without being blocked by existing project data.
Original PR description
This commit's purpose is to allow the fsm onboarding tour to work even if there are existing task template within the fsm project. note : This commit has to be edited in the 19.0 forward port, since its IsActive selector was updated. It should be ["body:has(.o-kanban-button-new.o-dropdown-caret"] instead. task-5088820
This fixes an issue where shoppers could select a free reward product from a coupon offer but it was not added to their cart. The checkout now correctly recognizes the selected reward product, helping promotional campaigns work as expected.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a coupon program with a free product reward using a product tag; 2. generate coupons & copy a coupon code; 3. have 2 or more products with the tag; 4. go to /shop & add any product to your cart; 5. go to checkout; 6. apply coupon code; 7. select a free product; 8. click "Use". Issue ----- Product isn't added to the cart. Cause ----- On forward porting a fix for a similar issue in bb92ba5fbba94, it accidentally checks for the `product_id` in `request.env` instead of `request.env.context`. As no `product_id` is found, no product is added. Solution -------- Check `request.env.context` instead of `request.env`. opw-4979939 Forward-Port-Of: odoo/odoo#229157 Forward-Port-Of: odoo/odoo#224166
2 changes
Resolved issues and error corrections
OSS tax reports can now open correctly when a fiscal position uses a country group, such as Mainland Spain, instead of a single country. This helps businesses report EU OSS taxes for regions like Spain and the Canary Islands without report access errors.
Original PR description
To be able to deal with Spain with Canary Islands and mainland, we have a country group that is Mainland Spain VAT, with Spain minus several states (Canary basically). People want to be able to use it for OSS. But currently, if you have an entry with a tax with a fp with this country group (and no country), you can't open your OSS Report. So take the countries of the country group if there is none in the fiscal position.
This update prevents errors when multiple employees are clocked in on the same Belgian POS. Sales and session closing can now continue normally in this scenario, reducing disruption for store staff.
Original PR description
- Fix traceback when trying to sell a product with multiple employees clocked in on the same POS. - Fix traceback when trying to close a session with multiple employees clocked in. task-id: 4902090 Forward-Port-Of: odoo/enterprise#93273
1 change
Resolved issues and error corrections
Fixed an issue where the rental schedule could hide later rental orders for the same serial-numbered product when rental transfers were enabled. Businesses can now see all bookings for the same serialized item, improving schedule accuracy and reducing missed rental visibility.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
14 changes
Resolved issues and error corrections
Internal users previewing project task portal pages will now see the same “Back to edit mode” banner that already appears on project portal pages. This keeps the portal preview experience consistent and helps users quickly return to editing from task detail pages.
Original PR description
Steps to Reproduce: - Log in as an internal user with project access. - Open a project’s portal page: /my/projects/. - Open a task’s portal page: /my/tasks/ (or via /my/projects/<id>/task/). - Compare the banner visibility between the project page and the task page. Current Behavior: The “Back to edit mode” banner appears on the project page but is missing on the task detail page. This leads to an inconsistent experience when previewing portal content and causes failure of the industry_fsm tour. Expected Behavior: The “Back to edit mode” banner should consistently appear on the task detail page as well, allowing users to return to edit mode from any portal view. Task-5083445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shop floor barcode actions now clear the manufacturing order filter after they run, preventing teams from staying on a narrowed work order view by mistake. This makes scanner-based operations more reliable and reduces confusion on the production floor.
Original PR description
To reproduce: - Create multiple WOs in assembly line 1 - Open shop floor, assembly line 1 - Scan one of the MO barcodes to filter - Scan OBTPAUS/OBTCLMO/OBTCLWO Current behaviour: The expected action gets executed, but the MO filter set in the search bar remains. Expected behaviour: The expected action gets executed and the filter is removed. Task: 5107223
Fixes an error that could occur when users clicked Tickets Closed on the Helpdesk dashboard or applied Closed On date filters. This restores reliable access to recent closed-ticket views and prevents disruption from server error messages.
Original PR description
Steps to reproduce: - 1. Install the helpdesk module. 2. Navigate to the Helpdesk Overview dashboard. 3. On any team card (e.g., VIP Support), click the 'Tickets Closed'. 4. (Alternative): Go to the 'All Tickets' list view, open the search filters, and select a 'Closed On' date filter like 'Last 7 Days'. Issue: - Clicking the 'Tickets Closed' button or applying a 'Closed On' date filter results in a server traceback (ValueError). Cause: - The search filters used an invalid date syntax with multiple operators like `today -7d + 1d` (introduced in commit https://github.com/odoo/enterprise/commit/3db2ad2424f5d40b51bedfba4475fa6b0602c955). Fix: - Corrected the syntax like `today -7d +1d`. task-5069003
Odoo now prevents users from validating a stock transfer when there is no quantity to process. Instead of opening a backorder prompt that cannot do anything, the system shows a clear user error, reducing confusion during delivery validation.
Original PR description
### Steps to reproduce: - Create and confirm a delivery with 2 moves: - 1 x product 1 - 1 x product 2 - Set the quantity of product 2 to 0 and mark it as picked - Validate the transfer #### > The…
### Steps to reproduce:
- Create and confirm a delivery with 2 moves:
- 1 x product 1
- 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.
#### Cause of the issue:
Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.
opw-5076640
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228490
Forward-Port-Of: odoo/odoo#227995This fix prevents duplicate payment provider setup when the payment customization module is initialized more than once, such as during a reinstall. It also ensures the correct wire transfer provider is used, reducing setup errors for businesses using payment and delivery features.
Original PR description
**Description of the issue/feature this PR addresses:** If the `post_init_hook` is executed a second time for some reason (ie., reinstalling the module), then errors happen: - It will create again copies of providers. - If you have installed `delivery`, then the `main_provider` to copy may not be the one with `custom_mode='wire_transfer'.` This PR avoids these errors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a checkout issue where customers who selected a free product from a coupon reward could not add it to their cart. Coupon-based promotions with multiple eligible free products now work as intended, reducing checkout friction and support cases.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a coupon program with a free product reward using a product tag; 2. generate coupons & copy a coupon code; 3. have 2 or more products with the tag; 4. go to /shop & add any product to your cart; 5. go to checkout; 6. apply coupon code; 7. select a free product; 8. click "Use". Issue ----- Product isn't added to the cart. Cause ----- On forward porting a fix for a similar issue in bb92ba5fbba94, it accidentally checks for the `product_id` in `request.env` instead of `request.env.context`. As no `product_id` is found, no product is added. Solution -------- Check `request.env.context` instead of `request.env`. opw-4979939 Forward-Port-Of: odoo/odoo#229157 Forward-Port-Of: odoo/odoo#224166
Calendar views can now correctly filter records linked to multiple people or items, such as tasks assigned to several users. This helps teams see complete and accurate results when selecting one or more filter values in the calendar.
Original PR description
This commit add support for Many2many filters in the calendar arch. This PR follows the PR #215790 Example: Add `<field name="user_ids" filters="1" invisible="1"/>` in the calendar arch with: Tasks: - T1 assigned to A - T2 assigned to A and B - T3 assigned to B and C Giving: - A => show T1 and T2 - B => show T2 and T3 - A and B => show T1, T2 and T3 task-5005992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the online shop’s GeoIP cart test uses pricelists even when a database has no demo data. It improves test reliability and helps prevent false failures in automated validation without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a database without demo data; 2. run `test_cart_new_pricelist_from_geoip`. Issue ----- Test fails, due to the order not having a pricelist. Cause ----- Pricelists aren't enabled by default without demo data. Solution -------- Call `self._enable_pricelists()` at the start of the test. runbot-232989 Forward-Port-Of: odoo/odoo#229224
The rental schedule now correctly lists every rental order for products tracked by serial number, even when the same serial number is rented again. This prevents missing bookings and gives rental teams an accurate view of product usage and availability.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
Free products added through loyalty rewards on sales orders now use the reward description as the line name instead of the underlying product name. This makes customized reward descriptions appear consistently and reduces confusion for sales teams and customers.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#229152 Forward-Port-Of: odoo/odoo#223755
The SEPA payment flow now checks the bank account actually selected by the user, not just the account originally linked to the bill. This prevents incorrect warning banners when a trusted bank account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Point of Sale now waits until a blackbox discount has finished applying before allowing payment to proceed. This prevents payments from being created with an outdated amount, reducing cashier confusion and terminal payment errors.
Original PR description
Before this commit, if a discount was applied with the blackbox, it was applied after communication with blackbox which could be slow. If the user was clicking payment before this disound was applied and had only one payment method, a payment line with the old amount was added which could lead to confusion and errors when this payment line was sent to a terminal. This is fixed by waiting for the discount to be applied before being able to click on payment. Community PR: https://github.com/odoo/odoo/pull/221020 Forward-Port-Of: odoo/enterprise#93809 Forward-Port-Of: odoo/enterprise#91256
Vendor payments no longer show a warning when a user manually selects a bank account that is already trusted. This helps accounting users avoid confusion and proceed with SEPA payments based on the account they actually selected.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
The point of sale flow now waits for a discount to finish applying before allowing payment to continue. This helps prevent incorrect payment amounts being sent to terminals, reducing cashier confusion and transaction errors.
Original PR description
pos*: point_of_sale, pos_restaurant Before this commit, if a discount was applied with the blackbox, it was applied after communication with blackbox which could be slow. If the user was clicking payment before this disound was applied and had only one payment method, a payment line with the old amount was added which could lead to confusion and errors when this payment line was sent to a terminal. This is fixed by waiting for the discount to be applied before being able to click on payment. Enterprise PR: https://github.com/odoo/enterprise/pull/91256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225358 Forward-Port-Of: odoo/odoo#221020
9 changes
Resolved issues and error corrections
This fix prevents Point of Sale orders from failing when branch users sell products assigned to a parent company with real-time inventory valuation enabled. It ensures staff can complete sales without access errors related to product cost currency information.
Original PR description
Before this commit, if a product was assigned to company A and a user from one of its branches tried to create an order with real-time inventory valuation enabled, the system would raise an access error when reading the product's cost_currency_id field. opw-4969390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223951
This change fixes an unstable automated test for the HTML editor by ensuring the editor toolbar is fully ready before the test continues. It helps prevent false test failures, improving confidence in releases without changing user-facing behavior.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090
The stock receipt screen now prevents users from editing a lot field that cannot correctly save lot information for lot-tracked products. This avoids a confusing situation where a lot appears selected but validation still fails because the system has not actually assigned it to the stock movement.
Original PR description
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the…
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the move in the picking form - Click Validate #### > Invalid operation: you need to provide Lot/Serial numbers of the product ### Cause of the issue: The set method of the `lot_ids` field of the `stock.move` model does nothing for product tracked by lots: https://github.com/odoo/odoo/blob/7a8f9b7fe4dded4cfa140103d51b52e08149cadb/addons/stock/models/stock_move.py#L575-L579 In particular, while the lot appears on the move in the view, none of the move lines refer to it and the transfer can not be validated as indeed no lots are provided to these reservations. ### Fix: The feature of writing `lot_ids` for lots has been introduced in https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e https://github.com/odoo/odoo/blob/1c52e2e9e8e00a19e2db00bf70d658496f9a0f29/addons/stock/models/stock_move.py#L596-L600 But this major refactoring can of course not be backported in 18.0. Therefore, it was decided put the field in readonly when its set method is inefficient. opw-5093217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds checks to ensure keyboard formatting shortcuts work correctly when no text is selected in the HTML editor. It helps prevent unwanted undo history entries and keeps editing behavior consistent for users.
Original PR description
Description of the issue this PR addresses: This PR adds test cases for formatting shortcuts (e.g., Ctrl+B) on a collapsed selection. An empty inline tag is inserted temporarily and auto-cleaned if unused, so no individual history step are created. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product prices on the website now display using the currency's configured rounding, so currencies set to show no decimals will no longer appear with two decimals in normal customer sessions. This keeps storefront pricing consistent between editor preview and customer-facing pages.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878 Forward-Port-Of: odoo/odoo#224429
Active payment providers can no longer have their linked payment journal cleared from the journal settings. This prevents payment failures caused by missing journal information when customers try to pay.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an active payment provider; 2. create a branch company; 3. set payment provider's company to branch; 4. leave Payment Journal unchanged (parent company Bank); 5. go to Accounting / Configuration / Accounting / Journals; 6. open Bank journal; 7. open "Incoming Payments" tab; 8. enable the "Payment Provider" column; 9. unset the payment provider on the active provider's line & save; 10. attempt paying using the provider. Issue ----- > Error: psycopg2.errors.NotNullViolation: > null value in column "journal_id" of relation "account_payment" violates not-null constraint Cause ----- We shouldn't be able to change the related journal of active providers. Solution -------- Make the field read-only if the payment method is active. opw-5045000 Forward-Port-Of: odoo/odoo#225187
Prices in the rental eCommerce flow now respect the website currency's decimal precision for public visitors. This prevents prices from incorrectly showing two decimal places when the business has configured a different currency format, such as no decimals.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#95634
Fixed an issue where the rental schedule could hide later rental orders when the same serialized item was rented again. Businesses can now see all relevant rental bookings accurately, improving planning and availability visibility.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
Point-of-sale orders in Spain that fail to upload to TicketBAI will now be retried automatically instead of blocking later submissions. This helps prevent silent reporting gaps and reduces manual intervention for failed fiscal uploads.
Original PR description
Currently if any PoS order uploads to TicketBAI fail, all future uploads will also silently fail since the chain head was never posted. Steps to reproduce ----- 1. Send a PoS order to TicketBAI have the upload fail 2. Validate another PoS order 3. The upload for the second order is never attempted Cause ----- The first order creates a `l10n_es_tbai_post_document_id` and chain index it is uploaded, but the document's state will remain rejected if the upload is unsuccessful. Any subsequent orders will fail the `_check_can_post()` check since the chain head is not accepted. Solution ----- Create a cron to automatically retry uploading the chain head if it's not posted, and retry any other uploads that were not sent. opw-4669823
2 changes
Resolved issues and error corrections
This fixes the Spanish accounting setup so account 411 is classified as a current liability. The change helps ensure financial reports and accounting balances use the correct category for this account.
Original PR description
Account 411 should be of 'liability_current' type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Chilean bank reference data rely on the country's stable internal identifier instead of its display name. It prevents module updates from failing when country names have been changed or corrupted in a database, improving reliability for Chile localization upgrades.
Original PR description
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted: ```SQL pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN…
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted:
```SQL
pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN ir_model_data d ON d.res_id = c.id AND d.model = 'res.country' AND d.module = 'base' AND d.name IN ('cl', 'co')
+----------+
| ?column? |
|----------|
| COLOMBIA |
| Colombia |
+----------+
```
Note: in this specific, the change is clearly an error introduced in the data. Still, the error it produces (which follows) can be avoided by referring to the xmlid, instead of the record name.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
File "<decorator-gen-6>", line 2, in new
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
load_modules(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 226, in load_module_graph
load_data(env, idref, 'update', kind='data', package=package)
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 79, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 624, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 680, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_cl failed: file l10n_cl/data/res.bank.csv could not be processed:
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
```
upg-3131231