Daily updates from Odoo
Tuesday, September 2, 2025
47 changes · saas-18.4
Enhancements to existing features
This update adds a way for developers to rerun selected tests directly from the Odoo shell after changing test code. It shortens debugging cycles by avoiding a full server restart for test-only changes, while business logic changes still require restarting the shell.
Original PR description
This commit introduces a new function `run_tests` to the Odoo shell. This function allows users to run specific tests directly from the shell, even after the test code is modified. This significantly…
This commit introduces a new function `run_tests` to the Odoo shell. This function allows users to run specific tests directly from the shell, even after the test code is modified. This significantly speeds up the debugging process by avoiding the need for a full server restart. In the odoo shell ``` >>> from odoo.tests.shell import * >>> run_tests(env, 'test_tags', modules=[module_name], reload_tests=True) ``` Note: `run_tests` automatically reloads test modules but does not reload Odoo model code. A shell restart is still required after any change to business logic. used by https://github.com/HydrionBurst/odoo-test-vscode for hot test vscode extension: [odoo-test-0.0.1.vsix.zip](https://github.com/user-attachments/files/22089685/odoo-test-0.0.1.vsix.zip) tutorial: https://github.com/HydrionBurst/odoo-test-vscode?tab=readme-ov-file#-hot-test 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#225175 Forward-Port-Of: odoo/odoo#224048
This update improves how tooltips are checked in website builder rows, delaying the check until a user hovers over the row. This reduces unnecessary work during page editing and can make the builder feel more responsive.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves internal automated tests for the website and HTML builder by using a safer way to prepare test page content. It helps make test results more reliable without changing what end users see or how they use the product.
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#221198In Point of Sale, opening All Orders from the customer list no longer clears the currently selected customer. This avoids extra re-selection steps and keeps checkout workflows smoother for sales staff.
Original PR description
Before this commit, opening the All Orders from the partner list would reset the selected partner. As a result, the user had to reselect the partner after returning, which disrupted the workflow. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224828 Forward-Port-Of: odoo/odoo#222507
Website module upgrade processing now uses memory more efficiently when handling large website view data. This prevents out-of-memory failures that could block users from accessing their database after an upgrade attempt.
Original PR description
### Issue A user cannot access their database (Bad Gateway) after trying to upgrade a module. ### Analysis The root cause is the out of memory error, stemming from the SQL query fetching all `arch_db` and then fetching them with `fetchall`. ### Solution This commit optimizes the loading of module terms in the `ir_module_module` model by iterating over the rows per chunks. This change reduces the memory footprint, which is crucial when dealing with heavy `arch_db` in the `ir_ui_view` table. We also filter out `if not generic_arch_db` directly in the SQL query instead of on the Python side. After applying this patch, there is no more `MemoryError` and the user can access their database. ### References opw-5014922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224709 Forward-Port-Of: odoo/odoo#223439
Website image grid blocks such as Masonry now keep images inside their rounded or bordered containers. This prevents visual overflow and makes edited website layouts look as intended for visitors.
Original PR description
When a border radius and/or width is applied to an image grid item (e.g. in "Masonry"), the image overflows its parent box. This happens because the style was only applied to the column, not the image itself. This commit adds necessary style to the image to take into account the border radius and width of the parent box. Steps to reproduce: 1. In Website Builder, add the "Masonry" snippet. 2. Select a block with an image (i.e. the block with the largest image) and apply a border radius. 3. Notice that the image does not respect the border radius. Related to task-3358501
This 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
This fixes a timezone issue when sending order dates for POS online payments. Orders are now formatted in UTC as expected by the backend, helping prevent incorrect order timestamps caused by local timezone conversion.
Original PR description
In 2a5f1ab, we formatted the `order_date` with `toFormat(...)`, however, that transforms the date into local, while the backend expects it to be in UTC. In this commit, we set the date tz back to UTC before formatting it. opw-4942697 Forward-Port-Of: odoo/odoo#225041 Forward-Port-Of: odoo/odoo#224085
This fixes a Point of Sale gift card issue where an order could show a second gift card line with a zero amount. The change helps keep receipts and order totals clearer by treating tiny rounding-like values as zero.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358 Forward-Port-Of: odoo/odoo#224870 Forward-Port-Of: odoo/odoo#223948
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
Inventory settings can now be saved even if the Replenish on Order route was previously deleted. This prevents an unexpected error and avoids blocking users from updating configuration settings.
Original PR description
Currently, an error occurs when saving settings if the `Replenish on Order (MTO)` route has been deleted. **Steps to reproduce:** - Install the `stock` and `purchase` modules. - Go to inventory…
Currently, an error occurs when saving settings if the `Replenish on Order (MTO)` route has been deleted.
**Steps to reproduce:**
- Install the `stock` and `purchase` modules.
- Go to inventory settings > enable `Multi-Step Routes` and `Replenish on Order (MTO)`.
- Go to inventory > Configuration > Routes and delete the `Replenish on Order (MTO)` route.
- Open the Settings app and click `Save`.
**Error:**
`AttributeError: 'NoneType' object has no attribute 'sudo'`
**Root Cause:**
After PR [1], at [2], `self.env.ref('stock.route_warehouse0_mto', raise_if_not_found=False)` can return `None` if the MTO route is missing. The code then directly calls `.sudo()` on this `None` value, causing an error.
**Fix:**
This commit moves the `.sudo()` call inside the `if route:` block, ensuring it is only executed when the route exists. This prevents errors when the MTO route is deleted and allows users to save settings without an access error.
[1]:
https://github.com/odoo/odoo/pull/221757
[2]:
https://github.com/odoo/odoo/blob/dfb14be8b83e3c48c1b186b0d7d7a66753381c9e/addons/stock/models/res_config_settings.py#L64
sentry-6839993384This 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
Fixes an issue in the website editor where removing a popup or undoing its creation could leave the page unable to scroll. This helps editors continue working normally on longer pages after popup changes.
Original PR description
Following the [html_builder refactoring], commits [1] and [2] removed the functionality that was responsible for toggling the popup's visiblity when we remove it or undo its creation. Steps to see the issue: - Have enough content on the page to be able to scroll it - Start editing and drop the popup - Undo => We can't scroll. The same happens if we just remove the popup. Related to task-4367641 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb [1]: https://github.com/odoo/odoo/commit/a3722219038fff [2]: https://github.com/odoo/odoo/commit/06101974532157c521155a7fbb2179aa85b060db
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 Send & Print wizard now consistently hides the Download option regardless of the user's language settings. This prevents confusion for non-English users and keeps the accounting workflow aligned with the intended behavior.
Original PR description
Since 7ad7a1d976391e81eaa03be7076cc61f4a6cfcbe we don't show Download option in the Send & Print wizard. However, we were checking the tuple `(value, label)` which works only if language is set to English. With this commit, we only check the technical value opw-4965650 Forward-Port-Of: odoo/odoo#221763
This update adjusts automated checks for the eLearning course publishing flow after changes in the website builder. It helps ensure future updates do not accidentally break course publishing for eLearning managers.
Original PR description
This commit adapt the broken test test_course_publisher_elearning_manager after refactoring of the website builder.
This fixes an issue where users editing menus in Studio could not create or edit a client action because the default form view failed to load. The change removes an outdated customization so Odoo can generate the form normally, improving reliability when configuring menus.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224752 Forward-Port-Of: odoo/odoo#224634
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 fix prevents Spain VeriFactu electronic reporting from failing when a company has no tax ID set. Instead of showing an unexpected error, the system now handles the missing value more safely during batch sending checks.
Original PR description
Replaced `['NIF']` with `.get('NIF')` to avoid a `KeyError` when the company does not have a NIF.
When the VAT value is not set on the company and the `_send_as_batch_check` method is executed, the system raises an error from [1].
This PR updates the code to use `.get('NIF')` instead of direct access, making it more robust.
[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/l10n_es_edi_verifactu/models/verifactu_document.py#L1165
**sentry-6829500308**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224982This 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
The email composer now filters templates so users only see templates assigned to them or templates available to everyone. This prevents templates intended for another user from appearing in sales email workflows, reducing confusion and accidental use of the wrong message.
Original PR description
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo…
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo user. 4. Create a quotation and click the 'Send by Email' button. 5. In the wizard, click the three dots between the attachment and AI logo in the footer. 6. Observe the templates list. **Issue:** - The template created for the admin user appears for the demo user as well. **Cause:** https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/mail/static/src/core/web/mail_composer_template_selector.js#L31-L44 - The domain used to fetch templates was incorrectly filtering for templates assigned to any user (instead of filtering for templates assigned to the current user or not assigned at all). **Solution:** - Corrected the domain to include only templates assigned to the current user and not assigned to anyone. opw-4901492 Forward-Port-Of: odoo/odoo#222073 Forward-Port-Of: odoo/odoo#217641
The leave statistics view has been adjusted so information no longer overlaps in the interface. This makes absence and time-off figures easier for HR teams and employees to read and use.
Original PR description
This commit addresses an overlapping styling issue in the leave stats task-4945729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221099
The barcode app now opens the scrap flow correctly for completed manufacturing orders even when there are no by-products. This prevents users from hitting an error screen and keeps warehouse production cleanup tasks moving smoothly.
Original PR description
Issue ----- Trying to scrap a production through the barcode app gives the user a traceback. Steps to reproduce ----- - Have a done MO - Go to barcode and try to scrap it --> Traceback Cause ----- When preparing the context for the scrap window, we try to map the MO's byProducts. When there is no byProduct, we end up trying to apply a mapping on "nothing". ----- Ticket: opw-4792599 Forward-Port-Of: odoo/enterprise#92925 Forward-Port-Of: odoo/enterprise#90623
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 employee form warning shown when wages fall below the legal minimum can no longer be edited. This avoids confusion and helps prevent accidental changes while keeping the warning informational.
Original PR description
When an employee’s wage falls below the minimum, the warning displayed on the employee form appeared with editable fields. This was misleading and could allow accidental changes. task-5051879
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.
The Documents app now recognizes older redirect records when someone opens a shared document content link. This preserves access to existing links and avoids broken document downloads or previews after link changes.
Original PR description
We do not currently check for `documents.redirect` records when accessing the `/documents/content/<access_token>` endpoint. This commit fixes this by redirecting if a `document.redirect` with the appropriate `access_token` was created for backwards compatibility. opw-4517698 Forward-Port-Of: odoo/enterprise#92342 Forward-Port-Of: odoo/enterprise#92313
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
The duplicate transaction search now works even when users leave the Starting Date blank. Instead of showing an error, the system uses today’s date so accounting teams can continue their bank review without interruption.
Original PR description
Currently, an error occurs when attempting to find duplicate transactions in the bank. Steps to Reproduce: - Install the `Accountant` module. - In the `Accounting` Dashboard, click on `Bank`. - In…
Currently, an error occurs when attempting to find duplicate transactions in the bank.
Steps to Reproduce:
- Install the `Accountant` module.
- In the `Accounting` Dashboard, click on `Bank`.
- In Actions, click `Find Duplicate Transactions`.
- Clear the `Starting Date` and click save.
Traceback:
```py
psycopg2.errors.UndefinedFunction: operator does not exist: date >= boolean
LINE 6: AND move.date >= false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
This error occurs when the system attempts to detect duplicate transactions without a `Starting Date`. During the check, it evaluates the condition `move.date >= date_from`. Since `date_from` is False, the comparison triggers an error.
This commit ensures that if the `Starting Date` is empty when finding duplicate transactions, it uses today’s date as the `Starting Date`.
Reference commit: https://github.com/odoo/enterprise/pull/87000/commits/806ab2d56952e9d0f597cf1ab36ea2f180a84323
Forward-Port-Of: odoo/enterprise#92497Rental 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.