Wednesday, May 21, 2025
14 changes
6 changes
Resolved issues and error corrections
Fixes an error that prevented users from deleting projects when the ESG Project module was installed. This ensures project cleanup works as expected without unexpected traceback messages.
Original PR description
Before this commit, when the user tries to delete a project in project app, a traceback is occurred because of recursion loop in the code during the deletion of the record. This commit removes the recursion in the code to correctly delete the project without any issue. Steps to reproduce the issue ---------------------------- 0. Install `esg_project` module 1. Create a project 2. Go to Projects list view 3. Delete the project created in step 1 Expected behavior ----------------- The project should be deleted without any issue Current behavior ---------------- A recursion error is occurred during the deletion of the project task-4788173
This fixes a checkout crash for Chilean customers when required invoicing details were left blank. Shoppers now see the expected checkout navigation instead of an error page, helping prevent abandoned orders.
Original PR description
**Steps to reproduce:** Leave at least one field empty on the invoicing info page of the website checkout flow. For that page to appear, the customer country must be Chile, and the setting "Automatic Invoice" must be checked on the Website settings. **Issue:** Error 500 when rendering the template of the navigation buttons. The button values are not set.  Bug introduced in commit odoo/enterprise@ba260e8 Fixed by calling the method that sets the values before rendering the template.
The IoT device page buttons for downloading logs and restarting Odoo now work again after a previous page change broke them. This restores important support and maintenance actions for connected IoT boxes.
Original PR description
Since odoo/enterprise#81180 removed the `ip_url` field from the IoT box form view, these buttons have not been working since their JS widgets relied on that field. This commit fixes the issue by making them use the new `formatEndpoint` helper instead. task-4813431
This fix prevents an error when users fetch e-invoice IRN details from vendor credit notes created during the GSTR-2B flow. It ensures the Indian GST reporting workflow continues without a traceback caused by a translation handling issue.
Original PR description
**Steps to reproduce:** 1) Open a GST return period. 2) Click Fetch GSTR-2B Summary. 3) Go to Vendor Refunds. 4) Open the vendor credit note created by OdooBot. 5) Click the Fetch button. -> Traceback occurs. **Cause:** The translation function (_()) was incorrectly used with two arguments instead of one in this commit https://github.com/odoo/enterprise/commit/14bfe78b034563637e43fd2795c9498c736d0dbc **Fix:** Change the arguments that are applicable for translation. **Task**-4808874
This fix prevents self-ordering kiosks from failing when they need to communicate with an IoT box without a logged-in user. It adds a secure proxy path that verifies the kiosk session and returns the needed authorization so kiosk ordering can continue reliably.
Original PR description
With the introduction of signing communication between the IoT box and the DB, a `sign_communication` method is called on the `iot.box` model for every IoT request. This works fine when there is a logged in user, however in the case when there is no user it fails. This is due to the `call_kw` route used by ORM calls requiring a user. In the Kiosk environment, there is no logged in user, so the request fails. To fix this, a new route has been added to proxy the request, which verifies the session ID and then returns the authorisation hash as usual. task-4809897
The AI update action now processes each selected record only once instead of repeating work across the full selection for every record. This prevents unnecessary AI service calls, reducing delays and avoidable usage costs when users run the action on multiple records.
Original PR description
Scenario: - create a res.partner server action "Update Record" with "Update with AI" and a prompt like "set phone to <t t-out="object.id">ID</t> times 2" - push on "Create contextual action" button - go to a contact list view, select 4 contacts and run the action Result: there is 16 calls to iap Reason: when running an action, _run_action_object_write is called one time per record, but the ai_server_actions override fill the field of all records at each call. Issue found when investigating unrelated opw-4491099
1 change
Resolved issues and error corrections
Sendcloud shipping rate requests now include postal codes so zonal carriers can calculate prices correctly. The change also validates incompatible shipping products earlier, helping prevent orders from using the wrong shipping method or bypassing required checks.
Original PR description
The API requests lacked postal codes, causing errors like "no rate available" even when rates could be calculated using zonal logic. Additionally, users weren't receiving errors when an incorrect or zonal shipping product was not selected, allowing the order to bypass proper validation. By always including postal codes, this change ensures correct rate calculations and prevents the selection of incorrect shipping methods or products. task-4461531
7 changes
Resolved issues and error corrections
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
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
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
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