Daily updates from Odoo
Wednesday, November 19, 2025
13 changes · 17.0
Enhancements to existing features
This update makes delivery lookup by lot much faster by changing how the system gathers the needed information. It reduces delays for users working with many lots, especially in large stock operations, so screens and processes complete more quickly.
Original PR description
### Description: This refactoring replaces the recursive calculation in `_find_delivery_ids_by_lot` with an iterative process. This change significantly reduces the amount of database queries by prefetching and batching all required lines in a single pass, and it also eliminates the overhead caused by repeated recursive function calls. ### Benchmark: | Total Lots | Before | After | |------------|--------|--------| | 69 | 1 sec | 106 ms | | 1152 | 1 min | 5 sec | ### Reference: opw-5096599
Resolved issues and error corrections
This update keeps Odoo working with newer code-quality checks by adjusting a few internal patterns and test files. It also reduces false alarms during validation, helping teams run maintenance checks more smoothly and reliably.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives.
This change removes repeated method definitions in a few enterprise modules. It does not add new user-facing features, but it helps keep the codebase cleaner and reduces the risk of maintenance issues later.
Original PR description
found by pylint 4
Odoo now uses the updated official code for Odisha in India, replacing the older code. This keeps contact and sales information aligned with current government standards and helps avoid mismatches when creating customer records and sales orders.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633**
Blog post paragraphs will now inherit the font size set in the website theme. This makes blog content match the site’s design settings and keeps formatting consistent across the page.
Original PR description
Previously, changing the paragraph font size in the theme (Website > Edit > Theme > Paragraph > Font Size) did not affected the paragraphs within blog posts. This was because blog post paragraphs used a static font size, overriding the theme's setting. This PR removes the overriding style, allowing blog post paragraphs to inherit the font size defined in the theme. task-4167716
This change prevents an empty “Column” options panel from appearing when editing media list snippets on the website. It also stops the edit overlay from covering items when there are no relevant settings to show, making the editing experience cleaner and less confusing.
Original PR description
Steps to reproduce [A]: - Go to website ("edit" mode) > Add a new "Media List" snippet. - Select one of the snippet items > An empty "Column" options section will appear on the sidebar and an overlay…
Steps to reproduce [A]:
- Go to website ("edit" mode) > Add a new "Media List" snippet.
- Select one of the snippet items > An empty "Column" options section
will appear on the sidebar and an overlay will be covering the item.
After [1], grid layout options were updated to be able to set grid items
padding individually, the new snippet option used for that
(see: `GridColumns`) is targeting every `.row > div` and uses the widget
visibility code to be sure that the option is available only in "Grid"
mode, which leads to the behaviour described above.
There is already an implementation to prevent sections with hidden
widgets from being visible (see: `updateOptionsUIVisibility()`) and
adapt the overlay accordingly, but it only handles specific situations:
[B]- The implementation on [2] (used to move the switchable views to a
`SnippetOption`) led to a situation where an empty "Page Options" editor
was visible on every page.
[C]- This visible section issue from [B] was fixed (see [3]) by hiding
the `snippetEditor` if none of its options are visible (including the
`we-top-button-group` options).
[D]- Even with a hidden "Page Options" `SnippetEditor`, its overlay will
always be visible (with an empty options tab) when the `<main/>` element
is clicked. The code from [4] fixed a specific situation of the issue:
The code will hide the overlay only if there are no options at all
(`customize$Elements === null`), which is the case for `SwitchableViews`
(e.g. for a `SnippetEditor` with parent editors, we only need to hide
the overlay if its `$optionsSection` is empty).
The goal of this commit is to fix the behaviour described in [A] in two
simple steps:
- Allow hiding the `snippetEditor` even if it contains visible
`we-top-button-group` options, since an editor with no
`we-customizeblock-option` is enough to prevent its visibility (also,
the fix in [3] was specifically introduced to hide the "Page Options"
editors).
- Generalize the check from [4] to hide the overlay of every editor with
an empty options section.
[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
[2]: https://github.com/odoo/odoo/commit/69af7dcfeb3ff95c40b00ef0cc7c5c0e4021f9d2
[3]: https://github.com/odoo/odoo/commit/39d073ccafddf4b3fbe9ec9f5f11849d77c9bdaa
[4]: https://github.com/odoo/odoo/commit/fccac358dae7092c8c7cd90ba1ee89c712bc86e9
task-3658153This fix prevents WhatsApp setup from failing when it references an archived user account, such as an inactive administrator account. It helps ensure the module installs smoothly without requiring someone to reactivate a user first.
Original PR description
The current constraint on `notify_user_ids` fails if the linked user is archived, as `active_test=True` (default) prevents reading archived records. This issue is notable on SaaS when installing WhatsApp since the default template phone record's user is the admin account, so if the admin user is archived it will cause the install to error out. By explicitly disabling `active_test` in the constraint, we ensure that archived users can still be read during this validation, preventing false negatives and allowing the module to be installed without requiring admin reactivation. opw-5006472
This fix removes an error that prevented users from generating a debit note from an existing credit note. It makes the correction flow work as expected, especially for localizations that rely on debit and credit notes to adjust posted invoices.
Original PR description
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo…
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. ### Steps to reproduce the error. 1. Install the Argentine localization 2. Create an invoice and post it 3. From the invoice using the wizard create a credit note and post it. 4. From the credit note open the wizard to create a debit note. 5. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. ### Current behavior before PR: When creating a debit note from a credit note get an error. ### Desired behavior after PR is merged: We can create a debit memo from a credit note. Adhoc tiket 69428 - 69854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a crash that could happen when the same serial number was reserved on more than one rental delivery. It improves the reliability of rental order processing and avoids errors when checking whether a reserved item is still available.
Original PR description
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide…
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide the "Reserved Lot" field, select the lot created earlier, and confirm 5. Open the Delivery(Stat button), assign lots to both deliveries 6. Create a second rental order (same or different user), assign the same lot, confirm, and process delivery 7. Create a third rental order, enter the same reserved lot → traceback occurs Issue: - Traceback with error `ValueError: Expected singleton: stock.move(88, 90)`. Cause: - The compute method `_compute_available_reserved_lots` accessed `move_id.date_deadline` directly, assuming a singleton. When multiple stock moves existed for the same lot, it triggered a singleton error. - When the same lot is linked to more than one delivery, the system crashed when checking available reserved lot. Solution: - Handled multiple stock.move.line records per lot by iterating over them instead of assuming a singleton. - Replaced direct access to move_id.date_deadline with an any() check to safely evaluate deadlines. - This prevents singleton errors when the same lot is linked to multiple deliveries and ensures correct availability calculation. opw-4963263
This update prevents receipt registration errors with some Swedish blackbox devices. The system now checks which protocol version the device supports before sending commands, so it only uses features the device can handle.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448
This change makes timesheet entries linked to a reversed invoice editable again. It fixes a case where users could not update recorded hours even though the original invoice had been reversed, which helps keep billing and time tracking accurate.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#201921
When users search on website pages, the system now checks whether the current page exists for that search. If the user is beyond the last available page, they are automatically redirected to the final valid page so results and pagination display correctly.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556
This update prevents users from manually changing the reply address on email templates unless it is intentionally configured. It helps keep customer replies linked to the right records and reduces email delivery problems caused by incorrect addresses.
Original PR description
Prior to this commit, the `reply_to` field on email templates (`mail.template`) was fully editable by users. This frequently led to misconfigurations where users would manually enter incorrect email…
Prior to this commit, the `reply_to` field on email templates (`mail.template`) was fully editable by users. This frequently led to misconfigurations where users would manually enter incorrect email addresses, bypassing the system's default catchall behavior. This resulted in: 1. Lost communication history: Replies were sent to private emails instead of routing back to the document chatter. 2. Deliverability issues: Manual values often failed SPF/DMARC checks, causing emails to bounce or land in spam. This commit addresses the issue by: 1. Modifying the `mail.template` form view to hide the `reply_to` field when it is not set (`invisible="not reply_to"`). This aligns the form behavior with the preview wizard and prevents users from accidentally overriding the system default on standard templates. 2. Setting the `reply_to` field to `readonly="1"` on the technical email message view to prevent manual tampering with emails already in the queue. opw-4894020 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr