Wednesday, May 21, 2025
17 changes · 18.0
Resolved issues and error corrections
The mail composer template dropdown now remains within the screen on mobile devices, even when template names are very long. This prevents users from losing access to dropdown options and makes saving or selecting message templates more reliable on smaller screens.
Original PR description
Steps to reproduce ================== - Use a mobile device/viewport - Go to any record with a chatter - Click on Log note - Expand the composer - Click on the template dropdown - Save the current content as a template with a long name - Open the dropdown again => The dropdown is almost entirely off screen Cause of the issue ================== The Dropdown component uses the usePosition hook. It works by doing the following: - It tries the fit the content using the position props (or it's default value) - If it doesn't fit, it tries the four other corners - If it's still doesn't fit, it gives up and uses the first one again Solution ======== Since we cannot show too much content inside a dropdown, we set a max-width on the dropdown content, and truncate the template names. Another possibility would be to allow an horizontal overflow. opw-4675320 opw-4674341 opw-4656725
A mail test helper now creates properly formatted message identifiers even when random numbers are small. This prevents occasional test failures and helps keep development and release validation more stable.
Original PR description
Steps to reproduce ================== Run the test `/test_mail.test_message_process_references_multi_parent_notflat` a bunch of times. It will eventually fail. Or simply change the random range from `randint(0, 99998)` to `randint(0, 98)` Cause of the issue ================== ```py "<%.7f-%05d-test@iron.sky>" % (time.time(), randint(0, 99998)) ``` If randint returns a low enough value, the msg_id might look like `'<1747742185.1234567- 42-test@iron.sky>'` Solution ======== We can pad the random int with zeros. runbot-110801
Point of Sale now shows the correct tax-free price when a customer is exempt from tax on products whose listed price already included tax. This prevents customers from being overcharged and keeps receipts and order totals aligned with the customer’s tax status.
Original PR description
**Issue:** When selling a product with a tax-inclusive price to a customer who is tax-exempt (e.g., under a "Rest of the World" fiscal position with a 0% tax mapping), the Point of Sale displayed the…
**Issue:** When selling a product with a tax-inclusive price to a customer who is tax-exempt (e.g., under a "Rest of the World" fiscal position with a 0% tax mapping), the Point of Sale displayed the tax-inclusive price instead of the correct tax-exclusive price. **Steps to Reproduce:** 1. Install the Sales, Point of Sale, and Accounting applications. 2. Create a product with a price configured to include taxes (e.g., a 20% VAT included in the sale price). 3. Create a customer and assign them a fiscal position that maps the product's default inclusive tax to a 0% tax (e.g., a "Rest of the World" fiscal position). 4. Create a fiscal position tax rule for the "Rest of the World" position, mapping the inclusive tax on the created product to a 0% tax. 5. Open the Point of Sale interface. 6. Select the customer created in step 3. 7. Add the product created in step 2 to the order. 8. Observe the total price displayed for the product. Expected Behavior: The Point of Sale should display the price of the product excluding the previously included tax, reflecting the 0% tax rate for the selected customer. Actual Behavior: The Point of Sale incorrectly displayed the original tax-inclusive price, even though the applied tax amount was shown as $0. **Root Cause:** The `get_tax_details` method calculates the base price (tax-exclusive) after the product's taxes have already been potentially remapped to 0% based on the customer's fiscal position. Consequently, when a product with an inclusive price is sold to a tax-exempt customer, the `total_tax_amount` becomes zero. The logic in `get_tax_details`,at line 368, that intends to adjust the base price when taxes are included doesn't trigger correctly because `total_tax_amount` is already zero, leaving the `raw_base` (which is derived from the tax-inclusive `price_unit`) unchanged. **Fix:** To resolve this, when preparing the base lines for tax computation, the code now detects if a product originally had a tax-inclusive price and if the effective tax rate has become 0%. In such cases, the `price_unit` of the order line is explicitly adjusted to its tax-exclusive value by reversing the original tax inclusion. This ensures that subsequent tax calculations and the final displayed price correctly reflect the tax-exempt status of the customer. Opw-4592602 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Indian GST Treatment is no longer automatically filled from country and company type when manually creating a partner. It is now filled through the partner autocomplete service, so users who create partners manually must choose the GST Treatment themselves.
Original PR description
This PR removes the `onchange` logic previously used to auto-set the l10n_in_gst_treatment field based on company_type and country_id. The GST Treatment is now set dynamically by the PartnerAutoComplete service. If a user manually creates a partner (without using autocomplete), they will need to select the GST Treatment manually. Related IAP-https://github.com/odoo/iap-apps/pull/1051
Email templates no longer offer video embedding for pasted YouTube links, avoiding content that would be removed when the template is saved. This prevents broken email layout and invalid saved content for users editing templates.
Original PR description
Problem: When pasting a YouTube link and embedding it as an `iframe`, saving removes the `iframe` element. This happens because `iframe` is listed as a `kill_tag` in `SANITIZE_TAGS`, leading to its removal. As a result, the wrapper `div` becomes empty and is converted to a self-closing element, which produces invalid HTML. Solution: Disable video embedding on `body_html` of email templates to avoid inserting `iframe` elements that will later be stripped. Steps to reproduce: 1. Paste a YouTube link in an email template. 2. Choose "Embed YouTube Video" from the popup. 3. Save the template. → The content is broken due to missing `iframe`. opw-4746178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures company branches in Italian e-invoicing share the same official connection settings as their parent company. It prevents duplicate-user errors when branches have the same VAT or tax code, making activation smoother in multi-branch setups.
Original PR description
- Prevent duplicate user conflict during official mode activation in multi-branch setups - Handle scenario where branches of the same company use the same Partita IVA (VAT number) or codice fiscale - Avoid "An user already exist in the database" error by validating user association logic - The branch should affect the same record in the db the will have the same proxy user Task [link](https://www.odoo.com/odoo/project/967/tasks/4737181) task-4737181
Group payment memo references now start with PAY instead of BATCH. This avoids confusion with the separate batch payment feature and aligns payment naming across the accounting app.
Original PR description
Current behavior before PR: - Memo prefix was BATCH/XXXX for group payments, but it has nothing to do with the batch feature Desired behavior after PR is merged: - Memo prefix in group payments is now PAY/XXXX. This was already the default syntax for payments without entries (introduced in 18.0), so it seems a good choice for a syntax for all payments Related Task (4356642) : - https://www.odoo.com/odoo/project/967/tasks/4356642 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Confirmed purchase orders now allow users to delete section and note lines, matching the existing ability to edit them. This removes an unnecessary error and makes purchase order cleanup more consistent after confirmation.
Original PR description
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is possible to delete a section or note line on a confirmed purchase order. --- opw-4744367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unwanted horizontal scroll on small screens in the eLearning app. Mobile users can now browse course content without the page shifting sideways unexpectedly.
Original PR description
In the kanban template there is a `row` container that is not wrapped into a `container` DIV, so it has negative margin and produce an overflow (horizontal scroll). This commit adds the `g-0` class on the `row` container. Steps to reproduce: * On Odoo on small screen * Go to the app "eLearning" * Try to scroll horizontally => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Project sharing where the page could show an error if no suggested contacts were returned. Users can now continue working normally even when there are no contact suggestions available.
Original PR description
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958)
This update ensures attachment deletion is only blocked when the German audit trail setting is actually enabled for the company. Businesses that have audit trail disabled can now delete attachments normally, avoiding unnecessary workflow interruptions.
Original PR description
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024
This fix prevents invoice submissions to Malaysia's MyInvois service from failing when a customer reference is present. Businesses using Malaysian e-invoicing can submit invoices more reliably without errors caused by this additional customer information.
Original PR description
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice and accounting PDF downloads now use the report name configured for the selected print action. This avoids confusing or incorrect file names when users print or save accounting documents.
Original PR description
Default pdf report name should match the "print report name" set on the action report Task 4646733
This fixes an error that could block users from opening the Paid Seats appointment template if the default booking fee product had been deleted. The system now restores the needed product when loading the template, preventing the crash and keeping appointment setup usable.
Original PR description
Currently a `ValueError` is arising when user try to load the appointment template `paid seat`. To get this error: - Create database without demo data and install appointment_account_payment - Delete the Booking Fee Product from products. - Open Appointment and click the `Paid Seats` to select template options. - The error appears in the console log. Error: ``` ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted ``` To fix this issue, used `convert.convert_file` to restore deleted product while loading appointment template. Sentry ID: 6013528364
This update ensures longer Mexican Payment 2.0 XML files are read correctly when uploaded to EDI documents. As a result, the Fiscal Folio is filled in automatically instead of being left blank, reducing manual correction and document processing issues.
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487
This fix allows existing customers to use the newer pain.001.001.09 ISO20022 payment format beyond SEPA credit transfers. It helps businesses generate compatible payment files for banks that require this newer format, enabled through a system setting.
Original PR description
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016
This fix prevents an error when users submit Chilean electronic invoices to SII using certificates that do not include a subject serial number. It helps keep invoice submission working reliably for companies using Chilean localization, even with certificates missing that optional detail.
Original PR description
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/account_move.py#L290 Here, If ``subject_serial_number`` of certificate is False. It will lead to the above traceback. ``subject_serial_number`` can be False because Some certificates do not provide this number. ref-https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/certificate.py#L19-L20 sentry-6591311577