Daily updates from Odoo
Monday, October 20, 2025
31 changes · 18.0
New functionality added to Odoo
This change appears to add or adjust email logging in Odoo's messaging area, helping businesses keep better records of communications. The file list also includes many module manifest updates and unrelated stock/web changes, so the business impact is likely limited unless the email logging behavior is activated in daily workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update simplifies how accounting tax calculations handle grouped tax details in the browser. It reduces the need for extra manual setup in the code, making tax-related interfaces easier to maintain and less prone to implementation mistakes.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves and fixes Odoo's Hoot unit testing tools while keeping changes limited to the test ecosystem. It helps maintain more reliable automated testing without affecting normal business workflows or end-user features.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/231263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Luxembourg payroll rules have been updated with the 2025 minimum social salary and related tax credit values. This helps ensure employee payslips and payroll calculations reflect the latest official rates.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf task-5176255
Peruvian customer addresses no longer require a ZIP code because ZIP codes are not widely used in Peru. This makes customer data entry easier and avoids unnecessary validation issues for businesses working with Peruvian contacts.
Original PR description
As ZIP codes are not widely used in Peru, the requirement for a ZIP code to be provided for a Peruvian customer should not be present. task-5012593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223157
Estonia VAT report XML exports have been optimized to handle large accounting periods without timing out. The change reduces repeated processing, allowing very large monthly reports to complete successfully and improving reliability for businesses with high transaction volumes.
Original PR description
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this…
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors. Behavior after: Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets. Root cause: The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation. Benchmark: | Period size (journal items) | Before patch | After patch | |----------------------------------------|----------------------|--------------------| | ~15k | 7s | 5s | | ~200k+ | Timeout error| 21s | opw-5046077 Forward-Port-Of: odoo/enterprise#95047
Resolved issues and error corrections
This fix avoids adding extra partner identifiers to electronic invoice files when local validation rules only allow one. It helps prevent rejected invoices or refunds in affected EDI formats, improving reliability for businesses using electronic invoicing.
Original PR description
odoo/odoo#206655 added the partner ref in the party identification nodes, but most rule sets don't accept multiple ids for a single partner party identification. Commit 4e22e6b already fixed the issue for malaysian edi. so instead of calling super and extending, we do full overriding with no delegation for `_get_partner_party_identification_vals_list`. enterprise: https://github.com/odoo/enterprise/pull/87298 no-task
Payment registration now looks up saved payment methods using the customer linked to the invoice, rather than the company partner shown on the payment line. This ensures previously saved payment tokens are offered correctly when registering payments for company users, reducing failed or manual payment processing.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#230105
This fix ensures Swiss payroll ELM transmission employee information works correctly when more than one company or country setup is used. It helps businesses avoid incorrect or missing payroll-related data in multi-company Switzerland configurations.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#96733
Fixed an issue that could cause an error when appointment availability was refreshed for bookings assigned to a staff member. This improves reliability for customers and staff using appointment scheduling by ensuring capacity checks do not interrupt the booking flow.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#95862
This update removes a browser option that was causing Point of Sale connections to IoT devices to fail on some older Chrome versions. It keeps the intended local device communication working while reducing avoidable errors for businesses using POS hardware.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232110
This change removes an unnecessary browser request option from IoT and point-of-sale IoT communication. It prevents errors in older Chrome versions while keeping local device communication working as before.
Original PR description
This reverts commit 6d09dc6 which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 Forward-Port-Of: odoo/enterprise#97500
The mail composer now handles failed file uploads without causing an error screen. This avoids disruption for users composing messages when an attachment cannot be uploaded.
Original PR description
Before this commit, when a file upload in the full composer would be fail, it would result in a traceback. This happens because we would try to access the attachment resulting from the upload, which is however undefined when the upload fails. This commit fixes the issue by guarding the access of said attachment. task-4778468
Improved the spacing of debug-mode menu option fields on event and event type forms, making it easier to match each label with its related setting. This helps administrators configure event website page menus with less confusion.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239
Fixes crashes that could happen when users rapidly drag and drop cards in large grouped Kanban views. The change makes drag-and-drop safer during screen refreshes, helping users continue working without interruptions in busy boards.
Original PR description
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this…
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this commit, different crashes could occur. The first category of crashes concern the sortable hook. It called the onDrop callback even if the dragged element was no longer in the DOM (which occurs if there's a re-rendering while the user is dragging). This has been fixed in the hook, and tested. Another crash could arise in kanban (in the model). If the user dropped the card while there was a scheduled/ongoing re-rendering, i.e. at a specific moment where the model isn't synchronized with the DOM, the dropped card was still in the DOM, but it's associated datapoint was no longer referenced in hte model. In that case, we can do nothing but cancel the d&d. Note that this couldn't be tested, as reproducing the exact behavior (typically having a slow rendering due to the number of cards to render) isn't possible in a unit test, where user interactions are done programmatically. Task~5167650 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures United Kingdom supplier records are reported with the correct country code in Mexico's DIOT tax report. It prevents UK-related transactions from being grouped under “Other country,” improving reporting accuracy for compliance reviews.
Original PR description
The DIOT country adaptation map lacked the ISO 3-letter code for the UK, causing records with country 'GB' to be reported as 'ZZZ' ("Other country").
Added mapping 'GB' → 'GBR' to ensure correct DIOT country code generation.
Forward-Port-Of: odoo/enterprise#96771Customers who navigate back during checkout and choose another delivery address are no longer shown an error. If the cart is no longer available, the site now sends them safely back to the shop so they can continue browsing or restart checkout.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801
Calendar activity feedback is no longer added to the meeting description when an activity is marked done. This prevents internal notes from being synced to external calendars or triggering unnecessary meeting updates, while keeping the feedback available in the chatter.
Original PR description
When marking a calendar.event activity as done, one can submit a feedback. Currently, that feedback is logged in the chatter, and is also appended at the end of the meeting's description. As this field is synchronized with external calendars, this may lead to notification / meeting updates. However, this should serve an internal purpose instead, and should not be shared to attendees in that way. Therefore, simply remove this behavior. The feedback will still be found in the note in the chatter. Task-5143141
This fix ensures that Italian point-of-sale transactions still print the required receipt when the cash drawer option is enabled. It prevents a checkout issue for businesses using Italian fiscal printers, helping sales complete smoothly and compliantly.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480
Fixed taxes on invoices with negative-priced products now correctly become negative as well. This prevents overstated tax amounts on refunds, discounts, or other negative invoice lines and keeps accounting totals accurate.
Original PR description
Steps to reproduce: 1. Create a fixed tax 2. Create a invoice with a product with negative price Problem: The amount of the tax is positive while the line is negative. opw-5128767
The Documents app now correctly applies debug mode changes made through the command palette. This fixes a navigation issue so users can switch debug mode without manually editing the URL.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056
Invoice terms and conditions now update automatically when a customer's language is changed during invoice creation. This helps ensure customers receive invoice text in the correct language without needing to recreate or manually adjust the invoice.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933
Users who choose to handle notifications inside Odoo could receive the same browser push notification twice when they had an Odoo tab open. This fix prevents duplicate alerts so users receive a single, clearer notification for each message.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes an issue where reconciling journal items could fail when a company had customized the default journal entry type. The reconciliation wizard now consistently creates write-offs as standard journal entries, preventing avoidable errors about missing partners or account type restrictions.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97028
Customers receiving Gelato shipping notifications now get a working tracking link for single-parcel shipments. This prevents broken links in delivery emails and helps customers follow their orders more reliably.
Original PR description
After receiving the shipping webhook from Gelato, we send a shipping notification with the tracking information to the customer. This commit fix the tracking url for single parcel, which was pointing to an inexistant url. opw-4637331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website form fields that are still in use can no longer be deleted from the underlying model. This prevents page editing crashes and guides users to remove the field from the form before deleting it.
Original PR description
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom…
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom field` on a model(for example, a field on the `mail.mail` model). - Website > edit > `add Form` widget to a page, and configure it to use the `mail.mail` model. - Add the newly created custom field to the form and save the page. - Now, `delete` the custom field which is created previously. - Return to the website page > edit > mark the deleted field as required, and attempt to save the changes. **Error:-** `ValueError: Unable to whitelist field(s) [''] for model 'mail.mail'.` **Root cause:-** - At [1], we can see that in the current version, it `only logs an error` using the logger, but in later versions, it `raises a ValueError` instead. **Solution:-** - This fix prevents a field from being deleted if it is actively used in any website form. - It adds a validation check that blocks the deletion and raises an error, forcing the user to remove the field from the form first. [1]: https://github.com/odoo/odoo/blob/d4f424d731fa93ccd232d0def0a7612997345ef7/addons/website/models/website_form.py#L123-L126 **sentry-5689731444** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the Spanish Facturae electronic invoicing tax information is loaded for the right Spanish tax templates, including mainland and Canary Islands setups. It prevents unrelated taxes from receiving an incorrect default electronic invoicing tax type, improving accuracy for compliant invoice reporting.
Original PR description
Currently the tax data defined in l10n_es_edi_facturae is incomplete and never loaded. This commit makes sure that the l10n_es_edi_facturae_tax_type is loaded correctly and adds the appropriate templates for es_common_mainland and es_canary_common. The default is also removed on the field l10n_es_edi_facturae_tax_type to avoid the value being assigned for unrelated taxes. task-4981325
The main menu search field now tells browsers and password managers not to offer autocomplete suggestions. This prevents unwanted Bitwarden popups from covering the menu while keeping Odoo's own search suggestions unchanged.
Original PR description
Bitwarden pops up small form on top of the main menu for no reason. It is because of the hidden input created to trigger search when you type. Put `autocomplete="off"` to avoid these popups, as the search feature handle its own autocompletion. Note: this commit is a backport of odoo/odoo@403d7b70ab16b8b70ea46aa692883c7b4a6e83b7 Forward-Port-Of: odoo/enterprise#97506
Documentation and clarification updates
Acsone has added Tobias Zehntner to Odoo's contributor records after confirming the required contributor agreement. This is an administrative legal update that helps keep contribution permissions and acknowledgements accurate.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update records that contributor arch-fan has signed the required Contributor License Agreement. It supports legal compliance for accepting their contributions and has no direct impact on product features or users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232057
The contributor list has been updated to include Acsone/Tobias Zehntner as having signed the required contributor agreement. This helps keep Odoo's contribution records complete and supports clear legal governance for future contributions.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr