Daily updates from Odoo
Tuesday, September 2, 2025
27 changes · saas-18.4
Resolved issues and error corrections
This fixes an issue where refunds for products tracked and valued by lot could leave the related stock transfer unvalidated after closing a Point of Sale session. The correction removes invalid empty stock lines instead of leaving them with zero quantity, helping inventory and accounting records stay accurate automatically.
Original PR description
When refunding a product that was lot valuated, the picking would not be validated automatically. Steps to reproduce: ------------------- * Create a product tracked by lot, and valuated by lot * Open…
When refunding a product that was lot valuated, the picking would not be validated automatically. Steps to reproduce: ------------------- * Create a product tracked by lot, and valuated by lot * Open PoS and create an order with this product * Validate the order and create a refund for it * Validate the refund * Close the session, and go to the picking of the session > Observation: The picking is not validated automatically. Why the fix: ------------ It was happening because the line that was put to 0 here (https://github.com/odoo/odoo/blob/eab97bed9c55a9057c7af7450ae1a09c6383a7b5/addons/point_of_sale/models/stock_picking.py#L249) has no lot assigned and should be deleted instead of just put to 0 quanity. It would then raise an error here (https://github.com/odoo/odoo/blob/2d933b83613ad52d76ab457201adecac6fcf184b/addons/stock_account/models/stock_move_line.py#L94) and cancel the validation of the picking. opw-4769042 Forward-Port-Of: odoo/odoo#224647 Forward-Port-Of: odoo/odoo#223888
Refunds for standard-cost inventory purchases now correctly reverse the related accounting entries instead of repeating the original bill balances. This helps keep stock valuation and purchase accounting accurate when products are returned and credited.
Original PR description
When users refund a real-time/standard cost product purchase, cogs lines are not reversed **Steps to reproduce** 1. Create a product category [CATEG]: - Costing Method: Standard - Inventory…
When users refund a real-time/standard cost product purchase, cogs lines are not reversed
**Steps to reproduce**
1. Create a product category [CATEG]:
- Costing Method: Standard
- Inventory Valuation: Automated
- Price Difference Account: 101403 Outstanding Payments (any account will do)
2. Create a product [PROD]
- Type: Storable
- Category: [CATEG]
3. Create and confirm a PO with [PROD]
4. Process the receipt
5. Create the bill
6. Issue the return and process it
7. Create the refund
**Issue**
The credit note cogs lines (price difference account and stock interim) have the same balance of the bill
However the credit note should mirror the original BILL with the opposite accounting entries.
This seems to occur because, when generating cogs lines, we take into account that the current move is a refund but then we use the move direction sign to alter the balance sign
opw-4845342
Forward-Port-Of: odoo/odoo#224873
Forward-Port-Of: odoo/odoo#221198This fix ensures that point-of-sale loyalty promotions calculate free product quantities correctly when multiple rewards are available. Customers and cashiers should see the right free items applied, reducing pricing mistakes and manual corrections.
Original PR description
Before this commit, when there were multiple reward lines for free products, adding a combination of those products would result in incorrect claimed free product quantities. opw-4975059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224683 Forward-Port-Of: odoo/odoo#222780
Point of Sale now uses the currency's rounding precision when calculating combo child item prices, matching the Sales app behavior. This prevents small one-cent differences between the expected total and the POS total when product price precision differs from currency precision.
Original PR description
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total…
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total between the sale and pos app. Steps to reproduce: ------------------- * Modify the product precision to have 4 digits * Modify the burger menu combo product * Sale price 26.5 * Burger choice: Cheese burger, remove taxes, change price to 10 * Drinks choice: Coca cola, remove taxes, change price to 10, extra price set to 4.5 * Add another combo choice with 1 product only, no tax, price 10 * Open pos session * Add the combo, select the product that were modified > Total is 31.01 when it should be 31.00 Why the fix: ------------ Point of sale was using the decimal precision set on the product price to compute the price unit of the child lines. We can notice that the sale app was using the currency precision. We will use the same approach as sales. The decision was driven by the fact that 1) both scenarios could make sense, 2) total should be as set, 3) child line prices are not as important as the total and don't have a big influence. opw-4769227 Forward-Port-Of: odoo/odoo#224740 Forward-Port-Of: odoo/odoo#220352
This update prevents errors when users clear an end date on a time off request. It also ensures the correct working calendar is used when leave dates are changed after saving, improving accuracy for employees with changing schedules.
Original PR description
Bug 1 - traceback on removing end date
Steps to reproduce:
- open the time off request form
- remove the end date
Cause:
- bool comparison with date
Fix:
- add a check before using the request_date_from or request_date_to
Bug 2 - inappropriate resource calendar use
Steps to reproduce:
- Create two different version with different working calendar.
- now while creating leave record it uses correct resource calendar as per
request dates.
- but after saving the leave record, if try to change the request dates
it does not use correct resource calendar.
Cause:
- resource calendar compute method is not dependent on request dates.
Fix:
- updated the depends of compute method.
moreover refactored the method to improve the performance.
task-4965122
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix lets HR users update multiple employee versions tied to the same contract without triggering synchronization errors. It improves reliability when maintaining contract-related employee records and adds test coverage to prevent regressions.
Original PR description
Problem ---------- If you write on multiple versions with the same contract, the sync will not work and will raise errors Solution ---------- Change the behavior of the `write` to allow multiple write. 4 tests are added for that 1 removed because we don't want to allow merge of different contracts task-5030583
Point of Sale now applies product pricing rules in the right quantity order instead of relying on an internal record number. This helps ensure customers are charged the intended price when quantity-based pricelist rules are used.
Original PR description
Before this commit, the product pricelist items stored in IndexedDB were sorted by their `id`, which led to incorrect rule application in the PoS. When retrieving rules for a product, the order of rules matters. opw-4997926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224687 Forward-Port-Of: odoo/odoo#222230
This fixes an accounting error when a dropshipped product is returned to an internal subcontracting location. The return now increases inventory value correctly, helping ensure stock valuation and interim accounts stay accurate for companies using automated valuation and Anglo-Saxon accounting.
Original PR description
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will…
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it **Steps to reproduce:** - enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings - create a storable product with dropshipping route and a vendor - in 'general information' write a non null cost - make sure the product category's inventory valuation' is 'automated' - create a new quotation for this product, confirm it and confirm the linked purchase order - click on the dropship smart button and validate the picking - click on return and select 'Physical Locations/Subcontracting Location' as the return location - validate and click on the valuation smart button - on the only stock valuation layer for this move, click on the book shaped widget **Current behavior:** the account move credits Stock Valuation and debits stock interim (received) **Expected behavior:** As we are returning the product to stock it should increase the value of the stock valuation account. Therefore, it should debit stock valuation and credit stock interim (received) **Cause of the issue:** If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location) https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614 opw-4894755 Forward-Port-Of: odoo/odoo#224871 Forward-Port-Of: odoo/odoo#221009
This fix prevents Point of Sale order validation from getting stuck in an endless loading cycle. It ensures orders downloaded in PoS use the correct data retrieval path, improving reliability for cashier workflows and online payment scenarios.
Original PR description
*: pos_online_payment The `pos.order` model was missing from pohibitedAutoLoadedModels which was causing infinite loop when validating an order. This commit add this models to the pohibitedAutoLoadedModels variable. Now when downloading an order from the PoS the `read_pos_orders` method should be used, it will returns all related order data.
This fixes issues in the website form editor where conditional visibility settings could show partner ID numbers instead of names or fail to select a default condition. It also restores related automated test coverage so future changes are less likely to reintroduce the problem.
Original PR description
**Commit: 1** Steps to reproduce: 1. Add "To (Partners)" field in the form snippet. 2. Click on any other field and set visibility to "Visible only if". 3. Click on "To (Partners)". You will see a…
**Commit: 1** Steps to reproduce: 1. Add "To (Partners)" field in the form snippet. 2. Click on any other field and set visibility to "Visible only if". 3. Click on "To (Partners)". You will see a list of ids instead of partner names. Root cause: In FormOptionPlugin, the list of conditional visibility options is built from the option values. Since partners use ids as values, only ids were displayed. Fix: We added a conditional check to display the correct textContent. The condition is introduced by this commit https://github.com/odoo/odoo/commit/60f0cb8b979195905be118d3ee2817eac3948ffe **Commit: 2** Steps to reproduce: 1. Drop a form snippet and click on any field. 2. Change visibility from "Always visible" to "Visible only if". 3. Notice that no default comparator is selected. In previous versions, a default comparator was present. Issue: In `SetVisibilityAction.prepareConditionInputs`, the list of available fields for conditional visibility also includes hidden fields such as `email_to`. With the current logic, if the field name is not null, it is assigned as the default comparator. Since `email_to` is hidden, the default visibility condition is not set. Fix: By skipping hidden fields when preparing condition inputs so that only visible fields can be selected and used as the default comparator. The condition was introduced by commit https://github.com/odoo/odoo/commit/24a7112d7b85d045ffb0629f7feb6e5556e809a1 **Commit : 3** This commit re-enables the test_tour test, which was broken and skipped due to the DOM changes introduced by the new Website Builder. It also adapts the tour selectors accordingly.
This fixes a regression in the website builder where editing content that appears in multiple places on a page did not update all matching occurrences. Business users editing menus, category names, or related product/page fields should now see consistent changes across desktop and mobile views, reducing manual cleanup and publishing mistakes.
Original PR description
In the previous builder, the replication was done here: https://github.com/odoo/odoo/blob/b5f795de71e1a77fdc65aaed8a18ff2e92b67800/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1263-L1356
The website editor color picker now uses semi-transparent default grayscale colors and gradients for image overlays, so backgrounds remain visible instead of being covered by solid colors. It also correctly shows when a default color has been selected, making editing more predictable for users.
Original PR description
*: html_builder, html_editor, web, website Previously, color filter default colors and gradients were set to 100% opacity, making them ineffective as overlays. This caused two issues: - Default colors didn't have the checkered transparency pattern in the color picker as in 18.3 - Fully opaque colors blocked the underlying image Steps to reproduce the original issue: 1. Open website and start editing 2. Drop any snippet with an image background and click on it 3. Click on the color filter option color picker The default colors and gradients appear solid and hide the background when applied. This commit introduces default 50% opacity to create functional semi-transparent overlays. As well as this, this PR fixes the problem when, after selecting the default color in the color picker, the color wasn't marked as selected. This PR follows [the html_builder refactoring]. [the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb Related to task-4367641
Fixes a problem where saving a form could show a redirect warning that failed to open the right corrective action or include needed context. Users can now follow the warning from the save flow and be taken to the appropriate action to resolve the issue.
Original PR description
Have a web_save that raises a RedirectWarning which has the ID of an action and an additional context in its parameters. Trigger the warning in the form view by clicking on the save button in the form view. Before this commit, this feature did not work like at all. - The additional context was not taken into account - the path taken by clicking on the form's save button was not able to handle interacting with the main form view - The error dialog did not handle going into an action in target other than new After this commit, all this is fixed and the whole flow, that allow an error to be enriched such that the user could do the correct action to correct the error now works. opw-4742952 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#224620 Forward-Port-Of: odoo/odoo#223198
This fixes a live chat issue where customers could sometimes see a restart button after their conversation had already been forwarded to a human agent. Keeping the chatbot state consistent across browser tabs prevents confusing options from appearing during support conversations.
Original PR description
Before this commit, the restart button was sometimes shown after the conversation was forwarded to an agent which should not happen. This happens because the state of the chat bot is not sent on the bus, leading to inconsistent state. This commit ensures each step is sent on the bus to avoid inconsistencies. This commit also ensures the selected answer of a selection step is properly sent to every tab to avoid similar issues. task-5031990 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#223879
This fix restores the review summary shown in portal pages, so customers can see rating feedback where expected. It also updates related portal rating behavior and test coverage to help prevent the issue from returning.
Original PR description
*: portal_rating, rating, test_mail_full task-4853416 Forward-Port-Of: odoo/odoo#224415 Forward-Port-Of: odoo/odoo#216044
Razorpay return notifications sometimes include only confirmation identifiers, without amount or currency details. This fix lets those payments validate correctly, preventing checkout errors for affected eCommerce customers, especially on iPhone flows.
Original PR description
When processing notification data from the route `/payment/razorpay/return`, only three fields are available: `razorpay_payment_id`, `razorpay_order_id`, and `razorpay_signature`. See official source here: https://razorpay.com/docs/payments/payment-gateway/callback-url/#2-what-are-all-the-field-names-posted This fix prevents the error "The amount or currency is missing from the payment data." during validation, since neither amount nor currency are included in the notification payload. Steps to reproduce: - Setup Razorpay - Pay for a product on an eCommerce website from an iPhone - An error occurs due to missing amount and currency in the notification data. opw-4989944
This fixes an issue where users working in 12-hour time formats could select an afternoon time, such as 6 PM, but the field would save it as 6 AM. The date and time picker now correctly understands shortened AM/PM time entries, reducing scheduling mistakes for affected users.
Original PR description
Be in (or configure) a language with the 12 hour time format (i.e. such that times are displayed with am/pm). In a datetime field, open the datepicker and set the time in the afternoon (e.g. 6pm). Before this commit, the value that was actually set in the input was in the morning (6am in this case). The cause of the issue came from the date parsing. As we do not display the seconds in the input, the value was "06:00 pm", which couldn't be parsed properly. This commit fixes the issue by adding a step in parseDateTime, to try to parse with the short time format. opw~4996133 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#224936
The point of sale now calculates additional down payments on a sales order based on the remaining amount, not the original total. This prevents customers from being asked to overpay when making multiple deposits on the same order.
Original PR description
- Create a SO of 450 with 15% tax for a total of 517.50 - Create a first down payment from the POS of 10% => you pay 51.75 - Create a second down payment from the POS of 10% => we ask you to pay 51.75 again => We should ask him to pay 10% of 517.50 - 51.75 instead --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224223
Fixes an error that could occur when reloading fiscal localization settings after a related localization module was uninstalled in another session. This helps accounting users continue configuration work without needing to refresh or recover from a crash.
Original PR description
Currently, an error occurs when a user attempts to reload the fiscal localization after uninstalling the `l10n_syscohada` module. **Steps to Reproduce:** - Install l10n_cf module(with demo). - Switch…
Currently, an error occurs when a user attempts to reload the fiscal localization after uninstalling the `l10n_syscohada` module. **Steps to Reproduce:** - Install l10n_cf module(with demo). - Switch the company to `CF Company`. - Navigate to Invoicing settings - Login in different device with admin rights - In other device, uninstall l10n_syscohada module. - Now switch back to main device and do not reload the tab. - Click on Reload button under Fiscal Localization. **Error:** `TypeError: super(type, obj): obj must be an instance or subtype of type` **Root Cause:** since https://github.com/odoo/odoo/pull/186635/commits/58fb2db14ce3b7ddd70ffd617d2152c836151455, the line `self = self.env()['account.chart.template']` was removed from [1] when clicking the reload button, system tries create **data** at [2] but fails because the registry has been reset. [1]- https://github.com/odoo/odoo/blob/1dfa4cc9d259b4918424a07394938e24da8c643d/addons/account/models/chart_template.py#L183-L184 [2]- https://github.com/odoo/odoo/blob/c363014fe77d2ea706dabf8af232745d4e723267/addons/account/models/chart_template.py#L222 **Solution:** This commit prevents the error by providing new `env` with new `registry` to handle loading during the reload process. Sentry-**6272559266, 6750055374** Forward-Port-Of: odoo/odoo#216315
Tax return warning checks are now recalculated when a user opens them, so outdated warnings such as draft entries no longer remain after the underlying entries have been confirmed or deleted. This keeps the displayed check status accurate while avoiding extra load on the Tax Returns overview.
Original PR description
Before, when opening a Return that had bypassed checks such as Draft Entries, and we had deleted or confirmed those entries it wouldn't have refreshed the check number and would still display that there are draft entries. Now, we are forcing the check to be refreshed when someone wants to see them as to not crash the performances when someone opens the Tax Returns Kanban view. task-4850581 Forward-Port-Of: odoo/enterprise#90187
The Belgian point of sale integration now handles certain payment/security device errors more safely after sales data is sent. This reduces the risk of unexpected crashes for cashiers while a broader error-handling cleanup is planned.
Original PR description
Before this commit, it could happen that an error returned by the iot when contacting the blackbox was not correctly handled and led to a traceback. This commit solves the issue temporaly before finding a solution to harmonize the error handling in the blackbox. Forward-Port-Of: odoo/enterprise#93468
This fix prevents point-of-sale order validation from getting stuck in an endless loading cycle. It ensures downloaded PoS orders use the proper order-reading process so related order information is loaded safely and reliably.
Original PR description
*: pos_settle_due, pos_urban_piper The `pos.order` model was missing from pohibitedAutoLoadedModels which was causing infinite loop when validating an order. This commit add this models to the pohibitedAutoLoadedModels variable. Now when downloading an order from the PoS the `read_pos_orders` method should be used, it will returns all related order data.
Fixes a Documents app issue where uploading a file for an existing request or through the manage versions dialog created an extra card or list row for progress. The upload progress is now shown on the existing document, reducing confusion and keeping document views cleaner.
Original PR description
Step to reproduce: 1. Upload a file to a request: - Create a Request. - Upload a file for that request. - Another Kanban card / List row is created showing the upload progression. 2. Upload a file into the manage version dialog. - Manage version for an existing document. - Upload a new document. - Another Kanban card / List row is created showing the upload progression. The upload progression should be shown on the existing document. Task-4863051 Forward-Port-Of: odoo/enterprise#87428
Odoo Studio now correctly keeps fields visible and editable when the Technical Features group is selected for field visibility. This prevents fields from unexpectedly disappearing during Studio customization and helps users manage advanced visibility settings more reliably.
Original PR description
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to…
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to groups" => The group is not displayed as a tag - Restore the view - Now without debug mode (?debug=0), repeat the same steps => The field disappears, we need to toggle "Show Invisible Elements" to see it again Cause of the issue ================== https://github.com/odoo/odoo/pull/179354/commits/15aeaf88c268f047b8b83a5aa66f5da246c2b675 When calling get_views, the "base.group_no_one" is removed from the groups attribute and "invisible" is set to true if we are in debug mode. Solution ======== Adding "base.group_no_one" is still the way to have the expected behavior for now. We override some ir.ui.view functions when in studio to be able to edit it. According to the docstring of _postprocess_debug_to_cache, this feature is temporary. Another solution will be needed in the future. opw-4969262 Forward-Port-Of: odoo/enterprise#93435 Forward-Port-Of: odoo/enterprise#91647
Blackbox devices now keep their existing setup when they are unplugged and plugged back in, even if the system assigns a different connection port. This prevents duplicate device records and avoids losing the configuration businesses rely on for IoT operations.
Original PR description
Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing…
Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work. After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device. This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons: - Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts. - Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier. task-5055027 Forward-Port-Of: odoo/enterprise#93593
Fixed an issue that could cause the Tax Report to fail when its root report was changed to another report type, such as the Balance Sheet. This helps accounting users access tax reports without server errors in affected configurations.
Original PR description
**[FIX] account_reports: ensure join on account_move for tax report base amount calculation** Fixes a server error in the generic tax report where `account_move_line__move_id` was referenced without an explicit join. The fix adds a conditional join on `account_move` to make fields like `always_tax_exigible` available, preventing `UndefinedTable` during SQL execution. Steps to reproduce: 1 - in a fresh db or runbot go to `Accounting > Config > Accounting Reports`. 2 - Open the Tax Report and change the `Root Report` to Balance Sheet. 3 - Save and try to open the tax report. opw-4990771 Forward-Port-Of: odoo/enterprise#91941
Rental orders and their planning slots now stay synchronized when dates or shifts change, preventing mismatches and incorrect planning totals. Online shoppers also see more accurate rental availability based on their selected dates, improving booking reliability.