Tuesday, September 9, 2025
9 changes · master
Resolved issues and error corrections
Fixes an issue in Data Cleaning where the discard button in deduplication rules would reload the page without removing the selected record. Users can now reliably discard duplicate candidates after a recent system change altered how related record data is handled.
Original PR description
…efactor. Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature. Steps to replicate: - Go to: Data Cleaning > Configuration >…
…efactor. Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature. Steps to replicate: - Go to: Data Cleaning > Configuration > Deduplication. - Open any Deduplication Rules > Deduplicate > select any record or directly click on the discard button. (Make sure at least one record is available in list view.) - Click `discard` on top left. Issue: `It will load the page but not discard the record.` This is not work because of a recent [refactor](https://github.com/odoo/odoo/pull/205486) where the data of a `many2one` will be an object rather than an array. (task-[3547961](https://www.odoo.com/odoo/project/49/tasks/3547961)) The discard button in the deduplication feature was not working correctly after a recent refactor in Odoo SaaS version 18.4. Previously (in SaaS 18.3), the record.data.group_id many2one field was represented as an array. The discard logic was written to access the group ID as record.data.group_id. After the refactor, the record.data.group_id field is now represented as an object. Thus, record.data.group_id became undefined, which made parseInt() return NaN. Because of this, the application failed to identify the correct group and records to discard, causing the discard action to silently fail and only reload the page without discarding any records. `The issue is also occurring in the runbot.` Summary: This change ensures that the discard button correctly identifies the group and record IDs to discard records. The lines that returns object is [this](https://github.com/odoo/odoo/blob/564348a5172ea98b38c903686c21d007d0e57b48/addons/web/static/src/model/relational_model/utils.js#L517-L523). cause of code : https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/static/src/views/data_merge_list_view.js#L67 reference pr:- https://github.com/odoo/enterprise/pull/90157 **saas~18.4** <img width="1914" height="564" alt="image" src="https://github.com/user-attachments/assets/d8079d6b-abad-4367-b9d5-9055ee4f8cfa" /> **saas~18.3** <img width="1907" height="545" alt="image" src="https://github.com/user-attachments/assets/8add0c64-a6ce-40bd-9df9-ca5de5ab9ac8" /> OPW:- [5043092](https://www.odoo.com/odoo/project/70/tasks/5043092) UPG:- [3116896](https://upgrade.odoo.com/odoo/upgrade.request/3116896) Forward-Port-Of: odoo/enterprise#93606
This fixes an issue where payroll processing could fail when a contract was missing from an employee version. The Contract button now opens the correct employee version, helping payroll users review the right information without unexpected errors.
Original PR description
Problem ---------- The warning message compares the contract_date_start of the version with the date_from of the payslip. So if no contract is defined on the versions, it raises the traceback Solution ---------- Remove this warning message it is useless we only want to know if a contract exists for the version associated with the payslip. Fix the "Contract" Button to open the employee form view with the good version. task-5067543
When an employee signs a newer contract, the previous contract is now automatically ended the day before the new one starts. This keeps employee contract records accurate and helps avoid confusion in payroll and HR processes.
Original PR description
When a newer contract for employee is double signed, the older version is closed. However, the 'contract_end_date' for the old version is not automatically updated. The logic has been adjusted to end old contract date the day before the new contract's start date. Forward-Port-Of: odoo/enterprise#93236
This fixes an error that could occur when opening or generating the Indian TDS/TCS Excel report after a related data field was renamed. Users can now generate the spreadsheet without encountering a traceback, improving reliability for tax reporting workflows.
Original PR description
With this commit: https://github.com/odoo/odoo/commit/f6d6659f8bf9ab7c7409f584524c7509865a7a45 the `l10n_in_pan` field was removed and replaced with the `l10n_in_pan_entity_id` field, which relates to the `l10n_in.pan.entity` model. However, the fix introduced in that commit wasn’t updated accordingly when the field name changed. With this PR, the field will now be set correctly, and the traceback will no longer occur when generating the TDS/TCS Excel sheet.
A recent change accidentally removed the special layouts used by the payment follow-up report and the Spanish VAT books report. This fix restores those tailored templates so users see the reports in the expected format again.
Original PR description
During a [recent refactoring][1], the follow-up report and Spanish VAT books report lost their custom templates. This commit restores them. [1]: https://github.com/odoo/enterprise/commit/162d2326b2bd4e78aa742ae7bdd125150faf3e08
The VoIP softphone on mobile now avoids reopening the device keyboard every time a keypad button is pressed. This makes dialing numbers smoother while still letting users open the keyboard manually by tapping the input field when needed.
Original PR description
**Purpose:** When using the softphone keypad on mobile, pressing any key would automatically trigger the native keyboard, creating a frustrating user experience and making it tedious to dial numbers. **Specification:** Adjusted the behavior so that: -The keyboard drawer still appears the first time the VoIP widget is opened. -However, subsequent key presses on the softphone keypad no longer trigger the native keyboard. -If the user wants to bring up the native keyboard (e.g., to enter letters), they can explicitly tap the top input field. **Task**-4964776
Canadian CPA005 payment files now use a unique batch payment name instead of a blank or repeated payment reference. This prevents rejections from banks such as CIBC and RBC when processing batch payments.
Original PR description
**CPA0005 Alphanumeric Originator's Cross Reference No is blank on non-unique** Impacted versions: - 17.2 - 17.3 - 17.4 - 18.0 - 18.1 - 18.2 - 18.3 - 18.4 - master Steps to reproduce: 1. create a new batch payment 2. create cpa005 payment file 3. rejected by CIBC and RBC Current behavior: - Uses payment_reference which is blank or non-unique - Causes bank to reject on non-unique status Expected behavior: - To have every batch payment reference (name of payment) be unique through the batch
Canadian CPA005 payment files now use a unique batch payment reference instead of a blank or duplicated payment reference. This helps prevent banks such as CIBC and RBC from rejecting batch payment files due to non-unique originator cross-reference numbers.
Original PR description
CPA0005 Alphanumeric Originator's Cross Reference No is blank on non-unique Impacted versions: 17.2 17.3 17.4 18.0 18.1 18.2 18.3 18.4 master Steps to reproduce: create a new batch payment create cpa005 payment file rejected by CIBC and RBC Current behavior: Uses payment_reference which is blank or non-unique Causes bank to reject on non-unique status Expected behavior: To have every batch payment reference (name of payment) be unique through the batch
Overdue invoice follow-up emails will no longer be sent again every day for the same invoice once the final reminder level has already been applied. This prevents customers from receiving duplicate reminders and helps keep automated collections communication accurate.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Invoicing / Follow-up Levels" - Create a unique follow-up level: * Remind 1 day after due date * Send Email:…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Invoicing / Follow-up Levels" - Create a unique follow-up level: * Remind 1 day after due date * Send Email: [checked] * Automatic: [checked] - Create an invoice: * Customer: [any] * Invoice Date: [1 month ago] * Due Date: [1 month ago] * Invoice Lines: [any] - Confirm the invoice - Go to "Settings / Technical / Automation / Scheduled Actions" - Open "Account Report Followup; Execute followup" - Run it manually => A reminder is correctly sent to customer (i.e. message on partner record) - Wait for the following day - Run the scheduled action again **Issue:** The same reminder in sent again. The last reminder will be sent every day even if there is no new invoice. **Cause:** When computing the follow-up status for a contact, all the entries that are due are taken into account. The entries that have already been included in a follow-up should be ignored when computing the same follow-up again. **Solution:** A field on a journal item (i.e. followup_line_id) tracks in which follow-up level the item has been included. We can exclude the journal items that has this field set to the next follow-up level. opw-4964103 Forward-Port-Of: odoo/enterprise#94026 Forward-Port-Of: odoo/enterprise#92191