Daily updates from Odoo
Friday, July 4, 2025
11 changes
1 change
Enhancements to existing features
This update improves how stock replenishment needs are calculated by processing orderpoint quantities in batches. It also corrects a purchasing-related issue so purchase orders are considered accurately without accidentally scanning unrelated records.
Original PR description
The method `orderpoint._compute_qty_order_computed` was batched in commit 17a2de9 then reverted in commit a58b995 because of a bug introduced when purchase_stock is installed. It should still be beneficial performance-wise to batch the calls to `orderpoint._quantity_in_progress` so this commit reintroduces the batching. The part that led to the issue was the override of `_quantity_in_progress` in the purchase_stock module. In this commit we fix the `_quantity_in_progress` method. Thanks to that, the test introduced in 606dc71 is passing even with the batched version of `_compute_qty_to_order_computed`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213154
8 changes
Enhancements to existing features
This update adds several state-specific payroll tax rates used in US salary calculations, including Alabama, Colorado, and Washington. It helps payroll teams calculate employee pay and employer obligations more accurately based on current state requirements.
Original PR description
Added salary rules for state: - US: Alabama ESA rate - US: Colorado Support Surcharge rate - US: Colorado Solvency Surcharge rate - US: Washington EAF Rate task-4814709 Forward-Port-Of: odoo/enterprise#89344 Forward-Port-Of: odoo/enterprise#87708
The Belgian payroll Eco-Vouchers wizard now keeps each national identification number on its own line. This helps payroll teams correctly handle employees whose NISS changed during the relevant period, reducing reporting confusion and improving voucher file accuracy.
Original PR description
In the Eco-Vouchers wizard, we should have only 1 NISS per line so if an employee changed NISS, it may need multiple lines. Task: 4866687
Uruguayan electronic invoices now send the invoice line name consistently as the mandatory item name, while placing overflow text, product descriptions, and addenda in the optional description field. This prevents duplicated product names on generated reports and keeps invoice XML aligned with DGI length requirements.
Original PR description
This PR aims to improve the way we create NomItem and DscItem lines on the XML files we send to DGI in order to generate the PDF report. We have two fields to inform to DGI in an electronic invoice,…
This PR aims to improve the way we create NomItem and DscItem lines on the XML files we send to DGI in order to generate the PDF report. We have two fields to inform to DGI in an electronic invoice, NomItem which is mandatory an has a maximum of 80 characters to send, and DscItem that is optional an has a limit of 1000 chars. So we ensure NomItem is always sent, and the description will be filled like this: First, if the product name is longer than 80 chars, DscItem field will contain the characters that didn't fit in the NomItem field (characters from the 80th) Then it will contain the description of the product and the addenda content if it exists. Plus, I refactor the method _l10n_uy_edi_cfe_D_global_discount so it is also aligned with what I mentioned before. Another reason for this improvement is that, as the description of a product contains the product name at the beginning, we faced some issues when a user added a description on the fly in the line of the product, and then confirmed and printed the report. In this case, the name of the product was duplicated in the report. With this change, the description will only contain the the part of the product name that exceeds the 80th character. Example:  Forward-Port-Of: odoo/enterprise#80993
PDF exports for accounting reports now generate report content progressively instead of holding all report pages in memory at once. This reduces memory usage during large exports and uses a cleaner internal mechanism for PDF rendering.
Original PR description
When generating the pdf export, we first generate all the bodies of the reports to export in HTML, then add them to a stream, and finally use it to generate the pdf => doing that, we'll use twice the memory: once for all the html, once for the copy in the stream. We can do better by yielding report by report the HTML it generates :) Use self.allow_pdf_render intead of directly patching wkhtml, since allow_pdf_render is cleaner. task-4823834
Shop floor users can now adjust routing directly from a work order, including adding the next operation or moving work to another work center. This reduces back-and-forth with manufacturing order overview screens and gives teams more flexibility while work is already in progress.
Original PR description
**Desired behavior after PR is merged:**
- Add modify routing button in shopfloor workorders with the ability to create another workorder or move work centers
- Allow moving to another work center while the workorder is still in progress
Task:4850003Odoo AI can now use system-managed agents that stay hidden from regular users and cannot be edited or deleted through the interface. These agents can provide direct AI responses without opening chat channels, enabling smoother background automation and simpler user experiences.
Original PR description
## Purpose - Introduced a new is_system_agent flag to distinguish system agents from user-created agents. System agents are hidden from the UI and are not editable by users. - Added a new method get_direct_response() to allow system agents to generate direct responses without creating chat channels.
Users can now turn off the journal-specific filter directly from the bank statements view. This makes it faster to switch from a focused journal view to all bank statements without returning to the dashboard.
Original PR description
This improves the UX by allowing users to quickly switch off the filter and see all bank statements, rather than having to go back to the dashboard and reselect the journal. Task ID: 4797334
When registering payments with SEPA Direct Debit, users now see a clear banner listing any partners without a valid SEPA mandate. This helps teams quickly identify who needs mandate setup before payments can be processed.
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 Forward-Port-Of: odoo/enterprise#81019
2 changes
Enhancements to existing features
This change adds checks to make sure customer phone numbers, email addresses, and website links are properly formatted before they are saved. It helps keep contact records cleaner and reduces problems caused by incorrect customer information.
Original PR description
Added validation for phone, email, and website fields on res.partner Added validation logic to ensure only properly formatted phone numbers, emails, and website URLs are accepted when creating or updating a customer/contact. Description of the issue/feature this PR addresses: Customers could be created with invalid phone, email, or website values. Current behavior before PR: No validation exists for the format of phone, email, or website fields on res.partner. Desired behavior after PR is merged: Validation is enforced for phone, email, and website fields, preventing the creation or update of a customer/contact with invalid values. I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr]
Saudi e-invoicing journal onboarding now creates unique identifiers using each journal's code, name, company, and internal ID. This reduces duplicate setup issues and alerts existing users to re-onboard affected journals where prior identifiers may not have been unique.
Original PR description
… common name to be unique per journal Previously, the company name was used as the common name when onboarding the journal. However, the common name has to be unique. The fix changes the common name to use the journal's short code, journal name, and company name to ensure uniquness. Additionally, an improvement is applied to the serial number on journals. Previously, users inputted this field manually. Now, the system uses the journal's id as the serial number to ensure uniqueness. A post-migration script was added to notify users that they need to re-onboard their journals. This is done in case users previously onboarded journals with non-unique serial numbers. task-4797124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216135 Forward-Port-Of: odoo/odoo#215012