Friday, July 24, 2026
14 changes · saas-19.3
Enhancements to existing features
When a user selects a project in the timesheet timer, Odoo now automatically fills in the task they most recently logged time on for that project. Helpdesk projects get the same convenience by preselecting the most recently used ticket, reducing clicks for recurring time entries.
Original PR description
When selecting a project in the timesheet timer, the task on which the user most recently logged time for that project is now prefilled, as they are most likely to keep logging time on it. If not, selecting a different task only requires one click. For Helpdesk projects, where the timer shows the ticket field instead of the task field, the most recently timesheeted ticket is prefilled in the same way. task-6359030 Forward-Port-Of: odoo/enterprise#124010
Spreadsheet users can now show the readable name of a selected global filter value, such as a customer name, instead of only its internal ID. This makes spreadsheet reports easier to understand and share with business users.
Original PR description
Before this commit: If you use ODOO.FILTER.VALUE and have a customer set in the global filter, it returns the id of the customer. That can be useful in some cases but in others you might simply want the label. Task: 6167605 Forward-Port-Of: odoo/enterprise#121004 Forward-Port-Of: odoo/enterprise#115984
The employee time off planning view now loads absence data in larger batches and only for the requested date range. This makes the view much faster for teams with many employees, reducing wait times from several seconds to around one second in large scenarios.
Original PR description
At odoo, our friendly kitchen chef needs to know who is off on any given day. To know that, they use the holiday gantt view and display all employees and check the sum. For 200+ employees working at GR2, `get_gantt_data` takes 7+ seconds `_unavailable_intervals_batch` is called for each individual version, which means it's not batched. Ultimatly, it leads to lots of sql queries that could be grouped together. With this commit, the calls are batched per calendar before: ~7s after: ~900ms-1s Forward-Port-Of: odoo/enterprise#124820
The ActivityWatch suggestions panel now shows total tracked time per project and a grand total across all suggestions. This gives users a clearer view of their logged hours directly in the timesheet workflow, helping them review and validate time entries more easily.
Original PR description
This commit introduces new time tracking metrics to the ActivityWatch suggestions panel to improve user visibility into their tracked hours. **Enhancements:** - Added the total duration per project in the By Project grouped view. - Added a grand total footer for all suggestions at the bottom of the list. task-6088877 Forward-Port-Of: odoo/enterprise#114772
Resolved issues and error corrections
Fixed an issue where importing a Chilean electronic invoice file with multiple documents could put all invoice lines and references onto the first vendor bill. Each imported document is now kept separate, helping prevent incorrect bill totals and reconciliation problems.
Original PR description
When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references…
When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.
Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.
e.g. l10n_es_edi_facturae:633:
```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```
Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.
Introduced in: https://github.com/odoo/enterprise/pull/75327.
opw-6378954
Forward-Port-Of: odoo/enterprise#124691Fixed an issue in Chilean electronic delivery guides where delivering a kit could fail if its components used different units of measure than the kit itself. The guide now prices those component lines directly from the product when needed, preventing errors and allowing the delivery document to be printed successfully.
Original PR description
When a kit is delivered, each component move is linked to the kit's sale order line. Pricing the delivery guide in "sale order" mode converted the component quantity into the kit's sale UoM. For a component sold in a different UoM category than the kit, this cross-category conversion raises a UserError. Steps to reproduce: - Create a BoM for a kit product with a component in a different UoM category - Create a customer with Delivery Guide Price = "From Sale Order" - Sold the kit in a sale order and deliver it - On the delivery, print the delivery guide -> error This fix makes the guide price for a component move to be "product" if the component's product is different from the related sale line product, avoiding the cross-category UoM conversion. opw-6327895 Forward-Port-Of: odoo/enterprise#125199 Forward-Port-Of: odoo/enterprise#122776
Product managers can now use barcode lookup to automatically fill product details without needing full administrator access. This keeps product creation workflows efficient while avoiding unnecessary elevated permissions.
Original PR description
Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled. ## Steps to replicate: - Install stock with demo data -…
Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled. ## Steps to replicate: - Install stock with demo data - Barcode Database > Setup barcode lookup credentials - Users > Marc Demo > Give Marc Demo > Master Data > Products > Create - Login as `Marc Demo` - Products > Barcode: `850049670180` > Click anywhere else ## Observed Behaviour: Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin). ## Root cause: This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1]. [1]- https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 ## Why this is an issue: The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case. In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6]. As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required. ## Solution: Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent. As a result, users no longer need unnecessary administrative privileges toperform barcode lookups. [2]: https://www.odoo.com/odoo/project/49/tasks/3911024 [3]: https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 [4]: https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 [5]: https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab [6]: https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a opw-6290999 Forward-Port-Of: odoo/enterprise#121915
French VAT declarations can now be sent successfully even when the company SIRET number contains spaces, reducing avoidable filing errors. Users will also be warned when a bank account number appears incorrectly formatted, helping them correct payment details before submission.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#124870 Forward-Port-Of: odoo/enterprise#120689
Applying Engineering Change Orders with uploaded documents no longer fails because the system now links copied documents to the correct attachment record. This helps manufacturing teams apply product changes reliably without manual cleanup or unexpected errors.
Original PR description
When applying an ECO, `action_apply` copies each ECO document onto the product template and fills `origin_attachment_id` with `attach.id`. That field is a many2one to `ir.attachment`, but `attach` is a `product.document`. Steps to reproduce: - Create an `mrp.eco` record and start a new revision - Upload a document on the ECO, note its product.document id - Make sure no ir.attachment exists with that same id - Move the ECO to its final stage and hit "Apply Changes" - Observe the error The very same change was already applied on master by 3a39186f883, but was never backported. opw-6387343 Forward-Port-Of: odoo/enterprise#124950
Electronic invoices sent from Colombian branches now use the parent company's official name in the DIAN XML. This helps DIAN correctly match the invoice to the company's tax ID and avoids rejections caused by branch names.
Original PR description
The correct behavior should be to use the original company name in this specific XML tag For the DIAN, branch names will not be recognized as related to the NIT. So, when sending electronic invoices from a branch, the XML should use the name of the parent company of that branch. Ticket [link](https://www.odoo.com/odoo/project.task/6074280) opw-6074280 Forward-Port-Of: odoo/enterprise#115494
The Belgian EC Sales List export now uses the correct foreign VAT number when a company files a Belgian report from another country. This helps ensure XML and PDF reports show compliant declarant details for cross-border tax reporting.
Original PR description
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly…
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference. ### Steps to reproduce the issue: 1. Download Accounting and l10n_lu 2. Switch to LU company 3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701) 4. A pop up will appear saying: Click to create the taxes for this country. so click there to create the taxes 5. Go to Invoices and create a new invoice and be sure that: 1. be sure the customer has a VAT number in their profile 2. in tab Other Info the Fiscal Position is set to Belgium 3. the tax applied is 0% EU S (BE) 4. date of invoice is in June 6. Open the tax return in 1 July 7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines 8. Click on Validate 9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company ### Cause of the issue: The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports. ### Reason to introduce the fix: To ensure tax compliance by appling the correct VAT number from the foreign fiscal position. opw-6170447 Forward-Port-Of: odoo/enterprise#125210 Forward-Port-Of: odoo/enterprise#124698
Point of Sale IoT now works better with newer IoT Boxes that no longer provide some device details. The system avoids relying on missing information when finding printers or payment devices, reducing setup and connection issues.
Original PR description
Newer IoT Boxes don't share device subtype or manufacturer. We then adapt the domains to avoid searching on fields that aren't filled. task-6388669 task-6388733 Forward-Port-Of: odoo/enterprise#125201 Forward-Port-Of: odoo/enterprise#124306
This fixes an issue that blocked users from saving changes to analytic distribution settings on employee records. The field remains available for payroll accounting setup, but it is no longer tracked in a way that causes save errors.
Original PR description
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic…
Problem: Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it. Steps to reproduce: 1. Enable analytic accounting 2. Try to edit the analytic distribution field on an Employee 3. Notice the error being thrown when trying to save Cause: Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields. https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172 Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited. Caused by 88a3e70 , as a result of this comment https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443 that mentioned that whitelisted fields should have tracking set to true. However, that's not necessary. opw-6405122 Forward-Port-Of: odoo/enterprise#125135
Users opening account reports from VAT return checks can now refresh the page without losing the report or seeing an error. This makes the VAT return workflow more reliable while leaving reports opened from menus unchanged.
Original PR description
Opening an account report through the VAT return button on an account.return.check record returns an inline client action whose report_id only exists in context. On refresh, Odoo will throw an error because it will try to rebuild the action context based off of the URL which is deficient. This will not effect reports opened via the menu since those follow a different pathway. This fix anchors the inline action to the "path" property stored on the client action. A helper method was added for deriving the action_id from a given report. opw-6366964 Forward-Port-Of: odoo/enterprise#125246 Forward-Port-Of: odoo/enterprise#124560