Daily updates from Odoo
Saturday, July 11, 2026
8 changes · saas-19.2
Resolved issues and error corrections
The timesheet billable checkbox is now hidden when there is no linked Sales Order for the project or task. This avoids confusion by only showing billing controls when they can actually affect customer billing.
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
This update resolves an issue where sales orders could incorrectly show analytic distributions exceeding 100%, leading to confusing financial reporting. The change consolidates analytic distributions from multiple models into a single line, maintaining functionality while ensuring accurate reporting. This improves clarity and prevents potential over-allocation of costs.
Original PR description
Steps: 1. Create an analytic model filtered by partner. 2. Create an analytic model filtered by product. 3. Create a project with an analytic distribution. (Make sure the distributions use different plans) 4. Create an SO for a product within the project that both the models apply to. 5. Confirm the SO. 6. Notice the analytic distribution for the project account is at 200%. When an SOL is created, the analytic distribution from each model is added as a separte line The analytic account for the project is added to each analytic distribution line. This can easily cause the account to have >100% distribution for a given SOL. This is unintuitive and confusing behaviour. This PR changes the behaviour to only create one line for all the distributions from analytic models. This should prevent this behaviour while keeping the functionality of applying the project distribution to each line. opw-6250908 / opw-6304033 Forward-Port-Of: odoo/odoo#270151
This update fixes an issue where the 'Commercial Invoice' report was incorrectly available for all companies, leading to confusion and duplicate options. The report is now restricted to only display invoices for Thai companies with a Sales journal type, ensuring accurate reporting and compliance.
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 related to a Python library dependency (python-stdnum) used in Odoo. The change ensures compatibility with newer versions of the library and the Ubuntu Resolute environment, preventing signature mismatch errors. Updating the dependency to version 2.2 improves stability and performance.
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
This update resolves an issue in the l10n_it_edi module where sending IT invoices again caused an error. The fix ensures that users are correctly guided to delete the PDF attachment before attempting to send invoices to the tax agency, maintaining consistent behavior across Odoo 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 accurately due to a technical limitation in the import process. The fix allows users to correctly specify combo items during import, ensuring accurate calculation of quantities and prices for combo orders. This improves the reliability of sales order imports.
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 via 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 the phone number from being recorded, improving order accuracy and customer communication.
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
This update resolves an issue where cloud attachments downloaded through signed URLs were saved with generic names. The fix ensures that the correct file names and types are used when downloading attachments from cloud storage services like Azure and Google, improving the user experience and data integrity.
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275700 Forward-Port-Of: odoo/odoo#274019