Daily updates from Odoo
Thursday, August 14, 2025
31 changes · saas-18.3
Resolved issues and error corrections
This fix makes automated checks for live chat session opening more reliable by skipping an unstable navigation step. It helps prevent false test failures while ensuring live chat sessions still open the correct conversation view.
Original PR description
The `test_session_history_open`, in later versions renamed `test_form_view_embed_thread`, ensures that clicking on a live chat session in the list view opens the thread, not the default form view. To do so, we first access the `/web` url, then open the command palette, and finally find the correct live chat view. However, such tests are known to be non-deterministic as the command palette is not always available at the start of the tour. Several live chat tours have been updated to directly access the view, providing the correct URL to `start_tour`: command palette part of the tour is meaningless. fixes runbot-161482 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 fixes an error that occurred when users duplicated several Point of Sale configurations from the list view at the same time. Businesses can now copy multiple POS setups without interruption, making store setup and administration smoother.
Original PR description
### Steps to reproduce the issue: 1) In the Point of Sale app, when trying to duplicate more than two records from the list view, it gives a singleton error. The implementation was added to the master branch from commit [1]. [1]: https://github.com/odoo/odoo/pull/92664/files#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44R360-R361 opw-4969713 ### Description of the issue/feature this PR addresses: #### Issue Previously, when duplicating more than one pos.config record, it would give a singleton error. #### Solution Added a for loop to iterate over the config records individually. ### Current behavior before PR: https://github.com/user-attachments/assets/ba5a3969-7647-4943-a0b1-12b1961f26cd ### Desired behavior after PR is merged: https://github.com/user-attachments/assets/b952b711-7782-4e9d-b05a-e4019ab79d87 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220452
This fix adjusts when Spanish POS orders can be sent to Veri*Factu, so users can send eligible orders after closing a session while avoiding unsupported registered-order submissions. It also prevents Veri*Factu cancellation of POS orders and directs users to use refunds instead, reducing compliance and accounting errors.
Original PR description
- The "Send Veri*Factu" button is currently also visible for registered orders (but we can not send documents for such orders anyway; we do not support subsanacion) - We do not allow generating Veri\*Factu documents for posted orders. That makes it impossible to (Veri\*Factu) send orders after the session is closed. - We should not allow to Veri*Factu cancel orders. They would still be included in the closing move. The user should create refund instead. task-None Forward-Port-Of: odoo/odoo#222927 Forward-Port-Of: odoo/odoo#222668
This fixes unstable automated checks for website live chat ratings by waiting until the chat message is fully saved before verifying it. It helps prevent false test failures and supports more reliable delivery of live chat functionality.
Original PR description
The website live chat rating tours share common steps, among them, the `start` steps. Those steps check if the first message is not duplicated by: - Waiting for the `.o-mail-Thread` selector. -…
The website live chat rating tours share common steps, among them, the `start` steps. Those steps check if the first message is not duplicated by: - Waiting for the `.o-mail-Thread` selector. - Checking if there is only one message. - Adding a class to this message if that is the case. - Adding a step that looks for the added class. This approach is flawed because: - The thread will be persisted once the first message is sent. If the class is added to the transient message but the next assertion runs after persistence, the message with the class is no longer in the DOM. - The class can be overridden if the message re-renders before the next assertion. - There is no guarantee the message is in the DOM when executing `queryAll`. There is no reliable way to check the state before persistence because the thread may change between "trigger" and "run". This commit updates the assertions to ensure the message is sent correctly and no duplicates exist once the thread is fully persisted. fixes runbot-229822 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 fixes an intermittent automated test failure in Point of Sale where product variants could be selected too quickly before the screen refreshed. The change improves confidence in testing for barcode-based product selection without changing day-to-day user behavior.
Original PR description
This fixes a random runbot failure in the barcode search test involving product variants. The issue was caused by timing problems when selecting a second variant of a product with the same template…
This fixes a random runbot failure in the barcode
search test involving product variants.
The issue was caused by timing problems when selecting a second variant of a product with the same template name. Due to UI delays, the wrong variant could be selected.
The issue happened in this sequence:
- The test searched the first barcode (12341357), which correctly
displayed the product template "Product with Attributes" with the
variant (Value 1, 3, 5, 7) preselected.
- The product was added successfully.
- Then the second barcode (12342468) was searched. But before the UI
had time to update
and reflect the new variant (Value 2, 4, 6, 8), the test clicked
again on the same product template — which still had the *first*
variant preselected.
- As a result, the first variant was added twice, and the expected
second variant was missing.
To prevent this, a distinct product template ("Product without Attributes") was introduced between the two variant searches to give the UI enough time to refresh. The tour was also updated to properly wait for the correct product to appear and to avoid triggering the configurator on products without attributes.
runbot-230339
Forward-Port-Of: odoo/odoo#222631
Forward-Port-Of: odoo/odoo#222335Fixes an issue where loyalty discounts for specific products could disappear after scanning an unrecognized barcode in Point of Sale. This ensures eligible discounts remain correctly applied or can be reapplied, improving checkout reliability for cashiers and customers.
Original PR description
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion…
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion program that grants a discount on a specific product category * Open PoS * Add to the order a product that triggers the discount * Scan an unknown barcode * (Try to reapply the discount) > Observation: The discount disappears and cannot be reapplied Why the fix: ------------ In v18.0, the method used `reward.update(...)` to apply the computed list of discountable products, ensuring proper handling by the reactive OWL model. In v18.2, a direct assignment was used instead, which did not properly set the internal state. When the filtered product list was empty, the resulting structure `[['link']]` became invalid, causing the discount to disappear and preventing it from being reapplied. opw-4923687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222017
This fixes an issue in Point of Sale loyalty rewards where selecting a product with multiple variants did not always automatically add the promised free product. Businesses can now rely on free product promotions applying correctly at checkout, reducing manual corrections and customer confusion.
Original PR description
Before this commit, when using a free product reward on multi products that have several variants, adding the desired product to the order would not always trigger the automatic addition of the free product as expected. opw-4841759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221998 Forward-Port-Of: odoo/odoo#215576
This fixes a validation issue where certain legitimate nested view customizations were incorrectly shown as faulty in the interface. It helps prevent false error warnings for valid customizations, reducing confusion for administrators and developers working with Odoo views.
Original PR description
Have an arch that will move a subchild of a parent effectively replacing the parent ```xml <data> <xpath expr="/form/div/div" position="replace"> <xpath expr="/form/div/div/span" position="move" /> </xpath> </data> ``` Before this commit, the move xpath was marked as faulty in the IrUiView's form in the interface. After this commit, the xpath is not marked as invalid, because it is not. read `@def apply_inheritance_specs` to get a grasp on the supported semantics for xpaths arch. opw-4965869 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
Portal users can now open purchase orders even when an ordered product has no image. The purchase order page skips the missing image instead of showing an error, improving reliability for customers and suppliers using the portal.
Original PR description
In the purchase order portal template (`purchase.purchase_order_portal_content`), `image_data_uri(line.product_id.image_128)` was called without checking if the product had an image, leading to a rendering error when `image_128` is False. Steps to reproduce the bug: - create a product without an image - create a purchase order with that product - partner: portal user (e.g joel) - connect as portal user - go to the purchase order - the portal view will raise an error because it tries to render an image Solution: Added a conditional check to only render the `<img>` tag if the product image exists, preventing template evaluation errors. opw-5013230 Forward-Port-Of: odoo/odoo#222769
This fix improves tax calculations when invoices or orders use down payments, global discounts, manual tax amounts, and multiple currencies. It helps prevent small rounding errors and mismatched tax totals, making accounting results more reliable across sales, purchases, invoicing, and point of sale.
Original PR description
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts…
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. That way, we could also use the manual_tax_amounts for amounts in company's currency. For down payment/global discount, let's handle both currencies instead of only the foreign one. Also, the percentage is applied for each line to keep the whole thing as most accurate and close to the input percentage. If we don't do that, we could end up with a base of 99.99 and a tax amount of 15.01 for a tax of 15%. Since the percentage is applied in a more "global" way, this commits also partially revert https://github.com/odoo/odoo/commit/3a269864534f234127c87ff1567f796904a27d5b This approach is more complex and doesn't give always better results when using round_per_line either. Let's keep it simple and come back to a global approach. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website theme switch loader now shows progress correctly every time a user changes themes. This prevents confusion during repeated theme changes by ensuring the loading indicator restarts properly instead of appearing frozen.
Original PR description
__Current behavior before commit:__ When switching a theme, the website loader is displayed with a progress bar. When the operation is finished, the loader is hidden and the progress bar interval is cleared. However, the variable holding the interval ID is not being reset. If the user switch theme a second time, the `initProgressBar` method doesn't start a new interval because its initial guard finds the old interval ID and exit prematurely. This resulted in the progress bar appearing to be stuck. __Description of the fix:__ This commit fixes the issue by removing the initial guard of the `initProgressBar` method. __Steps to reproduce:__ 1. Open the Website builder 2. Click on the "Theme" tab 3. Click on "Switch Theme" 4. Choose a Theme 5. The loader is progressing 6. Do every steps again 7. The loader is stuck at the beginning Forward-Port-Of: odoo/odoo#218356
This fix allows Odoo's template engine to handle longer expressions correctly when running on newer Python versions. It prevents certain pages or reports from failing due to internal expression-size limits, improving reliability without changing user workflows.
Original PR description
Not entirely clear why it was apparently excluded, but apparently in 3.13 some qweb expressions require the use of `EXTENDED_ARG`. Specifically [1] makes the expression long enough that it needs at least one "long jump" which then requires an `EXTENDED_ARGUMENT`, here's the sizes for the expression in question in various Python versions: - 3.10: 102 bytes - 3.11: 188 bytes - 3.12: 214 bytes - 3.13: 272 bytes Thus it makes sense at at some point the earliest jumps in the expression (and `and`/`or` *are* jumps, since they're short-circuiting) would become "long". These increases in size can be due to a multitude of factors e.g. changes in inline cache details (3.11 and above), jumps becoming strictly typed and requiring `TO_BOOL` instructions (3.13), ... [1]: https://github.com/odoo/odoo/commit/cc68a012649f9eb331265deba3197abaf1700d97#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bL154-R223 Forward-Port-Of: odoo/odoo#222939
The employee work address section now displays the state, city, and zip fields in a consistent horizontal alignment. This small layout fix makes the form easier to scan and helps users enter address details more clearly.
Original PR description
Task ID: 5002920 Description of the issue/feature this PR addresses: Align state, city, and zip fields horizontally on employee form Current behavior before PR: Not alignment in tab Employee > Work address as per fields state, city, and zip Desired behavior after PR is merged: Fields aligned
Purchase orders created from make-to-order sales will no longer be incorrectly treated as dropship orders. This prevents customer addresses from appearing on supplier requests for quotation when the goods are meant to be received normally, reducing confusion for purchasing teams and vendors.
Original PR description
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a…
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a product "Prod" - Select both buy and MTO routes - Add a vendor line - Create a SO for "Prod" - Confirm the SO - Go to the linked PO When printing the RFQ, the address field is that of the customer as if the PO was a dropshipped one Cause ----- 564b909 introduced an override of `_compute_dest_address_id` to update the delivery address of dropshipped purchases upon change of the SOL's `partner_shipping_id`. The problem is that the field having a value means it is a dropshipped purchase https://github.com/odoo/odoo/blob/35be5c9edf637fb813025f6817c16a9f50475fa8/addons/purchase/models/purchase_order.py#L89-L91 However, here, the value is set as long as the PO is linked to a SO, even if there was none to begin with. We can make sure that the field was already set via the vals when creating the PO, and that we just want to update it because the depends triggered the compute. ----- Ticket: opw-4925962
This fix updates the Time Off test setup so it archives existing leave types instead of deleting them when demo data is present. This prevents automated nightly builds from failing due to existing linked leave records, improving confidence in test results without changing user-facing behavior.
Original PR description
### Root cause: - We were using .unlink() before, but it throws error if a hr.leave.type is linked with any hr.leave. ### Fix: - Instead of unlink we will archive the record task: 4925370 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employees can no longer create time off requests through a shortcut when the time off type requires an approved allocation. This keeps the shortcut behavior aligned with the standard request flow and prevents accidental overuse of leave balances.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves. - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221022 Forward-Port-Of: odoo/odoo#208214
This fixes an automated test for employee time-off accruals by ensuring all date-sensitive checks run against a fixed date. It helps prevent false test failures caused by the current calendar date, improving release reliability without changing user-facing behavior.
Original PR description
Given that accrual plans are related to dates, all the testcase logic has to be inside 'with freezetime' to avoid date related errors Runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/230722 Forward-Port-Of: odoo/odoo#222854
This fix ensures simulated time settings used in testing are applied only to the selected database. It prevents unintended effects on related databases, such as logging databases, making test behavior more reliable and safer.
Original PR description
Filtering the postgres database was not enough, the log_db was also affected. Since only the order was impacted, this was creating strange side effect in databases like the log-db where it was only modified when the function exists. Checking the -d is more reliable and safer to avoid any side effect when testing with faketime. Forward-Port-Of: odoo/odoo#222805
Point of Sale now recognizes the exact product variant when a barcode is typed into the search bar, so staff no longer need to manually choose attribute values for matching products. This reduces checkout friction and speeds up sales for items whose barcodes must be entered manually.
Original PR description
Before this commit, when a user manually entered a product barcode in the search bar, and the product had multiple attributes and values, the configuration popup required the user to manually select the correct attribute values—even though the barcode uniquely identified the product variant. This slowed down the selling process and caused unnecessary friction. With this commit, when a product is found via its barcode (including manual entry), the configuration popup is automatically preset to the correct attribute values associated with that barcode. This improves the user experience and speeds up sales, especially for products whose barcodes cannot be scanned and must be entered manually. opw-4635497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220609 Forward-Port-Of: odoo/odoo#207086
This change adjusts an automated test for public discussion channels so it no longer depends on a page reload that caused inconsistent failures. It helps keep quality checks stable without changing the experience for end users.
Original PR description
This test suspiciously fails in various ways in all versions before the following PR: https://github.com/odoo/odoo/pull/214358 This seems to indicate an issue with the page reload. Properly wait for the page to reload before proceeding with the next steps in the tour, hoping it will resolve all the related issues. https://runbot.odoo.com/odoo/error/111051 https://runbot.odoo.com/odoo/error/223165 https://runbot.odoo.com/odoo/error/227755 https://runbot.odoo.com/odoo/error/227756 https://runbot.odoo.com/odoo/error/227757 https://runbot.odoo.com/odoo/error/227758 https://runbot.odoo.com/odoo/error/229657 https://runbot.odoo.com/odoo/error/229724 https://runbot.odoo.com/odoo/error/229745 https://runbot.odoo.com/odoo/error/229817 https://runbot.odoo.com/odoo/error/230901 Forward-Port-Of: odoo/odoo#222876 Forward-Port-Of: odoo/odoo#222825
This fix makes an internal automated test for bus notifications run consistently by ensuring the test setup is ready before notifications are triggered. It helps reduce false test failures in the development pipeline without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the main thread doesn't wait for the selector to be register before triggering the postcommit hook. This commit ensures the test waits for the selector to register the database connection before going further. runbot-77470 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#222810
This fix prevents search suggestions from interrupting Chinese, Japanese, and other composed text input on iPhones and iPads. Users can now select characters from their keyboard suggestions without the text disappearing, making Odoo usable for these languages on iOS.
Original PR description
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes…
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes it impossible for users to input text in these languages on iOS devices (iPhone/iPad). This regression was introduced between versions 18.0 and 18.2 when the search bar was modified to automatically open the suggestion dropdown during typing. Purpose: This commit fixes the IME input issue by preventing the suggestion dropdown from opening while the user is composing text with an IME. Opening the dropdown during IME composition disrupts the input process on iOS Safari, causing the composed text to disappear. The fix ensures that the dropdown only opens after IME composition is complete, allowing Chinese, Japanese, and other IME-based language users to properly input text on iOS devices. Steps to Reproduce on Runbot: 1. Access Odoo instance (version 18.2) on an iOS device (iPhone or iPad) 2. Switch keyboard to Chinese (Pinyin) or Japanese (Romaji) input method 3. Click on the search bar in any view (e.g., Customers, Sales Orders) 4. Type characters that require IME conversion: -For Chinese: type "ni" (for 你) -For Japanese: type "ka" (for か) 5. When the IME suggestion appears, press Enter or tap the suggested character 6. Bug: The text vanishes instead of being inserted into the search field Current behavior before PR: The character disappears immediately after selection Desired behavior after PR is merged: The selected character should be inserted into the search field Notes: -This issue only affects iOS devices (Safari/WebKit) due to how they handle DOM manipulation during IME composition events -The issue does not occur on Android devices or desktop browsers -The fix checks the `isComposing` property of the input event to avoid opening the dropdown during IME composition -No test added as IME input behavior is difficult to simulate in automated tests 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#222151
Surveys using randomized selection now shuffle questions even when all questions in a section are shown, removing an inconsistent ordering behavior. The change also allows section order to be randomized, giving survey creators more flexibility and reducing order bias in responses.
Original PR description
1/ When using Question Selection "Randomize per section", and a small number of questions is chosen, the order in which questions are shown is random. If, however, we choose to show all questions of the section (choose N of N), the order is not random, which is inconsistent, especially as setting `random_questions_count=0` can already be used to show them all in order. 2/ It was possible to randomize questions order per section but not sections order. It doesn't cost much and it's useful from saas-18.3. Task-4962940
Updates internal mail tests so they wait properly for background responses before checking results. This reduces false failures in automated checks, helping keep releases moving without affecting end users.
Original PR description
These tests were failing due to `expect.verifySteps()` being empty rather than the RPC response. The rpc response is asynchronous and awaiting the click doesn't necessarily mean the RPC had time to effectively happen, especially when runbot CPU load is high. Fixes runbot-error-160954 Forward-Port-Of: odoo/odoo#222839
The German EC Sales List CSV export now includes the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps German businesses submit their VAT-related reporting without manual file corrections.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314 Forward-Port-Of: odoo/enterprise#92110
French tax reports now compare totals using proper rounding instead of exact decimal matching. This prevents reports from incorrectly flagging matching amounts as different because of hidden decimal precision differences.
Original PR description
Currently, the code was checking for a strict equality between two sums. However, it may happen that there are many decimals that aren't displayed on the UI, hence the strict equality check fails. For instance `30201.63 != 30201.629999999997`. Instead, we now use the `float_compare` which takes care of rounding issues. opw-5000147 Forward-Port-Of: odoo/enterprise#92356
The General Ledger report no longer crashes when users apply the Account Types filter and expand an account. This improves reliability for finance teams reviewing payable and receivable activity.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411
Forward-Port-Of: odoo/enterprise#87431Employees can no longer create time off requests through a shortcut when the time off type requires an approved allocation. This closes a loophole so leave balances and company policies are enforced consistently across the Time Off app.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 Forward-Port-Of: odoo/enterprise#91257 Forward-Port-Of: odoo/enterprise#89975
This fix updates an internal subscription test so it no longer depends on the calendar year in which it runs. It helps keep automated quality checks reliable across time, reducing false failures without changing customer-facing behavior.
Original PR description
Before this commit, when test_uninvoiced_upsell_close_log was launched in a year different than 2025, it would fail with the following error: ``` File…
Before this commit, when test_uninvoiced_upsell_close_log was launched in a year different than 2025, it would fail with the following error:
```
File "/data/build/enterprise/sale_subscription/tests/test_sale_subscription.py", line 2085, in test_uninvoiced_upsell_close_log
action = subscription.prepare_upsell_order()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1042, in prepare_upsell_order
action = self._prepare_renew_upsell_order('7_upsell', upsell_msg_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1012, in _prepare_renew_upsell_order
order = self._create_renew_upsell_order(subscription_state, message_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/test_sale_subscription/models/sale_order.py", line 228, in _create_renew_upsell_order
order = super()._create_renew_upsell_order(subscription_state, message_body)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 998, in _create_renew_upsell_order
values = self._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/project_sale_subscription/models/sale_order.py", line 40, in _prepare_upsell_renew_order_values
res = super()._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/partner_commission/models/sale_order.py", line 72, in _prepare_upsell_renew_order_values
values = super()._prepare_upsell_renew_order_values(subscription_state)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/models/sale_order.py", line 1182, in _prepare_upsell_renew_order_values
raise UserError(_('You cannot create an upsell for this subscription because it :\n'
odoo.exceptions.UserError: You cannot create an upsell for this subscription because it :
- Has not started yet.
- Has no invoiced period in the future.
```
runbot-task-230716
Forward-Port-Of: odoo/enterprise#92307This fix prevents users from selecting bank reconciliation widget models in places where they cannot work correctly, such as model selectors in Knowledge properties. It avoids errors and tracebacks when those non-stored internal models are used by features that expect regular database-backed records.
Original PR description
To reproduce this issue, just try to perform a name_search/search_count/etc.. on `BankRecWidget` for example: - Example of Steps in Knowledge: - Open knowledge - Create an article - Create another article in the first one (child) - Add a properties - Select `Bank reconciliation widget` in Model - Traceback `BankRecWidget` and `BankRecWidgetLine` use ```py _auto = False _table_query = "0” ``` to avoid being stored in db. This kind of model doesn't work with several methods of the model api, such as `search_count`, `name_search` etc... This commit will add a models blacklist via ir_model._is_valid_for_model_selector opw-4763713 Forward-Port-Of: odoo/enterprise#90060 Forward-Port-Of: odoo/enterprise#88352
Fixed an issue where Mexico POS orders paid with eWallet could show a tiny negative balance because of rounding in tax calculations. The system now treats these negligible differences as zero, allowing customers to continue to the payment screen as expected.
Original PR description
Before this commit, paying an order with eWallet could result in a small negative residual amount (due to tax calculation), instead of zero. This prevented users from proceeding to the payment screen. With this commit, the "lt" function is used to compare amounts while taking rounding precision into account, ensuring the residual is treated as zero when appropriate. opw-4867365 Forward-Port-Of: odoo/enterprise#88275