Monday, November 3, 2025
10 changes · 18.0
Enhancements to existing features
Users who are already registered as Peppol receivers in another Odoo database no longer need to manually deregister and start over. Odoo now detects the existing registration and sends a secure email link so they can transfer the Peppol connection to the current database more smoothly.
Original PR description
### Summary Previously, when a user attempted to **register as a Peppol receiver** while already registered through a different Odoo database, the system would raise a **User Error**. The user had to…
### Summary
Previously, when a user attempted to **register as a Peppol receiver** while already registered through a different Odoo database, the system would raise a **User Error**.
The user had to **manually deregister** and **re-register** from the desired database.
---
### New Behavior (After This Commit)
With this update:
- The system **detects existing Peppol registrations** across databases.
- Instead of raising an error, it now **sends an automated email** to the user with a **secure transfer link**.
- This allows the user to **migrate their Peppol connection** to the current database seamlessly.
---
### Flow Overview
```text
┌────────────────────────────┐
│ User initiates Peppol │
│ registration (becomes │
│ sender) │
└────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Check existing registration │
└────────────┬─────────────────┘
│
┌──────────────┴──────────────┐
▼ ▼
┌─────────────────────┐ ┌──────────────────────────────┐
│ User NOT registered │ │ User ALREADY registered |
│ in any Odoo DB │
└────────────┬────────┘ └──────────────┬───────────────┘
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────────┐
│ Proceed with normal │ │ Send email with transfer link│
│ registration flow │ │ to the user │
└──────────────────────────┘ └──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ User clicks transfer link
│
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ Peppol connection migrated
└──────────────────────────────┘
```
---
iap pr- https://github.com/odoo/iap-apps/pull/1236
task- 5023252This update adds quick search in the invoice list so users can find invoices by currency amount. It makes locating specific invoices faster and reduces manual scrolling or filtering.
Original PR description
Description of the issue/feature this PR addresses: Added quick search in invoice search view Current behavior before PR: Can not search invoice by currency amount Desired behavior after PR is merged: User is able to search by currency amount --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures website building snippets appear correctly when using Arabic or other right-to-left languages. It helps users edit website pages without missing content options due to layout positioning issues.
Original PR description
Steps to reproduce: =================== - Set arabic as default language for website - Try to add a snippet -> you can't see the snippets Cause: ====== Snippets were fetched correctly but were not visible. In RTL languages (like Arabic), the CSS `transform-origin` was set to 'top right', rendering the snippets off-screen. This is due to the browser's interpretation of positioning in RTL mode. For more details, see MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/ Properties/position Solution: ========= Force the snippet preview's position by setting `left: 0`. This ensures its positioning is always aligned to the left, regardless of the `transform-origin` value dynamically set by the browser in RTL mode. opw-5214703
This update fixes the way Chilean state names are displayed in customer addresses. It replaces placeholder numeric codes with the official country-standard codes, helping ensure addresses are accurate and consistent for users and integrations.
Original PR description
**Steps to reproduce:** 1. Go to Sales > Create and edit a new customer. 2. Select Chile as the country and choose a state. **Issue:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Cause**: - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. <img width="601" height="146" alt="image" src="https://github.com/user-attachments/assets/a941c200-467b-4ad5-8f79-ca9e8a92d7b4" /> <img width="443" height="131" alt="image" src="https://github.com/user-attachments/assets/dc1df1b0-2267-499f-ad1d-bb5c9381cd66" /> **Solution**: - Updated all state codes to match the official ISO 3166-2:IQ codes (Reference: https://www.iso.org/obp/ui/#iso:code:3166:CL) **opw-5148562**
This fixes an issue where a sales order line could keep an outdated Delivered Quantity Method after the related product’s service settings were changed. The field now refreshes correctly when product type or service-related settings are updated, helping keep delivery tracking accurate.
Original PR description
To reproduce: ============= - create SO with a product of service type 'manual' - go to product and change its service type to 'milestones' - go back to SO -> the field 'Delivered Quantity Method' is not updated Problem: ======== `qty_delivered_method` is a computed field depending only on `product_id`. When changing the service type of the product, the field is not recomputed. Solution: ========= Add dependencies on `product_id.type` and `product_id.service_type`. P.S: also added `is_expense` as dependency as it is used in the computation. opw-5096446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When bills are created from QR Vendor Scan or IRN fetching, Odoo now uses the GST treatment provided by Partner Autocomplete instead of defaulting to “regular.” This helps ensure vendor tax treatment is set correctly from the start, reducing manual corrections and tax-related mistakes.
Original PR description
Before this commit: We used to set `regular` treatment when using QR Vendor Scan or Fetching bill with IRN After this commit: We use the GST Treatment received from Partner Autocomplete to set the GST Treatment task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps scrap orders consistent when a user changes the product. If the new product has no valid Bill of Materials, the scrap BOM is cleared; if it does, the appropriate BOM is selected automatically, preventing quantity mismatches at validation.
Original PR description
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the…
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency. Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM. Steps to Reproduce on Runbot: 1. Create a scrap order for a product that has a kit type BoM and set the kit field. 2. Change the product to a product without a kit type BoM. 3. Validate the scrap order. 4. Observe the quantity field is set to 0, but there are product moves for the correct quantity. opw-5122880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231937
This fix improves how Swedish bank account numbers are identified when exporting partner bank details. It now correctly recognizes several valid account formats that were previously treated as invalid, reducing errors in exported data and helping ensure payments are handled correctly.
Original PR description
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the…
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the 'Accounting' page create a new bank account 1- 62074-0 2- 678653833066 3- 99603406872188 - In the partner list view select this new partner - Click Actions > Export, select "Banks" and "Bank Type" - Check the file 1- 62074-0 not recognized as Plusgiro 2- 678653833066 not recognized as BBAN 3- 99603406872188 not recognized as BBAN ### Cause: These numbers are not recognized by the checks of Odoo but are valid numbers: 1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers 2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers 3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969 ### Sources: 1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15 opw-5099867
This change fixes an access problem that prevented some Recruitment administrators from sending referral campaigns. Users with the right recruitment permissions can now complete the action without needing extra employee access rights.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344This update fixes a problem where some appointment pages could fail to load with a 404 error when the assigned staff member has flexible working hours. It ensures availability is checked correctly so customers can view the appointment details without interruption.
Original PR description
This PR fixes the 404 error displayed on the info page of a "Limit to Work Hours" appointment linked to a staff user with flexible hours. The availability of the staff user must not be computed from its work schedules as it has flexible hours. Task-5046134