Wednesday, August 13, 2025
14 changes · saas-18.3
Resolved issues and error corrections
This fixes a mismatch in Portuguese vendor bills when a user manually adjusts a tax amount. Tax totals now stay aligned with the accounting entries, reducing confusion and helping invoices reflect the correct untaxed amount.
Original PR description
Create a vendor bill with a base of 123 and 23% tax. => untaxed_amount = 123 & amount_tax = 28.29 Edit the tax amount to be 28.30 => The tax totals shows an untaxed_amount of 122.99 but the accounting entries say 123.0 This is because during the rounding, since the tax computation is custom in Portugal, we subtract the tax amount from the total amount to get the expected base amount. Since the total is not updated according the tax lines, the base amount takes the difference instead of the total. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220635
This fix prevents an unrelated payment provider card selector from appearing when a POS payment method is configured for online payments. It keeps the setup form clearer and reduces the chance of choosing an incompatible payment option.
Original PR description
Before this commit, when the `is_online_payment` field was set to `True` the widget `pos_payment_provider_cards` was not properly hidden in the form view of the POS payment method. This commit ensures that the widget is correctly hidden when the field is set to `True` by resetting the `payment_method_type` to 'none'. Thanks to @elierwclik for the report and initial PR #222142 Forward-Port-Of: odoo/odoo#222356
This fix prevents confusing system errors when a document numbering format contains an invalid placeholder. Users will now receive a clear warning so they can correct the sequence setup without disrupting document creation unexpectedly.
Original PR description
Currently, an error is raised when a sequence is generated with an invalid legend in the prefix or suffix. **Steps to reproduce:** - Install Sales module. - Update the sale order sequence prefix to S%(days)s. - Create a new sale order. **Error:** `KeyError - 'days'` **Cause:** An error occurs when the user provides an invalid suffix in `ir_sequence` and the system tries to generate that sequence at [1]. [1] - https://github.com/odoo/odoo/blob/18da9b6dfc9dc376700cd948a09ae201bf897990/odoo/addons/base/models/ir_sequence.py#L235-L236 **Fix:** To resolve the issue, raise a user error for an invalid sequence. **Ref:** https://github.com/odoo/odoo/commit/18cac1caa21149d70009aa50f3e90dfbc18456a3 Sentry - 6684586181 Forward-Port-Of: odoo/odoo#222527 Forward-Port-Of: odoo/odoo#217142
Leave requests can now be validated for employees who do not have a fixed working schedule. The system uses the employee resource timezone as a fallback, preventing errors and keeping time off approvals running smoothly.
Original PR description
Currently, if we try to validate a leave for a fully flexible employee (employee without a working schedule), we get a traceback when fetching the timezone from the working schedule. To rectify this issue, we default to the timezone of the resource. opw-4979974 Forward-Port-Of: odoo/odoo#222634
This fix prevents upgrade failures when one module changes a field to be company-specific and another module is updated later. It helps keep database upgrades reliable and reduces the risk of interruptions during module maintenance.
Original PR description
before this commit: if module_A has a field ``company_dependent=False`` and module_B override it to ``company_dependent=True`` When -u module_A, there would be an error since ORM tries to convert column type of the field from varchar/integer/boolean... to jsonb This commit will add a patch to the field in the ORM registry if the field was company dependent before upgrade. 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#222701 Forward-Port-Of: odoo/odoo#220983
This fix prevents an error when users press Enter while chat group search results are still loading. It improves reliability for users on slower networks by avoiding a crash during normal chat selection.
Original PR description
Description of the issue/feature this PR addresses: --- **Reason for PR** When a user searches for a chat group, if the network is slow and the search results have not yet been loaded, pressing **Enter** will cause the system to attempt to access the `unselectable` property of an `option` variable that is not yet initialized. This leads to the following error: ``` Uncaught Javascript Error: undefined is not an object (evaluating 'option.unselectable') ``` This PR adds handling to prevent the error when data has not been fully loaded. --- Current behavior before PR: https://github.com/user-attachments/assets/de3964c7-ff83-4f94-bc1a-cb8e09bfb62f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222576
The contact geolocation action now handles unnamed sub-contacts without crashing. Users will see a normal no-match message instead of an error, making address lookup more reliable when contact records are incomplete.
Original PR description
<b>Steps to reproduce:</b> 1. Install base_geolocalize and Contacts > Go to Contacts. 2. Create a new contact or select an existing one (Individual). 3. Go to Contacts & Addresses > Add, leave all…
<b>Steps to reproduce:</b>
1. Install base_geolocalize and Contacts > Go to Contacts.
2. Create a new contact or select an existing one (Individual).
3. Go to Contacts & Addresses > Add, leave all fields empty, then Save & Close.
4. Open the newly created sub-contact > Partner Assignment > Geolocation
5. Click "Compute based on address".
<b>Issue:</b>
- Traceback is raised during geolocation computation if the sub-contact has no name Instead of Displaying.
<b>Cause:</b>
- If a partner does not have a name, the value is False.
- The join() operation results in a TypeError because False cannot be concatenated with strings.
<b>Problematic line:</b>
`'message': _('No match found for %(partner_names)s address(es).', partner_names=', '.join(partners_not_geo_localized.mapped('name')))`
<b>Solution:</b>
- Replaced `name` with `display_name` to ensure all elements passed to`join()` are strings.
This also improves readability in the UI when identifying partners without proper names.
opw-4930258
Forward-Port-Of: odoo/odoo#222317
Forward-Port-Of: odoo/odoo#218292This fix ensures Point of Sale loyalty rewards correctly recognize price list settings when applying reward conditions. It prevents loyalty options from being missed during sales or refunds, helping keep customer rewards consistent.
Original PR description
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070) Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672) --- ## Error FAILED: [12/46] Tour…
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070)
Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672)
---
## Error
FAILED: [12/46] Tour test_refund_does_not_decrease_points → Step selection popup has '$ 1 per point on your order' (trigger: .selection-item:contains("$ 1 per point on your order")).
## Qualifiers
{
"module": "pos_loyalty",
"test_path": "/pos_loyalty/tests/test_frontend.py",
"tour_name": "test_refund_does_not_decrease_points",
"tour_step": ".selection-item:contains(\"$ 1 per point on your order\")",
"test_class": "TestUi",
"test_method": "test_refund_does_not_decrease_points",
"test_module": "pos_loyalty"
}
## Fix
In some cases, the POS config's `pricelist_id` was not available in the frontend, causing loyalty program conditions to be skipped when checking for a matching pricelist.
By explicitly setting `use_pricelist` to True on the POS config, we ensure that `config.pricelist_id` is properly loaded and available at runtime, allowing loyalty programs with pricelist conditions to behave as expected.This fix prevents an error when users group Cash Flow report data by account code. It helps ensure financial reports remain usable even when account line data includes a custom account code field.
Original PR description
The term used by GROUP BY should be the same term in the SELECT, avoiding the posible error like: ERROR: column "account_move_line__account_id.code_store" must appear in the GROUP BY clause or be used in an aggregate function That appears when a column named account_code is created for the model account_move_line. opw-4963180 Forward-Port-Of: odoo/enterprise#91915
This update ensures Point of Sale totals in Mexican electronic invoicing are rounded using the currency's correct precision. It prevents valid fully discounted orders from being blocked by a validation error caused by tiny rounding differences.
Original PR description
Issue: With specific prices and discounts, we can get an rounding issue that does not pass the Validation Error. Purpose of this PR: To round the amount total based on the currency's rounding precision to pass the check. Steps to Reproduce on Runbot: install pos, l10n_mx create products prices with 75.00 and 60.00 respectively. create discount 100% on order change decimal accuracy to 3, change tax to Include with Price create PoS order with products and apply discount receive ValidationError even though the amount total should be rounded to 0.0. opw-4944830 Forward-Port-Of: odoo/enterprise#92141
The default Swiss payroll setting for the contractual 13th month payment rate has been adjusted from 8.33% to 8.3333%. This improves payroll calculation accuracy for Swiss employment contracts and helps reduce rounding differences.
Original PR description
-changed the default contractual thirteen month rate for Switzerland from 8.33 to 8.3333 Forward-Port-Of: odoo/enterprise#92129 Forward-Port-Of: odoo/enterprise#92095
The Argentina electronic invoicing test setup now stops after a limited number of failed connection attempts instead of retrying indefinitely. This reduces wasted time and lowers the risk of external services blocking repeated automated test requests.
Original PR description
In 18.0 and above test hasn't worked in months, half the time it fails because pretty much nothing works in it and half the time it's because it keeps looping on trying to set up the connection and failing (possibly because we're getting blacklisted due to how much spamming we do). For now restrict to just trying 5 times (per class since it's called from a `setUpClass`) with an exponential backoff. This may yet end up in removing the entire test directory as it doesn't seem like anyone cares. Forward-Port-Of: odoo/enterprise#92226 Forward-Port-Of: odoo/enterprise#92207
This fix ensures subscription effective dates set during order processing are properly saved to the database. It prevents cases where the date could appear set internally but not be persisted, improving reliability for subscription records.
Original PR description
Since https://github.com/odoo/enterprise/commit/ff8e55ed83d4905584b7ea10b60ded0d7afbd0cf setting the effective date is done in a precommit hook. Problem, the precommit don't automatically flush. The value set in the cache may be never reflected in the database. Solution: Explicitly flush in the precommit hook
Fixed an issue where exporting the Journal Audit report to PDF could fail when filtering by receivable or payable account types. This ensures finance teams can generate audit PDFs reliably with those filters enabled.
Original PR description
- In the Journal Audit report options, set the Account Type (filter_account_type) to either receivable, payable, or both. - Attempt to export the PDF of the Journal Audit report. A traceback occurs because, in _generate_document_data_for_export, we attempt to add a join using an alias. However, if the filter_account_type option is enabled, there is already a left join in the query with the same alias: account_move_line__account_id. opw-4926547 Forward-Port-Of: odoo/enterprise#91683