Daily updates from Odoo
Tuesday, August 5, 2025
18 changes · master
Resolved issues and error corrections
This update fixes visual issues in Odoo Studio after a recent styling change. Sidebar headers and report editor undo/redo buttons now display correctly, helping users work with a more consistent interface.
Upsell invoices for yearly subscriptions now show the correct billing duration when a current partial period is followed by a full renewal period. This prevents customers from seeing misleading invoice line descriptions and helps keep subscription billing clearer and more accurate.
Original PR description
**Steps to Reproduce:** - Install `sale_subscription`. - Create a product (recurring product) with: - Type: Service - Invoicing Policy: Prepaid/Fixed Price - Create a subscription plan Yearly with: -…
**Steps to Reproduce:**
- Install `sale_subscription`.
- Create a product (recurring product) with:
- Type: Service
- Invoicing Policy: Prepaid/Fixed Price
- Create a subscription plan Yearly with:
- Billing Period: 1 year
- Align to period start: enabled
- Create and confirm a subscription for the product using the Yearly plan.
- Create and confirm the first invoice (shows remaining days like
185 days – 06/30/2025 to 12/31/2025 in product description).
- Create and confirm second invoice (check 1 year – 01/01/2026 to 12/31/2026).
- Go back to the subscription and create an upsell.
- Confirm the upsell and generate its invoice.
**Observation:**
- The upsell invoice line shows the wrong duration:
1 year (06/30/2025 to 12/31/2026).
- This is incorrect because the expected duration is:
185 days (from 06/30/2025 to 12/31/2025) + 1 year (01/01/2026 to 12/31/2026)
**Issue:**
- The duration calculation is based on the ratio of the first date and the end
date, but for the Upsell's ratio is always 1, so it considers fix duration,
i.e 1 year, 1 month
https://github.com/odoo/enterprise/blob/4bb43da79dba7ac1d0772fde814b3da6bade7db6/sale_subscription/models/sale_order_line.py#L346-L347
**Solution:**
- Corrected the logic to calculate the upsell duration by combining the remaining
current period (e.g., 185 days) with the standard 1-year period ratio.
Reference PR: https://github.com/odoo/enterprise/pull/68163/commits/cfed2d369960896f0f4d91a90eb24f3641627419
opw-4853426
Forward-Port-Of: odoo/enterprise#91362
Forward-Port-Of: odoo/enterprise#88963Fixes an issue where Mexican point-of-sale refunds failed when a gift card was used. Refunds can now correctly reload the gift card balance, preventing checkout errors and allowing legitimate positive gift card lines during refund transactions.
Original PR description
**Problem:** When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card. But when doing so, two problems arise: - In the case of a gift…
**Problem:** When trying to make a refund in Mexico, with a gift card in the order, the order should be refunded on said gift card. But when doing so, two problems arise: - In the case of a gift card, *line[2].refunded_orderline_id* is not set, so we are trying to read the property of an undefined variable. - Another problem is that the order can not have any line that have a positive subtotal in the case of a refund. This was not taking the gift cards into accounts, as it makes sense for them to be positive in such a case. **Steps to reproduce:** - Set your company to a Mexican company - Make a purchase for a gift card - Make another purchase for a random product - Start the refund process and enter the gift card code we created before - Try to finalize the purchase, a traceback appears - If we were not trying to read an undefined variable, the purchase would still not go through as some lines are positive in a refund **Why the fix:** When refunding with a gift card, we should refill the gift card by the order's cost instead. With this in mind, it makes sense for the gift card to have a positive price even though we are in the context of a refund, which usually only permits negative priced lines. opw-4892935 Forward-Port-Of: odoo/enterprise#91385 Forward-Port-Of: odoo/enterprise#89892
Sale order previews for subscription purchases now work even when no salesperson is assigned. This prevents an error screen for administrators reviewing paid subscription orders, improving reliability in eCommerce subscription workflows.
Original PR description
**Steps to reproduce:** 1. Install sale_subscription, payment_demo and eCommerce 2. Go to Website → Configuration → Settings and clear the Salesperson field 3. Create a subscription product with…
**Steps to reproduce:** 1. Install sale_subscription, payment_demo and eCommerce 2. Go to Website → Configuration → Settings and clear the Salesperson field 3. Create a subscription product with recurring plan and publish it. 4. Place an order for this product as a portal user and complete payment. 5. Log back in as admin, open the related Sale Order, and click Preview **Issue:** A traceback occurs:- ```"ValueError: Expected singleton: res.users()"``` This happens in _prepare_partner_addresses because user_id is not set on the Sale Order. **Cause:** https://github.com/odoo/enterprise/blob/6b449769d4bf2cdf6517a026706fd6ea55832975/sale_subscription/controllers/portal.py#L233 The code calls has_group on order_sudo.user_id without checking if user_id exists, leading to an empty recordset and singleton error. **Solution:** Add a fallback to handle cases where user_id is not defined, defaulting to False for multiple_addresses_enabled. opw-4947508 Forward-Port-Of: odoo/enterprise#91013
This fix prevents WinBooks accounting imports from failing when imported data contains special tax accounts, missing journal references, or accounts later marked as deprecated. It helps businesses complete legacy accounting data imports more reliably without manual cleanup or interrupted migration workflows.
Original PR description
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it…
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80 *Note* Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines **Issue 2** Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal **Issue 3** Account created during import may be marked for deprecation, which occurs at the end of the import process. However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error. https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028 opw-4850314 Forward-Port-Of: odoo/enterprise#91581 Forward-Port-Of: odoo/enterprise#89426
This fix aligns ESG date range fields with the correct date-based behavior instead of datetime handling. It removes unnecessary browser console warnings without changing the visible user experience.
Original PR description
The widgets `esgDateRangeField` and `esgListDateRangeField` inherit respectively from `dateTimeField` and `listDateTimeField`. As their name implies, those widgets are made to handle datetime fields, whereas the esg widgets are used on dates. While it does not seem to make a functional difference, it produces a warning in the browser console. This PR makes the esg widgets inherit from the "date" counterpart instead. Forward-Port-Of: odoo/enterprise#91646
This fixes an issue where AI-related email template customization could fail when Odoo was used in a language other than English. The update makes the template override independent of translated text, improving reliability for multilingual customers.
Original PR description
Texts are translated before template compilation so xpaths that depend on text content fails on odoo instances that use language aside from EN. We are now searching for the div inside the content page beside the attachment_ids field to find the div to replace. OPW: 4964821 Forward-Port-Of: odoo/enterprise#90900
Users can now reorder folders within Company or My Drive without the system unnecessarily checking permissions for a parent folder that is not changing. This prevents avoidable errors and makes organizing document folders smoother.
Original PR description
Reproduce: 1/ Pick a folder under Company in the search panel 2/ Drag and drop it to reorder (still under COMPANY) No need to show/fetch rights of new parent folder when it is COMPANY or MY, overlooked in 939d7a3c. Task-4822908
Fixed an issue where editing a signing template could replace field popup titles with placeholder text. This keeps reused templates clear and prevents confusing labels such as custom placeholder values appearing where standard field names should be shown.
Original PR description
### Steps to reproduce:
- Create a document using a sign template.
- Add a new field or modify the placeholder of an existing one.
- Validate the changes.
- Notice title is replaced by the value entered in placeholder.
### Issue:
After editing a template that has already been used in a signed document, the title of each sign item popup is unexpectedly replaced with the value
entered in the placeholder for that item. This corrupts the template and results
in incorrect title of sign itme being shown when the template is reused.
### Cause:
The issue occurs because the title was being updated with the placeholder of that particular sign item.
### Solution:
Added a prop for title of sign item in SignCustomPopover so that we can make the title as name of the sign item or the type like ('Name', 'Text', 'Signature') rather than the placeholder of the sign item.
---
task-4872963
Forward-Port-Of: odoo/enterprise#91639
Forward-Port-Of: odoo/enterprise#90348This update improves accounting return workflows by preserving selected dates in the return creation wizard and keeping audit completion status in sync. It also adjusts period-locking behavior so audit returns are not incorrectly blocked, making audit-related processes smoother and less error-prone.
Fixed an issue where activities configured on a reconciliation model were not added to the related bank statement line when the model was triggered. This helps teams reliably follow up on reconciliation tasks as intended.
Original PR description
On a reco model, you can set an activity that should be applied on the statement line where the reco model is triggered. Before this commit the activity was not set. task-4954201 Forward-Port-Of: odoo/enterprise#90853 Forward-Port-Of: odoo/enterprise#90540
The India reporting module now creates the GSTR1 report with the required access rights during testing. This prevents permission-related build failures and helps keep GST reporting checks reliable.
Original PR description
steps to reproduce: 1. Install l10n_in_reports module. 2. Run the test `TestReports.test_hsn_schema_change_gstr1_json`. this is required to avoid permission issues when creating the GSTR1 report in the test. build_error-223245 Forward-Port-Of: odoo/enterprise#90969 Forward-Port-Of: odoo/enterprise#89116
This fix prevents the Barcode app from storing invalid empty values when scanning lot numbers during receipt processing. It avoids a crash when users scan multiple lots, helping warehouse teams continue receipt operations reliably.
Original PR description
## How to reproduce: https://github.com/user-attachments/assets/bf44f9fd-0402-4d70-8b55-5baf192d42e8 - Enable Consignment - On Receipt operation type, enable 'Use existing lots' - Create product P,…
## How to reproduce:
https://github.com/user-attachments/assets/bf44f9fd-0402-4d70-8b55-5baf192d42e8
- Enable Consignment
- On Receipt operation type, enable 'Use existing lots'
- Create product P, tracked by lot
- Create lot SN-001 & SN-002
- Add 1 unit on hand with lot SN-001
- Create Receipt for 10 units of P -> Confirm
- Open receipt on Barcode App
- Scan "SN-002" => 'undefined' value added to 'dbQuantCache'
- Scan "SN-001" => Uncaught Promise > quantsByLocation is not iterable (cannot read property undefined)
---
## Test result without fix:
```
2025-07-18 09:30:33,801 20801 ERROR oes_test_18 odoo.addons.stock_barcode.tests.test_barcode_client_action_picking: FAIL: TestPickingBarcodeClientAction.test_barcode_lazy_cache_scan_two_lots
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/enterprise/stock_barcode/tests/test_barcode_client_action_picking.py", line 3508, in test_barcode_lazy_cache_scan_two_lots
self.start_tour(url, 'test_barcode_lazy_cache_scan_two_lots', login='admin')
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2264, in start_tour
return self.browser_js(url_path=url_path, code=code, ready=ready, timeout=timeout, success_signal="tour succeeded", **kwargs)
File "/home/odoo/projects/odoo-src/multiverse/src/18.0/odoo/odoo/tests/common.py", line 2235, in browser_js
self.fail('%s\n\n%s' % (message, error))
AssertionError: The test code "odoo.startTour('test_barcode_lazy_cache_scan_two_lots', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false, "startUrl": "/odoo/147/action-stock_barcode.stock_barcode_picking_client_action", "delayToCheckUndeterminisms": 0})" failed
TypeError: quantsByLocation is not iterable (cannot read property undefined)
at LazyBarcodeCache.getQuants (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21482:279)
at BarcodePickingModel._processBarcode (http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21748:631)
at async http://127.0.0.1:8565/web/assets/3d6bda7/web.assets_web.min.js:21661:75
```
OPW-4942192
Forward-Port-Of: odoo/enterprise#91433
Forward-Port-Of: odoo/enterprise#90492This fix prevents barcode scanning from crashing on iOS when the scan confirmation sound cannot be played. It improves reliability by choosing a better-supported sound format and safely logging sound playback issues instead of interrupting the user.
Original PR description
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan…
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan a barcode --> Traceback Discussion ----- There are 2 issues occuring here. 1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''. https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value This means that when we do https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37 We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy. To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail: https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46 2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors. ----- Ticket: opw-4820022 Forward-Port-Of: odoo/enterprise#91579 Forward-Port-Of: odoo/enterprise#91158
The stool demo bill of materials now uses the correct color attributes instead of mismatched material values. This keeps demo assembly steps clear and accurate for users evaluating or testing manufacturing workflows.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Install demo data; 2. open the Stool BoM; 3. check assembly steps. Issue ----- Mismatch between product attribute colors & materials. Cause ----- Commit f7ad739fd4b4 updated product attribute demo data. It replaced color with materials, and didn't account for attribute ordering being alphabetical instead of by time of creation. Solution -------- Change material attributes back to color attributes for stool demo data, and order attributes alphabetically to prevent confusion. Also provide unique references to product attribute value records to ensure the correct attribute value gets linked to the BoM lines. opw-4989005 Forward-Port-Of: odoo/enterprise#91611
The Sign option in Documents no longer appears in the general Action menu for list views or folders by default. This prevents users from seeing a signing action unless it has been explicitly enabled for the folder, reducing confusion and keeping workflows aligned with configuration.
Original PR description
**Before this PR:** 'Sign' option is present in 'Action' button even if its not enabled via folder action in list view. And it is available for folders too. **Technical reason:** 'Sign' button was binded in list view via this commit: https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b We don't need binding as we have a seperate flow in documents **After this PR:** 'Sign' option will only enabled when enabled in folder action. And will not be present in 'Action' button. Task-4829548
The salary configuration form now leaves the state field genuinely blank when no state is chosen. This prevents new employee records from being created with an unintended default state, improving data accuracy.
Original PR description
When using the salary config, the state (private_state_id) shows that no state is set, but the selector actually thinks the first element is selected. So when the employee is created, the state is set anyway. This forces the selector to not have anything selected by default. Task: 4904118 Forward-Port-Of: odoo/enterprise#89958
In Luxembourg and Romania localization flows, choosing a free app will no longer automatically install Accountant unless Accountant is the selected free app. This prevents unwanted app installations and keeps customer setups aligned with their choices.
Original PR description
When choosing one app free in these countries, Accountant is automatically installed. This should only be the case when Accountant is the one app free. Fix: Change the auto-install dependencies to ensure that these modules are only installed when Accountant is already installed. Forward-Port-Of: odoo/enterprise#91662 Forward-Port-Of: odoo/enterprise#91627