Daily updates from Odoo
Monday, November 24, 2025
14 changes · 17.0
Enhancements to existing features
This change makes Google Places autocomplete more flexible when searching for customer information. Businesses can now adjust the search type to better find locations or establishments, which should reduce cases where no result is returned for valid queries.
Original PR description
Description of the issue/feature this PR addresses: We use the google search autocomplete for completing our clients informations in the application Contact, but for some reasons almost all the times the autocomplete was not working, it was not able to find an address (the same query worked on google search engine). Current behavior before PR: On trying to search the business of a client by name, most of the time no result found. Desired behavior after PR is merged: I would be able to change the base behaviour of the google search api with a custom module by changing the parameter of the method, by changing the types from "address" to "geocode|establishment". This change will change nothing for thoses who don't need this improvement, because the old comportement was kept as a default parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds an index to the sales order team field, which helps Odoo find matching sales orders more quickly when users filter by sales team. It improves performance on large databases and reduces delays when opening or searching sales orders.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update replaces the specific name 'Uruware' with a generic 'UCFE Provider' in the Odoo settings for Uruguayan localization. This ensures customers contact Odoo support for assistance and maintains a consistent, clear configuration. The core functionality remains unchanged.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539
Resolved issues and error corrections
When a delivery line is split during barcode packing, the remaining line now keeps the original package information. This ensures products that started in a specific package continue to be tracked correctly, avoiding confusion and mismatches in stock handling.
Original PR description
Steps to reproduce ----- - Enable packages - Create a stored Product "Prod" - Add a quantity of 5 "Prod" in stock, in package "PACK1" - Create a delivery for 3 units of "Prod" (so as to not move the…
Steps to reproduce ----- - Enable packages - Create a stored Product "Prod" - Add a quantity of 5 "Prod" in stock, in package "PACK1" - Create a delivery for 3 units of "Prod" (so as to not move the whole package) - Open the delivery in Barcode - Scan "Prod" - Put in pack > The new line created for the remainder of the delivery is not taken from PACK1 Cause ----- Put in pack causes the line to be split since there is some remaining quantity https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_picking_model.js#L1586-L1593 Through which we create a new line https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L555-L559 With the origin package set as false by default https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L617-L624 ----- Ticket: opw-5081496
This fix ensures customers cannot return more rented items than were originally picked up. It keeps rental quantities accurate and prevents inconsistent order records that could affect billing and inventory tracking.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727
This update refreshes the spreadsheet component to its latest version and includes a couple of usability fixes. It prevents interactions in read-only spreadsheets and improves how the editor switches modes when the cursor or selection changes, reducing confusing behavior for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/498c3fcb1 [REL] 17.0.78 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/498c3fcb1 [REL] 17.0.78 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1e758de59 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/60a66b680 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Automatic payment follow-ups will now use an active user instead of an archived one when choosing who sends the message. This prevents errors and avoids follow-ups being sent under inactive staff accounts.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159
The Romanian SAFT report was incorrectly using the supplier account for both customers and suppliers. This update ensures customer records are reported with the proper receivable account, improving the accuracy of the export and reducing the risk of incorrect tax/reporting data.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009
This change stops users from triggering the transfer validation action multiple times in Barcode before the first attempt finishes. It prevents duplicate stock lines from being created, especially when items without reservations are added to a transfer, which avoids inventory errors and incorrect quantities.
Original PR description
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696This change fixes a problem where invoice printouts could lose the exchange rate section when certain Gulf country localization modules were installed together. It helps ensure customers see complete and correct invoice details when using multiple regional settings in the same database.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents pasted text from being wrapped twice with the same formatting, which could make content look overly bold or otherwise over-styled. It keeps the final appearance consistent and avoids unexpected visual changes when editing rich text.
Original PR description
### Description of the issue/feature this PR addresses: - When pasting formatted content (like `<strong>` or `<font>`) into a region that already had same formatting, it caused nested identical tags, leading to exaggerated styling (e.g., "double bold"). ```html <!-- User pastes <strong>text</strong> inside <strong> --> <p><strong>text []</strong></p> <!-- Resulting HTML --> <p><strong>text <strong>text</strong>[]</strong></p> ``` ### Desired behavior after PR is merged: - Prevents unwanted style amplification by unwrapping nested identical formatting tags. ```html <!-- Resulting HTML --> <p><strong>text text[]</strong></p> ``` task-5138472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the XML generated for credit notes so it is accepted by Spain’s FACe validation service. It also simplifies the credit note reversal screen by removing a duplicated reason field, making the process clearer for users.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one.
This update resolves a memory issue that occurred when processing sales documents for Romania (RS) with the RS EDI module. By proactively fetching country codes, the system now avoids running out of memory, ensuring smoother and faster processing of these documents. This improves the overall efficiency of the RS EDI functionality.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change reorganizes how changes to a product’s standard cost are prepared and applied. It makes the process easier for other parts of Odoo to hook into, improving flexibility for future stock and valuation updates without changing the main business flow.
Original PR description
To make it hookable when some vaccum values of a product needs to be change a separate method and prepare values method was created This was split from the initial PR https://github.com/odoo/odoo/pull/160527 cc @pfertyk --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr