Daily updates from Odoo
Saturday, July 11, 2026
10 changes · saas-19.4
New functionality added to Odoo
Users can now instantly fetch e-invoices from the Polish KSeF platform directly within Odoo, eliminating the need for scheduled updates. This new 'Fetch e-Invoices' action, accessible through the gear icon, provides immediate control over document synchronization, ensuring data accuracy and compliance.
Original PR description
Previously, bills could only be retrieved from the KSeF platform via a scheduled cron job, leaving users with no option to manually sync documents on demand. An "Import from KSeF" action has been added to the gear (cog) menu within both the list and Kanban views. Clicking this option triggers the synchronization process immediately and reloads the active view. Task [link](https://www.odoo.com/odoo/project.task/6306892) task-6306892 Forward-Port-Of: odoo/odoo#274798 Forward-Port-Of: odoo/odoo#271459
Enhancements to existing features
The Time Off planning Gantt view now uses paging and opens with an overview-style scale by default. This should make larger schedules easier and faster to browse, improving usability for managers reviewing leave plans.
Original PR description
Add paging and default scale as the overview gantt task-6381315 Forward-Port-Of: odoo/enterprise#123936
Resolved issues and error corrections
The billable checkbox is now hidden when a timesheet entry is not connected to a sales order, so users no longer see an option that has no billing effect. This reduces confusion and makes the timesheet systray and inline forms better reflect what can actually be billed.
Original PR description
Previously, the `is_billable` checkbox was visible in the timesheet systray even when no Sales Order was linked to the project or task. Toggling the checkbox in this state had no actual effect on billing, leading to user confusion. This commit introduces a non-stored computed field `has_available_so` on `account.analytic.line`. This field evaluates whether billing is possible based on the project and task configuration, and is used to conditionally hide the checkbox in the UI. task: 6328661 Forward-Port-Of: odoo/enterprise#122326
The project Gantt view now consistently shades unavailable periods when users work across multiple companies. This prevents confusion by making approved time off visible in the schedule even when several companies are selected.
Original PR description
Steps to reproduce: - Create one user linked to two companies. - Create one employee per company for that user. - Select one company and approve a time off for the employee. - Open Tasks > Gantt and…
Steps to reproduce: - Create one user linked to two companies. - Create one employee per company for that user. - Select one company and approve a time off for the employee. - Open Tasks > Gantt and create a task during the approved time-off period the warning is shown and the Gantt cell is grayed out. - Select both companies and create a task during the same time-off period in Tasks > Gantt. Issue: When multiple companies are selected, the time-off warning is still displayed but the corresponding Gantt cells are no longer grayed out, leading to an inconsistency between the warning logic and the Gantt rendering. Cause: In multi-company setups, a user can be linked to multiple resources. The Gantt unavailability logic assumed a one-to-one relationship between user and resource causing unavailability intervals from some resources to be overwritten. Solution: Aggregate unavailability intervals from all resources linked to the same user, limited to the selected companies, and merge them with the company calendar unavailability to ensure consistent Gantt gray rendering. Related PR: https://github.com/odoo/enterprise/pull/57028 task-5089385 Forward-Port-Of: odoo/enterprise#123732 Forward-Port-Of: odoo/enterprise#105288
This update fixes an issue where the 'Commercial Invoice' report was incorrectly available to all companies, leading to duplicate print options. Now, the report is restricted to invoices generated for Thai companies with a Sales journal type, ensuring accurate reporting and avoiding confusion.
Original PR description
The "Commercial Invoice" report action had no domain, so it appeared as a print option for account.move records of any company, not just Thai ones. This caused duplicate-looking invoice print options when another localization was installed alongside l10n_th. Restrict the report's visibility to invoices whose company's fiscal country is Thailand and journal type is Sales. task-6372205 Forward-Port-Of: odoo/odoo#275213
This update resolves an issue with our Odoo installation's Python dependency, python-stdnum. The core fix removes an outdated workaround that caused compatibility problems with the latest version of python-stdnum. The change now ensures Odoo works correctly with the newest version of this dependency, specifically for Ubuntu Resolute environments.
Original PR description
In python-stdnum 2.0+, the upstream issue regarding the zeep Transport class timeout handling has been resolved arthurdejong/python-stdnum@6cbb9bc09c25fbda7a032521bc57b44e0ce18ec4), and the method signature for `get_soap_client` was updated to include the `verify` parameter. Applying our legacy monkey patch on python-stdnum >= 2.0 causes signature mismatch issues and is no longer necessary. This commit: - Restricts the `get_soap_client` monkey patch to run only for `python-stdnum < 2.0`. - Updates `requirements.txt` to use python-stdnum 2.2 for Python 3.14+ to ensure compatibility with Ubuntu Resolute. Forward-Port-Of: odoo/odoo#275506 Forward-Port-Of: odoo/odoo#275046
A recent issue was identified where the 'star' priority field in the Helpdesk app on smartphones displayed incorrectly – appearing as black on a gray background. This pull request restores the intended yellow color on smaller screens, ensuring a consistent and professional user experience for Helpdesk users. This change improves visual clarity and usability.
Original PR description
Steps to reproduce: - Open Helpdesk app on smartphone - Go to a ticket - the star priority_field is black with a gray background => bug task-6369589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275326
This update fixes an issue where users sending invoices only by email in version 19.0 were incorrectly prompted to send them to the tax agency, causing errors. The fix restores the previous behavior, warning users to delete the attached PDF before sending to the tax agency, ensuring compatibility with earlier versions.
Original PR description
**Steps to reproduce:** - Install the `l10n_it_edi` module and switch to an IT Company. - Create and confirm an invoice for a non-Italian customer. - Send the invoice, making sure that only `by…
**Steps to reproduce:** - Install the `l10n_it_edi` module and switch to an IT Company. - Create and confirm an invoice for a non-Italian customer. - Send the invoice, making sure that only `by Email` is enabled. - Attempt to send the invoice again. **Issue:** - In `18.0`, the XML file is not generated when re-sending an invoice that was previously sent only by email. - Starting from `19.0`, attempting to `Send to Tax Agency` raises an error: `UnboundLocalError: cannot access local variable 'attachment_name' where it is not associated with a value` **Root cause:** At [1], `_get_alerts` method does not check whether the invoice was previously sent only by email. As a result, the warning banner is not displayed, and allows the user to `Send to Tax Agency`. **Fix:** Restore the expected behavior by preventing `Send to Tax Agency` when the invoice was previously sent only by email. Instead, display the appropriate warning message instructing the user to delete the PDF attachment before sending to the Tax Agency, matching the behavior in `17.0` (confirmed with PO). [1]: https://github.com/odoo/odoo/blob/c0d8d36481e106f0209521bbb127cb3b1ad1059a/addons/l10n_it_edi/models/account_move_send.py#L27-L33 opw-6293519 Forward-Port-Of: odoo/odoo#275600 Forward-Port-Of: odoo/odoo#269547
This update fixes an issue where combo lines weren't being imported correctly, leading to inaccurate calculations. The fix allows users to now specify combo item IDs during import, ensuring combo line amounts are calculated accurately and imported successfully.
Original PR description
Issue: --- Importing combo lines from file is not working correctly. Combo amounts are not correctly calculated. Cause: --- Currently we cannot set `combo_item_id` field in import file, as filling it will cause import fail on `ensure_one()` being called on `lined_lines` while no line is still created. Fix: --- The proposition here is to pop the `combo_item_id` in import while creating SOLs and then writing these fields values after records are created. This will allow users to set `combo_item_id` in order to be able to import combo lines. opw-6355560 Forward-Port-Of: odoo/odoo#275069
This update ensures that the customer's phone number is consistently saved when placing orders through a self-order kiosk (like a payment terminal). Previously, the phone number was lost during a payment processing step. This change corrects a bug that prevented accurate order information from being recorded, improving the customer experience.
Original PR description
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed…
When ordering from a self-order kiosk (e.g. with a Stripe payment terminal), the customer's phone number was saved on the created partner but no longer on the order itself (pos.order.mobile stayed empty), while the email was correctly registered. Self-order (QR code / mobile) was not affected. Steps to reproduce: ------------------- * Set a POS in kiosk mode with a payment terminal * Place an order and fill in the contact information (email & phone) * Pay through the terminal * Open the order in the backend > Observe that the email is registered but the phone (mobile) is not Why the fix: ------------ The kiosk pays through a second server round-trip (/kiosk/payment), which runs _check_pos_order again on the already created order. There, 'email' falls back to the partner's email but 'mobile' was taken only from the payload. By payment time the phone is no longer in the frontend payload (it is stripped from every self-order response), so the second sync overwrote the mobile saved on the draft with an empty value. The email survived only thanks to its partner fallback. Mirror the email behaviour and fall back to the partner's phone so the mobile survives the payment re-sync, consistently with the mobile field being computed from the partner. opw-6331335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273679