Daily updates from Odoo
Saturday, August 23, 2025
5 changes · saas-18.4
Resolved issues and error corrections
Invoices can no longer be saved with a zero or negative currency rate, preventing crashes when working with multiple currencies. The system now validates the rate and uses a safe default when needed, helping users complete invoice updates reliably.
Original PR description
Currently, an error occurs when a user tries to save an invoice with a currency rate of 0. Steps to reproduce: - Install `Invoicing` and enable at least 2 currencies. - Open an Invoice and change…
Currently, an error occurs when a user tries to save an invoice with a currency rate of 0. Steps to reproduce: - Install `Invoicing` and enable at least 2 currencies. - Open an Invoice and change currency to something other than USD. - Now change the currency rate displayed to 0 and save. Error: `ZeroDivisionError: float division by zero` Cause: - Error occurs due to a recent [feature](https://github.com/odoo/odoo/pull/214308) that allows changing currency rate. - Error occurred because the user set the currency rate to `0`, and line [1] attempted a division by zero, resulting in the error. Solution: - Added a constraint that restricts the currency rate and raise validation. - Added a default value for the currency rate in cases where the rate might be 0. [1]: https://github.com/odoo/odoo/blob/698e71b3a5b35fec5c7a27f2487df0e368c541b3/addons/account/models/account_move_line.py#L1505 sentry-6762861372,6787738443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220833
This update prevents warning messages caused by newer Python documentation libraries while keeping compatibility with older versions. It is a low-risk internal fix that helps keep Odoo stable across supported environments.
Original PR description
Odoo 17.0 supports Python ≥3.11, which installs docutils==0.20.1. This version deprecates `Node.traverse()` in favor of `Node.findall()`. To avoid deprecation warnings and ensure compatibility with both docutils 0.17 and 0.20.1, this patch uses `findall()` if available and falls back to `traverse()` otherwise. This change is backward-compatible and safe to cherry-pick to >= 18.0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222000
Fixed an issue that could block users from creating payslips for employees in the Mexico payroll module. The system now uses a reliable fallback date when payroll contract dates are missing, preventing an error and preserving the expected payslip workflow.
Original PR description
Currently, an error occurs when creating a payslip for an employee. Steps to Reproduce: - Install the `l10n_mx_hr_payroll` module with demo data.. - Switch to the `Mexico` company. - Go to…
Currently, an error occurs when creating a payslip for an employee. Steps to Reproduce: - Install the `l10n_mx_hr_payroll` module with demo data.. - Switch to the `Mexico` company. - Go to `Employees` and create an employee. - Click the `Payslips` button under the employee form. `TypeError: '>' not supported between instances of 'bool' and 'datetime.date'` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/780a242b20932f808639f2719a9337d63ca6b13e#diff-e7b04636c3505b4f658eef73da77ef7dbd064ce663fdcfb76ed81e47246acc9d), which replaces the use of the date_start and date_end fields with contract_date_start and contract_date_end, since date_start and date_end are deprecated. When accessing the version, the _compute_dates method runs and sets date_start[1] to the version’s date if the version does not have a contract_start_date. Before this commit, it always retrieved the version’s date_start, which was handled safely. However, after this commit, it retrieves contract_start_date instead of date_start, which is not a required field and can be empty. As a result, when user tries to create a payslip, it raises the error [2]. This commit ensures that if the version does not have a contract_start_date, then while computing the payslip amount it uses the version’s date_version, which is a required field, thereby maintaining the same flow as in previous versions. [1]- https://github.com/odoo/odoo/blob/2054a54a66d6291ab37fa79f749a805138ada1c0/addons/hr/models/hr_version.py#L517-L521 [2]- https://github.com/odoo/enterprise/blob/f1c2326137fd3a94d37e2bbf09b175a9c742f46b/l10n_mx_hr_payroll/models/hr_payslip_worked_days.py#L21 sentry-6818787136
Portal users can now group their helpdesk tickets by customer without seeing an access error. This improves the self-service ticket experience for invited customers while keeping existing access limits in place.
Original PR description
**Issue:**
When logged in as a portal user, grouping tickets by 'Customer' raises an
access error, as portal user can only read partner records if:
```
[('id', 'child_of', user.commercial_partner_id.id)]
```
As defined in rule here:
https://github.com/odoo/odoo/blob/68a156030c366fbbf6b0841e1e2688a571355bf2/odoo/addons/base/security/base_security.xml#L22-L30
**Steps to reproduce:**
- Navigate a helpdesk team and set tickets to be visible to Invited portal
users and all internal users.
- Add a portal user as a follower to one of the team's tickets.
- Log in as the portal user, navigate to Tickets, and group by Customer.
An access error is raised
opw-4969684
Forward-Port-Of: odoo/enterprise#92985
Forward-Port-Of: odoo/enterprise#92603Bank reconciliation now avoids mistaking foreign exchange fees for partial payments when payments involve accounts in different currencies. Matching is stricter, reducing incorrect reconciliations and helping finance teams process bank fees and invoices more accurately.
Original PR description
In case of foreign payment using a bank account in another currency, banks can reflect the foreign currency exchange fee on another bank account belonging to the company and in its main currency. Fr…
In case of foreign payment using a bank account in another currency, banks can reflect the foreign currency exchange fee on another bank account belonging to the company and in its main currency.
Fr example: in a EUR company having in the same bank (e.g ING) both an USD and a EUR account, making a payment using the USD bank account gets you effectively 2 bank transactions while you initiated only one:
- the payment in the USD account and
- the currency diff fee in the EUR account.
In this particular use case, the communication on the currency diff fee reflects the one from the payment and, depending on the reconciliation order, that currency diff could be taken as a partial payment
because we were matching on the words in payment_ref regardless of the currency used, while it shouldn't and must be processed as a bank fee.
The outstanging payments are now only matched when the account.payment memo and the statement line payment_ref exactly match, and if the journal is the same. The algorithm for invoices matching doesn't change except we explictly remove the outstanding accounts from the list of reconcilable accounts to search on.
Previously, a match between an invoice ref and a transaction payment_ref could occure even if the matching word wasn't complete.
E.g: invoice ref: INV/2025/01/10
transaction payment_ref: INV/2025/01/100
To be sure this isn't the case anymore, we check that the matching words are properly surrounded by a "finishing character".
task-5023163
Forward-Port-Of: odoo/enterprise#92950