Daily updates from Odoo
Friday, July 3, 2026
9 changes · 17.0
Resolved issues and error corrections
This update ensures that lot numbers are consistently applied to incoming stock movements created during Point of Sale refunds. Previously, the system wasn't correctly reusing the original lot number when a refund was processed, leading to inconsistencies in inventory tracking. This fix maintains accurate lot number traceability for products, improving inventory management.
Original PR description
Steps: ---------- - Install point_of_sale. - Create a trackable product with a lot and add an on-hand quantity. - Open a PoS config with "Ship Later" enabled. - Place an order for the trackable product with a lot and ship later, then validate the delivery picking in Inventory. - Refund the previous order from PoS and ship later, and check the receipt in Inventory. Issue: --------- - The delivery picking correctly assigns a lot number, but the corresponding receipt created during the refund does not. Cause: --------- - The system was not reusing the existing lot number when the picking type was incoming. Fix: -------- - Ensure the existing lot number is assigned to incoming pickings created during refunds. task-5005122
This update resolves an issue where PDF invoices from Nilvera were being corrupted due to incorrect storage. The fix ensures PDFs are properly decoded and stored as valid files, preventing invoice processing errors. This improves the reliability of invoice generation and submission.
Original PR description
## Short fix summary: The PDF fetched from Nilvera comes back as a base64 string. It was stored verbatim in the attachment's `raw` field (no decoding), producing a corrupt PDF. Store it in `datas`…
## Short fix summary: The PDF fetched from Nilvera comes back as a base64 string. It was stored verbatim in the attachment's `raw` field (no decoding), producing a corrupt PDF. Store it in `datas` instead, which base64-decodes its input into a valid PDF. ### How it slipped in The mocked test for PDF fetching never mirrored the real API response: it returned raw bytes instead of the base64 string Nilvera actually sends, and asserted nothing about the stored file. Because the mock misrepresented the response, a later fix for a `binascii.Error` on Python 3.14 was applied in the wrong layer, switching the attachment field from `datas` to `raw`. That silenced the error but stored the base64 text undecoded, corrupting the PDF. The mock on the test will be corrected on Forward port of 18.0 onward. ### Related PRs - **#266718** — introduced the regression: switched the attachment field from `datas` to `raw` to silence a `binascii.Error` on Python 3.14, but stored the base64 text undecoded, corrupting the PDF. - **#246884** — added the mocked test suite that misrepresented the Nilvera `/pdf` response (raw bytes instead of a base64 string), which masked the bug and made the wrong fix in #266718 appear correct. task-6312640 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a formatting issue in the Hindi language setting within Odoo. It now correctly applies Indian-style number grouping (e.g., 1,54,75) for numerical displays, ensuring accurate representation of financial data for users in India. This improves clarity and consistency for Hindi-speaking users.
Original PR description
Currently the Hindi language used no number grouping at all. This commit sets the number grouping for Hindi to Indian style, like `1,54,75,317.70` e.g. [task-6320391](https://www.odoo.com/odoo/project.task/6320391)
This update corrects a visual issue where the background color of the account type selection dropdown remained in light mode when dark mode was enabled. The change ensures the dropdown background adapts correctly to the overall dark mode theme, providing a consistent and visually correct user experience. This improves the usability of the account module in dark mode.
Original PR description
Steps to reproduce: - Install `account` module - Enable dark mode - Open `view_account_form` to create a record - On the Accounting page, open type dropdown - The dropdown background remains in light mode This commit applies $dropdown-bg on `o_field_account_type_selection` as in odoo/odoo@0cd148eb389078c896aaa719af5733d05377fd1c
This update resolves a problem where automation rules on sales orders were failing due to an incorrect handling of messages. The fix ensures that automation messages are processed correctly, preventing errors and maintaining the expected behavior of sales order workflows. This improves the reliability of automated tasks.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install `industry_fsm_sale` and `base_automation` modules 2. Create a product with: * Type: Service * Create on order: Task * Project:…
Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
* Type: Service
* Create on order: Task
* Project: Field Service
3. Create an automation rule with:
* Model: Sales order
* Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
* Change the quantity to 2 or more
Observation:
----------------------------------------
Traceback occurs:
```
File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```
Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`
Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on
opw-6276916This update corrects a minor error in the turnstile template that prevented users from consistently selecting the desired display mode. The fix ensures the ?cf=show path correctly controls the turnstile's appearance, improving the user experience. This is a standard maintenance update for the 17.0 release.
Original PR description
Stable forward-port source patch. Issue - The turnstile template uses a misspelled variable name in data-appearance: appeareance. - JS provides appearance. - Because of this mismatch, data-appearance always falls back to interaction-only and ?cf=show cannot force always mode. Fix - Replace appeareance with appearance in the turnstile template. Why stable-safe - One-line template fix. - No API/model/signature changes. - No behavior change outside the intended appearance selection. This is intended as the 17.0 source fix so forward-porting can propagate to upper versions. Related: odoo/odoo#273306 and odoo/odoo#273652
This update corrects a display issue where the shipping address option remained visible on the website even when shipping addresses were disabled in the settings. The fix ensures that the shipping address field is hidden correctly when this setting is toggled, improving the user experience and preventing confusion.
Original PR description
Issue: --- Shipping address option will be still shown if the shipping address is disabled in setting. Steps to reproduce: 1- Disable shipping address in setting. 2- Navigate to shop and checkout using a public user. You can see when filling address, the shipping address option is still shown. Cause and Fix: --- The group is not added to `Ship to the same address` checkbox. Even if we add the group, the whole t-if/t-else block will not be taken, and we need explicitly set use_same when the group is not present. opw-6193161
This update fixes a bug where GIF images weren't visible in the feed comment modal. The system now correctly displays GIFs from Facebook, ensuring users can share richer content within the feed. This improves the user experience and allows for more engaging comments.
Original PR description
Bug === When opening the comments modal of the feed view, the GIF images are not visible. Technical ========= The API does not return the GIF, it only returns the MP4 and the JPG. So we show the fixed image, and when clicking on it, it opens the video on Facebook. Task-6241607 Forward-Port-Of: odoo/enterprise#118619
This update corrects a technical issue that was causing a misleading error message when generating invoices with Co-Contractant tax rates. The fix ensures the note is only added to the invoice when the tax amount is zero, accurately reflecting the Co-Contractant's fiscal position and avoiding unnecessary alerts.
Original PR description
We were raising a UserError because we were putting the note even if the tax amount was different from 0. But in fact, it can be normal to have 0% cocontractant tax and normal rate at the same time on an invoice, which would have the fiscal position Co-Contractant. So remove these UserError, but only apply the note when the tax amount is 0 opw-6302806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr