Monday, August 4, 2025
14 changes · saas-18.3
Enhancements to existing features
The eWay Bill PDF has been tidied by removing extra punctuation from address section labels and aligning key table information more consistently. This makes the document easier to read and present to customers, suppliers, and compliance stakeholders.
Original PR description
In this commit: --- - Removed unnecessary '::' from 'Dispatch From' and 'Ship To' labels. - Center-aligned table data in the Goods Details and Vehicle Details sections. Forward-Port-Of: odoo/odoo#221419
Resolved issues and error corrections
Spanish VeriFactu POS now checks the configured simplified invoice limit instead of relying on a fixed €400 threshold. This keeps invoice handling aligned with current localization settings and reduces the risk of incorrect simplified invoice decisions.
Original PR description
In 18.0+ there is a field that determines the amount up to which an invoice can be simplified (`l10n_es_simplified_invoice_limit`). After this commit we use that instead of the hardcoded limit of 400 € that was used in 17.0. task-None Forward-Port-Of: odoo/odoo#221347
Portal users who follow a project task can now open the task from the “View Task” link in notification emails. This fixes a permissions issue that prevented the link details from being read, improving access for external collaborators.
Original PR description
To reproduce: ============= - on a project task where a portal user is follower send a message - the portal user should receive an email with a link to the task on the button "View Task" -> the link is not working Problem: ======== starting from 18.3, a method to check field access was added to the project task model, `access_token` and `access_url` were not in set of readable fields for portal users, so the link was not working. Solution: ========= add `access_token` and `access_url` to the set of readable fields for portal users. opw-4939913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The delivery package type list now respects the sequence set by inventory users instead of showing items by creation order. This makes package selection more predictable and aligned with the configured business workflow.
Original PR description
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for…
#### Step to reproduce: - Go to Inventory > Configuration > Settings and enable Packages - Go to Inventory > Configuration > Package Types - Inverse the order of two packages types. The goal is for the sequence order to differ from the id order. (you can display id with studio) - Go to Inventory > Overview > Delivery Orders - Create a new delivery order - Add a line - In 'Additional Info' add a Carrier - Go to Barcode > Operations > Delivery Orders - Select the delivery order (you might need to remove filters) - With the 'Add Product' button add a product - Click on 'Put in Pack' - A 'Package Details' wizard should have opened. In this wizard there is a field 'Delivery Package Type'. #### Current behavior: - In the delivery package type dropdown list, packages are ordered by id #### Expected behavior: - In the delivery package type dropdown list, packages should be ordered by sequence #### Cause of the issue: As no order was defined, stock.package.type was ordered by id which is the default behavior opw-4824064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220327
Archived time off types are now hidden from the Employee app, so employee profiles only show active and relevant time off balances. This prevents outdated or inactive leave categories from confusing HR teams and employees.
Original PR description
In this bug, if a time off type is archived, it is still displayed in employee app. Steps to reproduce the bug: 1- Create a database with employee and time off modules installed 2- Allocate a time off to an employee 3- Archive the time off type 4- Open Employee app and go to the employee profile 5- The archived days are still displayed opw-4900060 Forward-Port-Of: odoo/odoo#221335 Forward-Port-Of: odoo/odoo#217517
This fixes a crash in the Indian localization when a company removes its VAT/GST number and then uses the GST warning update action. Users can now leave the VAT field empty without encountering an error, improving stability in company tax setup workflows.
Original PR description
Currently, a traceback is occurring when the user clicks on the update button of GST warning after removing the vat. To reproduce this issue: 1) Install l10n_in 2) Open the Indian company 3) Change…
Currently, a traceback is occurring when the user clicks on the update button of GST warning after removing the vat. To reproduce this issue: 1) Install l10n_in 2) Open the Indian company 3) Change the VAT to get the GST warning 4) After getting the GST warning remove the VAT and click the `update it` button Error:- ``` TypeError: 'bool' object is not subscriptable ``` On company, VAT is not a required field, so the user can indeed remove it. When the user removes the vat and clicks on the `update it` button from GST warnings, the `action_update_state_as_per_gstin` method triggers. https://github.com/odoo/odoo/blob/c96d2b1d1ee917b1c665842010c56c23df91ccd3/addons/l10n_in/models/res_partner.py#L99-L101 From the above method we try to access the vat value. Here in our case, the `VAT` value is False. So it leads to the above traceback. We can resolve this issue by adding check, which makes the code more robust. sentry-6151570042 Forward-Port-Of: odoo/odoo#190840
Updating a blog cover image or filter now avoids saving unintended changes to the underlying website template. This helps prevent duplicated styling information and keeps blog pages stable after editing cover images.
Original PR description
Since summernote was replaced by the editor, the record cover template becomes `o_dirty` and therefore gets saved when a cover image is changed. This commit solves this by marking the record cover components readonly inside the DOM. Steps to reproduce: - install website_blog - set a blog cover image or specify its filter - save => The `record_cover` template was saved with the modifications, thus combining `t-att-style` and `style` attributes. task-jke Forward-Port-Of: odoo/odoo#219013
This fix prevents an error when validating a returned delivery linked to a sales order whose original line was deleted. It helps users complete stock return workflows reliably, even after a sales order has been cancelled and changed.
Original PR description
The error occurs when a SO line is deleted, and a return is processed for the associated delivery using a different product, after which the return is validated. Steps to reproduce: --- - Install the `sale_management` and `stock` modules - Create & Confirm an SO for one product - Now cancel that SO and remove that product - In Stock > Deliveries > Open that delivery(Cancelled) - Click on the `Return` button and add any product > Return > Validate Traceback: --- `ValueError: max() iterable argument is empty` At [1], a ValueError is raised because there are no SO lines, resulting in an empty sequence is being passed to the max() function. [1]- https://github.com/odoo/odoo/blob/deab3cafc8b3cd79dcc52fddd9511a38a7e77afa/addons/sale_stock/models/stock.py#L68 sentry-6709665025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting system logs now keep error messages in a consistent original language, making issues easier to investigate across different language settings. User-facing error messages remain translated, so day-to-day users continue to see messages in their preferred language.
Original PR description
Currently, error messages in logs are translated, which can make it difficult to debug issues — especially in multi-language environments or when analyzing logs programmatically. This commit ensures logs use the original, untranslated message templates for clarity and consistency, while keeping translations for user-facing errors. sentry-6763108230 Forward-Port-Of: odoo/odoo#221498
The Website settings label for Google Search Console has been corrected from an awkward word order to the proper product name. This makes the setting clearer for users configuring Google Search Console integration.
Original PR description
Before this commit, the Google Search Console label in the settings was wrongly displayed as "Console Google Search". This commit replaces this field label with "Google Search Console". task-3839274 Forward-Port-Of: odoo/odoo#182790
Invoice and sales email subtitles now avoid displaying “False” when sent to invoice-address contacts without a contact name. This keeps customer-facing emails cleaner and more professional in common accounting and sales workflows.
Original PR description
**Steps to reproduce:** 1. Install *Accounting* and *Contacts*. 2. Create a company contact with a name & address. 3. Add a child contact: Type = “Invoice address” **Leave the Contact Name blank** 4. Configure an outgoing mail server. 5. Create & confirm a customer invoice for created invoice‑address contact. 6. Click Send, send the invoice email, and check subtitle — it displays `False`. **Issue:** - When the invoice is emailed to a contact without a name, the email subtitle shows False, for example: `INV/2025/00006 - False` **Note: Same issue for Sales** **Cause:** - The rendering logic only checked that `partner_id` existed, not whether `partner_id.name` was non‑empty - Since name was not mandatory for address-type Invoice Address, this resulted in `False` appearing in the email subtitle. **Solution:** - Add an check for the validity of partner_id.name when generating the email subtitle. **opw-4939158** Forward-Port-Of: odoo/odoo#219881
Fixed an issue where administrators could not preview certain subscription sale orders if no salesperson was assigned in website settings. This prevents an error page and keeps subscription order review working normally after portal purchases.
Original PR description
**Steps to reproduce:** 1. Install sale_subscription, payment_demo and eCommerce 2. Go to Website → Configuration → Settings and clear the Salesperson field 3. Create a subscription product with recurring plan and publish it. 4. Place an order for this product as a portal user and complete payment. 5. Log back in as admin, open the related Sale Order, and click Preview **Issue:** A traceback occurs:- ```"ValueError: Expected singleton: res.users()"``` This happens in _prepare_partner_addresses because user_id is not set on the Sale Order. **Cause:** https://github.com/odoo/enterprise/blob/6b449769d4bf2cdf6517a026706fd6ea55832975/sale_subscription/controllers/portal.py#L233 The code calls has_group on order_sudo.user_id without checking if user_id exists, leading to an empty recordset and singleton error. **Solution:** Add a fallback to handle cases where user_id is not defined, defaulting to False for multiple_addresses_enabled. opw-4947508
This fixes an error that could occur when a user manually entered a tracking reference for a Sendcloud delivery. Instead of crashing, the system now handles missing Sendcloud parcel data cleanly and shows the normal user-facing error flow.
Original PR description
**Steps to reproduce:** 1. Install delivery_sendcloud. 2. Create a new shipping method (Inventory -> Configuration) - Provider: sendcloud - Put the public and secret key - Assign Delivery Product 3.…
**Steps to reproduce:** 1. Install delivery_sendcloud. 2. Create a new shipping method (Inventory -> Configuration) - Provider: sendcloud - Put the public and secret key - Assign Delivery Product 3. Create a sales order with a deliverable product 4. Confirm the sale order 5. Go to the delivery 6. Manually enter a random tracking reference. 7. Make sure carrier is set to the Sendcloud delivery method 8. Click on "tracking," or get back to the sales order (click "preview"). 9. A traceback occurs. **Issue:** `A TypeError: 'bool' object is not subscriptable` when accessing sendcloud_parcel_ref, which is expected to be a list or JSON but is instead a boolean. **Causes:** The code assumes the presence of valid Sendcloud parcel reference data, but manually entering a tracking reference bypasses the [_send_shipment](https://github.com/odoo/enterprise/blob/6ecf0af6b6874460d300ede6cc7c092927607810/delivery_sendcloud/models/sendcloud_service.py#L102) method that populates this field. As a result, sendcloud_parcel_ref can remain False. https://github.com/odoo/enterprise/blob/df924ef8adffb3e42419a44ecf22fec3059917c4/delivery_sendcloud/models/delivery_carrier.py#L196 **Solution:** Return None if there is no Sendcloud parcel reference, which will raise a UserError from the below line https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L288 Co-Author By - alsh@odoo.com opw-4894677 Forward-Port-Of: odoo/enterprise#89444
Fixed an issue that could cause spreadsheet thumbnail updates to fail when several records were processed at the same time. This improves reliability for users working with spreadsheet-linked records, such as sales order spreadsheets.
Original PR description
The `_inverse_display_thumbnail` method raised a `ValueError` when called on multiple records, due to direct access to `self.display_thumbnail` on a multi-record recordset. Traceback: `ValueError: Expected singleton: sale.order.spreadsheet(43, 44, 45, 46)` At [1], the code now correctly iterates over each `spreadsheet` in `self` to ensure accurate processing for each record. [1]- https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/spreadsheet_edition/models/spreadsheet_mixin.py#L619 sentry-6615551353