Thursday, October 9, 2025
35 changes · saas-18.3
Resolved issues and error corrections
Fixes an issue where users could see an error message after successfully reconciling the last available batch payment in the bank reconciliation widget. The reconciliation itself worked, but the confusing traceback interrupted the workflow; this change keeps the screen stable when no batch payments remain.
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-4830466
Forward-Port-Of: odoo/enterprise#96598Stripe payments now handle currencies like the Ugandan shilling that use different decimal rules in Stripe than in standard currency settings. This prevents valid payments from being rejected or sent with the wrong amount, improving checkout reliability for affected currencies.
Original PR description
Steps: - Activate the 'UGX' currency. - Make a sale order with amount 100 with 'UGX' currency - Try to pay that order (100 USh) using card Issue: - stripe throws the following error - > 'The Checkout Session's total amount must convert to at least 50 cents. 1.00 USh converts to approximately €0.00.' - Hence 100 USh sent was identified as 1 USh by stripe. This confirms issue with decimals and currency mapping. Cause: - 'UGX' is zero-decimal currency but stripe identify it as two-decimal. Fix: - Update mapping for such special currency cases for stripe that don't follow general rules opw-5075707 Forward-Port-Of: odoo/odoo#227688
Tables pasted from tools like Google Docs now keep the expected formatting and structure in Odoo's HTML editor. This prevents invisible or incomplete tables and makes pasted content easier to edit reliably.
Original PR description
### Purpose of this PR: - Ensure that pasted table elements get the standard classes: `table, table-bordered, and o_table.` - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230425 Forward-Port-Of: odoo/odoo#230208
This fix prevents Live Chat from showing a runtime error in Chrome when an administrator clears browser data. It adds a safeguard for missing storage information, improving reliability during routine browser maintenance.
Original PR description
**Steps to reproduce:** Install 'Live Chat' Open Chrome Log in as 'Admin' Clear browser data **Current behavior before PR:** Clearing data triggers a storage event where the key parameter is null. An event listener attempts to call a method on this null key, leading to a runtime error. **Desired behavior after PR is merged:** A check has been added to ensure the key is not null, preventing the error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230298
The payroll test data for Hong Kong was updated to include required leave allocations. This prevents internal validation errors and helps keep automated checks reliable for future updates.
Original PR description
Issue: Unit tests are failing because test data was created without leave allocations, leading to validation errors. Fix: Added leave allocation data for time off types which requiring allocation in some tests. build_error-230409 Forward-Port-Of: odoo/enterprise#96060 Forward-Port-Of: odoo/enterprise#93160
This fix keeps the restaurant floor screen working correctly when appointments are used, following related updates in the core point-of-sale system. It helps prevent disruptions for restaurants that manage table service and bookings through Odoo.
Original PR description
This commit adapts an overriding method to reflect changes in the base method done in this pr https://github.com/odoo/odoo/pull/176016. Forward-Port-Of: odoo/enterprise#91334
The bank reconciliation widget now keeps existing invoice matches when users choose a write-off account that has a default tax. This prevents matched bills from disappearing during reconciliation, reducing rework and avoiding confusion for accounting users.
Original PR description
In the Bank reconciliation widget, users can click a button to set the account to write off the remaining balance. However, if the chosen account has a default tax set, the widget will lose any existing matches with invoices. Steps to reproduce: - Have an account with a default tax - Create a bill with a total - Create a bank statement for a greater amount - Open the bank reconciliation widget - In the created statement, first add the bill, then click 'Set Account,' and choose the account with tax Issue: Bill matching will be lost. This occurs because we remove and recreate the matching line, but we don't keep the line to be reconciled. opw-5002624
This update adjusts how a setting is written in the sales timesheet invoice wizard so it can be safely read by Python-based customizations. It helps prevent errors for businesses using customized invoice workflows, with no expected change to normal user behavior.
Original PR description
Versions -------- - 17.0+ Issue ----- Some customizations may parse XML views using Python, in which case the `date_start_invoice_timesheet` field could return an error, as the `options` attribute uses a Javascript boolean `true`. Solution -------- Use `'true'`, which will get parsed as `true` in JS via `archParseBoolean`. Forward-Port-Of: odoo/odoo#230278
Fixes a checkout issue where valid promotions or coupons could be removed because the storefront and payment confirmation used different time zones or timing. This helps prevent paid orders from getting stuck as unconfirmed and ensures expired coupon discounts are removed before payment is finalized.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California…
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California before 7:00 UTC; 4. add the product to your cart; 5. go to checkout; 6. pay for the order. Issue ----- Order cannot be confirmed due to incomplete payment. Cause ----- The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order. Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order. Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed. Solution -------- If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates. For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone. For website orders, if defined, use the eCommerce salesperson's time zone instead. Also fix an issue where expired coupon lines weren't getting removed from the order. opw-4765873 opw-4781346 opw-4939268 Forward-Port-Of: odoo/odoo#229749 Forward-Port-Of: odoo/odoo#222428
This fix prevents the editor from creating invalid page content when users change the style of text inside certain formatted elements. It helps ensure edited content keeps the expected layout and displays consistently in browsers.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block and we change its font style. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. task-5123274 Forward-Port-Of: odoo/odoo#229043
Fixes an issue where custom hour or half-day selections could be cleared when employees changed the time off type. This helps avoid accidental changes to leave requests and reduces the need for users to re-enter their choices.
Original PR description
- made the value of checkboxes for `request_unit_half` and `request_unit_hours` stay the same when switching between timeoffs that can have hourly type task-id: 5085389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228981
Product searches in Point of Sale now show all relevant matches instead of stopping at an exact match. This helps cashiers find similar or related products more reliably, reducing missed items during checkout.
Original PR description
The POS search only returned products with an exact match (when existing), ignoring other relevant products that partially matched the search string. Steps to reproduce: 1. Create a product "TEST" - Create a variant with attributes value including "TEST" and "OTHER". 2. Create a second product "TEST 2". 3. Open the POS. 4. Search for "TEST". 5. Only "TEST" is shown; "TEST 2" is missing, even with "Search more". To align with the behavior introduced in v18, I’ve removed the exact match condition, as it no longer appears necessary due to the absence of fuzzy search. I’ve also adjusted the logic to perform the search on `product.product` instead of `product.template`. opw-4958141 Forward-Port-Of: odoo/odoo#221520
This fix prevents an error when saving a manufacturing order after changing the duration of a work order that has not yet been scheduled. It ensures only scheduled work orders are used to calculate production start and finish dates, improving reliability for manufacturing teams using work orders.
Original PR description
**Steps to reproduce:** 1. In Settings, enable "Work Orders". 2. Create a product with a BOM that has 2 operations: op1 and op2. 3. Create and confirm an MO for 1 unit. 4. Start op1 and change the…
**Steps to reproduce:** 1. In Settings, enable "Work Orders". 2. Create a product with a BOM that has 2 operations: op1 and op2. 3. Create and confirm an MO for 1 unit. 4. Start op1 and change the Real Duration of op2. 5. Try to save. **Issue:** - Traceback : `'<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause of the issue:** Starting the first operation launches a call of the `button_start` method creating a `resource.calendar.leaves` to set on the `leave_id` of this first operation: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_workorder.py#L630-L641 Then, setting the duration of the second operation from the form view of the MO and saving triggers a call of the write of the MO containing the `[Command.update(op_2.id, new_duration)]` as vals.This, in turn, calls `_plan_workorders`: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L939-L942 while the first operation has a set `leave_id` but the second do not However, the `min` operator will be applied to both the set and the unset values, comparing a `boolean` with a `datetime`: https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L1581-L1588 **Solution:** Only workorders with a `leave_id` (i.e., those planned in work-center schedule) should be considered when computing MO `date_start` and `date_finished`. Workorders without a `leave_id` are not yet scheduled and therefore should not influence MO start and end dates. As both `date_start` and `date_finished` of a workorder are related to the `leave_id` record. As per `mrp_workorder._compute_dates`, these dates reflect the work-center scheduling (`leave_id.date_from` and `leave_id.date_to`). https://github.com/odoo/odoo/blob/6a075fa3c090920499ccbd5fe673819da7e3f95e/addons/mrp/models/mrp_workorder.py#L250-L260 Therefore, when computing MO dates, it logically follows that only workorders with an assigned `leave_id` should be used. This avoids mixing unscheduled operations (`leave_id = False`) with scheduled ones, preventing invalid comparisons and ensuring accurate production timing. **opw-5068080** Forward-Port-Of: odoo/odoo#226436
This fixes an issue where French POS order integrity hashes could be created before all order details were finalized. The change helps prevent valid orders from being incorrectly flagged as altered during compliance checks.
Original PR description
Description of the issue/feature this PR addresses:
Starting from version 18.0, inalterability hashes in the FR localization are sometimes calculated with incomplete data, leading to incorrect `l10n_fr_hash`. Related orders are then wrongly flagged as altered when running the POS Inalterability Check.
Current behavior before PR:
When you post a POS order and a related draft order exists, Odoo updates the existing order with the new vals. Because `{'state': 'paid'}` is amongst the new vals, it triggers the generation of the `l10n_fr_hash` before the order is fully processed. For instance, the hash will be generated before a new payment line is added for change with `_process_payment_lines()`.
Desired behavior after PR is merged:
The hash should be generated at the end of the order processing, with the final write in `action_pos_order_paid()`.
Forward-Port-Of: odoo/odoo#226032Fixes an issue where opening a shared employee profile link could display an error when the profile contained private information. Users now receive a clearer message and can be redirected to the public employee list, reducing confusion and improving reliability.
Original PR description
Sharing a link of an employee profile containing private info generated a traceback. Permissions had to be applied to the private field. I've also put a more explicit error message that allows the user to get redirected to the public employee list. I couldn't find a way to get the employee id from the url before the generic permission warning comes in. Thus I had to resort to redirecting to the general public employees list. Other tracebacks may happen each time a private field without the corresponding groups is put in the xml. Thus I added a test to prevent us from doing that again. Forward-Port-Of: odoo/odoo#229611 Forward-Port-Of: odoo/odoo#228623
Inventory transfers now list each source document only once, even when multiple items come from the same receipt. This keeps transfer records clearer and avoids confusing repeated references for warehouse users.
Original PR description
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each…
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each origin. ### Steps to reproduce: From Inventory * Enable two step transfer for the warehouse From Barcode * create and validate new receipts with "Product A" * create and validate a second new receipts with "Product A" and other products From Inventory/Operations/Transfers/Receipts * Open the corresponding receipts * In "source Document" (Field: origin, Model : stock.picking) we can see that the reference from second receipts is repeated. ### Observation: In the case of already existing origins it will not duplicate them but it's missing if several item comes from the same origin. https://github.com/odoo/odoo/commit/0caa44ca97d9d197811a03ad2ff227df68d4437a#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR1410 opw-4970159 Forward-Port-Of: odoo/odoo#223251
Survey participants can now submit a comment as their answer to eligible multiple-choice questions, even when roaming is enabled. This prevents incorrect required-answer warnings and adds safeguards so single-choice questions cannot receive multiple answers.
Original PR description
Issue: When answering a question with a comment in multiple choice with roaming activated for the survey, the UI will display a warning message that says the question requires an answer. Cause: The backend creates a skipped record if none of the pre-created answers is chosen. Solution: Don't create a skipped record if a comment counts as an answer and a comment is provided. Added validation of input and unittests Task-5062984 Forward-Port-Of: odoo/odoo#226022
Creating a goal from an employee appraisal now assigns it to the employee being appraised instead of the current logged-in user. Goals created from the general Goals menu remain blank by default, reducing accidental misassignment and improving data accuracy.
Original PR description
If you go on _appraisals -> any employee -> goals smart button -> new_, it will populate the employee field with the current user. Instead, the field should be filled by the appraisal's user. If the goal is created from the "Goals" menu item directly, then no user / manager should be put by default in the goal's fields. I changed the field's default value to use the employee already passed in the context. I also added some tests to make sure the bug doesn't happen again. task-5048292 Forward-Port-Of: odoo/enterprise#93522
This fix stops Odoo from recreating the default administrator employee record during updates. It helps companies that have replaced the default setup with their own HR workflow avoid unwanted duplicate or obsolete employee records.
Original PR description
The `employee_admin` is a default admin option. Later when clients set up their work flow they set up their own admin employee. This record is not present, and it doesn't make sense recreate it with every update. 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#230250 Forward-Port-Of: odoo/odoo#228117
Videos added inside certain website building blocks now expand to the full available width instead of appearing too small. This makes pages using Masonry and similar layouts look more consistent and gives editors the expected visual result without extra workarounds.
Original PR description
To reproduce: ============= 1- In Website edit mode, drop the "Masonry" snippet. 2- Add a video in one of the text blocks. -> It will appear smaller than expected, with no way to make it larger Why: ==== The child iframe already had width: 100%, but it can only stretch to 100% of its parent container. If the parent container (.media_iframe_video) doesn't have an explicit width, it defaults to its minimum content size. This issue happens specifically in blocks where the columns are display: flex. As a result, the iframe ends up being too narrow despite having width: 100%. Solution: ========= By adding width: 100% to the container itself, it now fills the grid cell, and the iframe inside fills the container. opw-5104640 Forward-Port-Of: odoo/odoo#229001
A typo was corrected in the Attendance app's department grouping option. This helps users see the correct department label when organizing attendance records, reducing small reporting or navigation confusion.
Original PR description
- Fixed typo in groupby for 'department' task-id - 5109185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228334
This fixes missed updates from a previous merge for India's localization setup. It corrects chart of accounts data and renames export-related taxes so accounting labels and configuration are accurate for Indian companies.
Original PR description
During the following [fw-port](https://github.com/odoo/odoo/pull/229757/) and resolving conflicts few changes such as Renaming of taxes and change of CoA was missed out in this commit we resolve the issue and add the missing changes that were unintentially missout during fw-port --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing the POS Settle Due module now applies its required products to every point-of-sale configuration, including those with active sessions. This prevents checkout issues when staff need to settle dues, take deposits, or settle invoices in POS.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074
This fix prevents essential point of sale products, such as discounts, tips, and settlement items, from being deleted or archived. It helps avoid checkout and configuration issues caused by missing required products.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes failing automated tests for Hong Kong payroll accounting after a related leave type was moved to another part of the product. It helps keep the payroll accounting test suite reliable without changing customer-facing behavior.
Original PR description
Explanation: l10n_hk_hr_payroll.holiday_type_hk_annual_leave is moved to community. build_error-233182