Thursday, September 25, 2025
11 changes · master
Enhancements to existing features
The setting that controls whether tax details are handled as single lines has been moved from invoice OCR into the core accounting area. This makes the same behavior available for both OCR processing and electronic invoice imports, improving consistency across accounting workflows.
Original PR description
[IMP] account_invoice_extract: move field to account Move the extract_single_line_per_tax field to the account module: until now, this field was only used in the OCR, but we want to use it in the ubl import so to be accessible from both modules, we move it to account. task-5047859
Resolved issues and error corrections
The bank reconciliation action now avoids using desktop-only behavior on mobile screens, where a different view is shown. This prevents users from seeing an error when tapping the reconcile button on phones or small screens.
Original PR description
When clicking on the reconcile button in mobile, the js_class of the custom list view is never triggered because, in small screens (aka. "mobile"), by default, kanban views are used instead of list views (or at least take precedence). To avoid having a traceback, we will keep the custom behavior in desktop only no task id Forward-Port-Of: odoo/enterprise#95145
Code cleanup and technical improvements
The system now relies on a single built-in safeguard to prevent circular parent-child record links, removing duplicate checks in affected apps. Users may see clearer error messages when they accidentally create a loop, while behavior remains otherwise unchanged.
Original PR description
The ORM's `_parent_store` mechanism already prevents recursive loops by raising a `ValidationError` early on. This commit removes now-redundant (since https://github.com/odoo/odoo/pull/35659) Python constraints across various models that were performing the same check. Additionally, the generic ORM error message for recursion has been made more user-friendly to improve the user experience.
Users without HR permissions could see an empty employee list because an employee photo field triggered an access error. The view now limits that photo field for those users, keeping the work order employee list usable until the underlying HR issue is resolved.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group. Forward-Port-Of: odoo/enterprise#95424
General Ledger PDF reports now show longer company names in the footer instead of cutting them off after a short limit. The footer spacing was also adjusted so the longer name fits cleanly on printed reports, improving document presentation for companies with longer legal names.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972 Forward-Port-Of: odoo/enterprise#94535
Scheduled account report emails no longer fail when a partner included in a pending batch has been deleted before processing. The system now keeps only existing partners in the batch, helping automatic statement delivery continue reliably.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571 Forward-Port-Of: odoo/enterprise#95127
This fix ensures helpdesk tickets appear correctly in timesheet reports when they should. It corrects a previous report update that did not target the existing report field properly, helping users see complete ticket-related time information.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Customers buying subscriptions through the e-commerce checkout are now informed that their payment details will be saved for automatic renewals. This aligns the online shop experience with the portal flow and improves transparency around recurring payments.
Original PR description
Before this commit, when the customers paid a subscription on the portal, they would get the following information: Your payment details will be saved for automatic renewals. When they would pay on the e-commerce, the token would be saved but they would not be notified. task 4808806
This fix ensures that using the left and right arrow keys inside a dropdown does not accidentally trigger actions elsewhere in the interface. It makes keyboard navigation more predictable and prevents unexpected UI changes while users are selecting dropdown options.
Original PR description
This commit prevents arrowleft and arrowright hotkeys to trigger on other parts of the UI when navigating a dropdown. Community: https://github.com/odoo/odoo/pull/226604 Task: [5048895](https://www.odoo.com/odoo/project.task/5048895) Forward-Port-Of: odoo/enterprise#94478
Quality checks now use the unit of measure entered on the receipt line when it differs from the product default. This helps teams review inspections with the correct operational quantity and avoids confusion during receiving.
Original PR description
Steps to reproduce: - Create a storable product “P1” with UoM = Unit - Create a quality point: - Control per: Quantity - Operation type: Receipt - Product: P1 - Create a receipt of 1 unit of P1 - Mark as "To Do" - Open the detailed operations (SML) and update the UoM to Dozen - Go to the quality check Issue: The UoM of the quality check is still "Unit" instead of "Dozen", because the field was related to `product_id.uom_id`. Fix: Compute the UoM from the stock move line if available, otherwise fall back to the product's default UoM. opw-5080657
Users can no longer try to send a WhatsApp message without selecting a template. This prevents an application error and guides users to complete the required message setup before sending.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the…
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874 Forward-Port-Of: odoo/enterprise#93898