Daily updates from Odoo
Monday, June 30, 2025
13 changes · 18.0
Enhancements to existing features
When registering SEPA Direct Debit payments, users now see a clear banner if any selected customer lacks a valid SEPA mandate. The banner lists the affected partner names, helping staff quickly identify who needs a mandate before continuing.
Original PR description
When users try to register one or multiple payments with 'SEPA Direct Debit' method, and one or more partners don't have a valid SEPA mandate, a banner alerts the user and mention the names of the concerned partners. This makes it easier for the user because he directly sees the partners for which he has to set a SEPA mandate. task-4575537 runbot : https://runbot.odoo.com/runbot/bundle/18-0-sepa-missing-links-roto-353391
The Documents service now avoids waiting on unnecessary permission checks during early loading, especially in environments where Documents is enabled but not actively opened. This should reduce background delays and improve responsiveness across affected Odoo settings without changing user-facing functionality.
Original PR description
As the Documents service is loaded early in many settings (odoo.com) even when not opening the Documents application, we see that we are `awaiting` too many calls to get user groups. We can do two things to alleviate this: 1. Avoid blocking calls when not necessary 2. Fetch multiple groups in one call even if it doesn't populate the `user` `groupCache` with Documents groups, as reading for these values goes through the service. Note: Refactoring for style only in the constructor. Task-4836624
Resolved issues and error corrections
New Argentine companies will now start with the more commonly used Responsable Inscripto chart of accounts instead of the less common Monotributista option. This reduces incorrect default accounting setup for most Argentine businesses and aligns automatic setup with typical usage.
Original PR description
### Description of the issue/feature this PR addresses: Odoo will try to auto install a Coa when creating a database or creating a new company where country is defined The problem is that in Argentina we have different CoA depending on the AFIP Responsibility, and the one that is currently installed by default is the 'ar_base' (Responsable Monotributista): the less used one. In this case we prefer to do not install any CoA and let the user to install it manually (as it was working in older versions, but it is not possible). For that reason we made this change force to install 'ar_ri' (Responsable Inscripto) CoA by default instead ### Current behavior before PR: 1. Create a new company with country AR 2. Will automatically install the "Responsable Monotributista" Coa ### Desired behavior after PR is merged: Now will install the "Responsable Inscripto" Coa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi and GCC invoice reports now show the regular invoice date separately from the Saudi confirmation date, reducing confusion for backdated invoices. The issue date is also consistently shown using Saudi Arabia time, regardless of the customer's location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. Only an intentional visit to the close-ticket link will trigger closure, reducing accidental ticket closures and support disruption.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#88547
Fixed an issue where the timer could briefly use outdated information after start or pause actions, causing an incorrect time calculation. This helps users see a more reliable timer value and avoids large discrepancies in tracked time.
Original PR description
Before this change, onRecordChange listens to changes on the record for timer_start and timer_pause to drive the timer, depending on whether timer_pause was present on the record. However, since record is a proxy object that also subscribes to changes when its data is read, onRecordChange fires twice, once with the *previous* state and once with the updated data. On the first call, timer_pause would have the data from the previous button call, but by that point timer_pause is already in the past and forces a recalculation of the timer's server offset, causing a large discrepancy. This commit changes onRecordChange to use the second parameter nextProps instead, which bypasses the record from subscribing the callback for the outdated data. opw-4658402
This update fixes the conditions used to apply payroll subsidy rules in Mexican payroll. It helps ensure employee payslips calculate the subsidy correctly, reducing payroll errors and manual corrections.
Original PR description
task-4690544
Mexican payroll can now generate payslips for employees who only have variable income, such as commissions or bonuses, and no fixed base salary. This prevents a payroll processing error and helps ensure affected employees can be paid correctly.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413
Fixes an error that could block users when adding a rental product with variants during subscription renewal. The system now only processes rental dates when they are actually available, keeping the renewal flow usable before confirmation.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a rental product with multiple variants; 2. create a subscription order via the Rental app; 3. add the rental product; 4. confirm & invoice the subscription; 5. renew the subscription; 6. add the rental product to the renewal. Issue ----- > `Uncaught Promise > value.setZone is not a function` Cause ----- Commit 76526bdb3835 implemented the `_getAdditionalDialogProps` method for using OWL in the product configurator. In our flow, it simply checks whether the order is a rental order, and if so, it attempts to serialize its rental dates. Issue is that rental dates are not a required field as long as the order hasn't been confirmed yet, causing the traceback. Solution -------- Instead of checking whether it is a rental order, verify that the order has rental dates before attempting to serialize them. opw-4898437
Odoo Studio now uses each field's official capabilities to decide whether it can be grouped, sorted, or aggregated instead of relying on less reliable guesses. This makes view editing more accurate and helps prevent users from being offered options that do not work well for a given field.
Original PR description
Before this commit we used some heuristics in studio to determine whther some field had some ability (groupable, sortable, aggregator) After this commit, we use the not so new tools given by https://github.com/odoo/odoo/commit/b177b058be1531c3d2af2b591c22591c19240d33 Note that we still rely on the field type, because even if possible, groupong by some fields doesn't make much sense (eg.: float) task-4879382
The Helpdesk menu now only shows teams assigned to the website a visitor is using. This prevents teams from other websites appearing in the wrong place, reducing confusion for customers and staff.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939
Users can now preview XLSX spreadsheets from the document list view. Older XLS files are clearly blocked with a message explaining that only XLSX files can be opened in Odoo Spreadsheet, reducing confusion.
Original PR description
Before this commit: 1. Can't preview the xlsx file in the list view. 2. Can't preview the xls file. Reason: 1. The mimetype is not set in the isViewable for xlsx. 2. currently xls file is not compatible with our spreadsheet. After this commit: 1. Able to preview the xlsx file in the list view. 2. A notification will be displayed, indicating that `Only XLSX files can be opened with the Odoo Spreadsheet` for .xls file. Task- 3461536 Forward-Port-Of: odoo/enterprise#65162 Forward-Port-Of: odoo/enterprise#47585
EasyPost shipping labels now include the related Odoo delivery reference, making it easier for staff to match physical labels and carrier dashboard records with the correct delivery order. This reduces manual lookup effort and confusion during shipping operations.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615