Daily updates from Odoo
Friday, April 3, 2026
12 changes · master
Resolved issues and error corrections
This update fixes a technical error that caused tracebacks when users chatted with the AI about documents opened in the file viewer. The fix ensures the correct file ID is passed to the AI, resolving a 404 error and improving the AI's ability to process document-related queries. Additionally, improvements were made to the LLM's handling of images.
Original PR description
Before this commit, whenever a user tried to interact with the ai regarding a document opened in the file viewer, they would get a traceback with a 404 error. This was caused by the file id that we passed in the `openAIChat` method of the `AIChatLauncher` service. The id is negative on purpose by the documents team - there is a comment stating that it "prevents a reload from resolving to a real record". Also, the id doesn't reflect the attachment_id, but rather another id dedicated to the file_viewer. On the AI side, when using the id to search for the attachment to send to the AI, we get an error because the id is negative. This bubbles up to the user. We fix this by replacing the `this.file.id` with the `this.file.documentData.attachment_id.id` which is the correct value of the id associated with this document's attachment. Task-6030598 Forward-Port-Of: odoo/enterprise#111167
This update ensures that planned actions like Dimona and Part Time are only automatically triggered for new employees with Belgian HR contracts. Previously, the system incorrectly applied these actions to all new employees, regardless of their country of employment. This change improves accuracy and efficiency in managing Belgian HR processes.
Original PR description
Previously, planned actions (Dimona/Part Time) were triggered for all new employees with a contract start date, regardless of country. Now, the trigger is filtered to only apply to Belgian contracts. task-5942339 Forward-Port-Of: odoo/enterprise#111788
This update fixes an issue where Belgian VAT return PDFs were generated without essential fields like 'Ask Restitution' and 'Client Nihil'. The fix ensures these fields are correctly included in the PDF attachment, allowing for accurate VAT return submissions. This resolves a reported problem impacting Belgian businesses using Odoo.
Original PR description
When submitting a Belgian VAT return, the PDF attachment was generated without 'l10n_be_closing_vat_return', 'ask_restitution', and 'client_nihil' in the options. The wizard called _proceed_with_locking() without options_to_inject, so when export_to_pdf() rebuilt options via get_options(), _custom_options_initializer() read those keys from previous_options as None, making <t t-if="options.get( 'l10n_be_closing_vat_return')"> always False. Steps to reproduce: 1. Create a Belgian company 2. Navigate to Accounting -> Accounting -> Tax Returns 3. Create a VAT Return, fill in "Ask Restitution", and validate it 4. Submit the VAT return 5. Open the generated PDF attachment => "Ask Restitution" and "Client Nihil" fields are missing from the header Ticket [link](https://www.odoo.com/odoo/project.task/5509725) opw-5509725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#110537
This update resolves a bug preventing users from correctly reverting changes to a product's 'Recurring' subscription status when confirmed sales orders are associated. The fix ensures that the system reverts to the original state, preventing incorrect data and improving data integrity. This update impacts subscription products.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server. Forward-Port-Of: odoo/enterprise#111725 Forward-Port-Of: odoo/enterprise#110877
This update ensures delivery estimates correctly reflect rental orders. Previously, the delivery date wasn't properly calculated for rentals, leading to inaccurate estimates. This fix locks the rental start date, preventing edits and ensuring accurate delivery timelines for rental customers.
Original PR description
Issue: --- The delivery estimate date doesn't consider rental orders. Steps to reproduce: 1- Set delivery estimate on a delivery method. 2- Add a rental product to the cart. 3- Checkout and go to delivery page. You can choose a date in estimate date input. In rental order the rental start date should be shown and not allowed to be modified. Fix: --- By default when `_get_estimate_delivery_days` returns single date, the estimate date will not be editable. We can use xpath to target `available_delivery_days`, and override its value with rental start date, which is going to prevent it from being edited. opw-6081494
This update resolves an issue where planning users couldn't update customer phone numbers within slots, resulting in an access error. The fix implements security measures like sudo() and view-level restrictions to ensure only authorized users can modify partner phone details, improving data integrity.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Planning > User" access. 2. Create a new planning slot. 3. Add a customer on the slot whose partner is linked to a res.users account. 4. Access error is raised. Issue: - - Planning users could not update the partner phone on a slot. - An access error appeared when updating the phone number. Cause:- - - When a customer was added to the slot, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/enterprise#112777 Forward-Port-Of: odoo/enterprise#93969
This update fixes an error in the Mod 347 BOE export that was causing issues with AEAT's data processing. The system now uses the correct 'C' and 'S' indicators for complementary and substitute declarations, ensuring compliance with Spanish tax regulations. This prevents the AEAT from misinterpreting the report.
Original PR description
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the…
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company` - Navigate to Accounting > Reporting > Tax Report - From the smart button, select `Report: Tax Report (Mod 347) (ES)` - Download the BOE file using the dropdown. - In the wizard: - Enable `Substitutive Declaration` or `Complementary Declaration` - Set `Previous Report Number` (e.g., 123456789) - Click `Generate BOE` - Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required) **Observation:** AEAT does not recognize 'X' as a valid indicator for substitutive or complementary declarations and interprets the file as a standard return. **Root Cause:** At [1], the BOE Mod 347 generation writes 'X' for both substitute and complementary declarations. **Fix:** This commit ensures the file contains correct indicators: - 'C' for `complementary declarations` - 'S' for `substitute declarations` This aligns Modelo 347 with AEAT specifications and ensures consistency with the implementation of Modelo 349 at [2]. Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html [1]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062 [2]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491 opw-6048711 Forward-Port-Of: odoo/enterprise#112860 Forward-Port-Of: odoo/enterprise#112566
This update corrects a previous issue where negative partner totals were hidden and insurance operations only considered purchase journal data. Now, the report accurately displays all partner totals (positive or negative) and correctly reports insurance sales and purchase amounts, ensuring more accurate Spanish tax reporting.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023 Forward-Port-Of: odoo/enterprise#112823 Forward-Port-Of: odoo/enterprise#100413
This update resolves an issue where users couldn't successfully undo rescheduling calendar events. The fix removes a problematic data field ('originId') before the system writes event data to the database, preventing an error that occurred during the undo process. This ensures calendar event modifications are reliably saved and undone.
Original PR description
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to…
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to create a calendar event. - Reschedule the event to a later time (drag and drop forward). - Click Undo on the notification that appears. Error: `ValueError: Invalid field 'originId' in 'calendar.event'` `KeyError: 'originId'` Cause: - The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it. - The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur. Solution: - Remove the `originId` key from `fallbackdata` before the orm call. [1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116 [fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425 [orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477 [line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248 sentry-7020359653 Forward-Port-Of: odoo/enterprise#112851 Forward-Port-Of: odoo/enterprise#100570
This update addresses a previous issue where calculating asset depreciation consumed excessive memory, particularly with large numbers of assets. The fix uses a more efficient method to process depreciation calculations, preventing the system from running out of memory and improving performance. This ensures accurate depreciation reports for all users.
Original PR description
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the…
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```
Traceback (most recent call last):
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
result = records.read(fields, **read_kwargs)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
opw-5921410
upg-3891767
Forward-Port-Of: odoo/enterprise#110407
Forward-Port-Of: odoo/enterprise#109008This update resolves an issue where the LPP (Labor Pension Plan) was incorrectly applied to employee salaries when they were not insured. The fix ensures that LPP contributions are only calculated for employees who meet the necessary insurance requirements, improving payroll accuracy and compliance. This change primarily impacts the Swiss payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#112824
This update resolves an issue where subscription products with a zero sales price couldn't be added to the cart when the 'Prevent Sale of Zero Priced Product' setting was enabled. The fix ensures the system correctly uses the selected subscription plan to determine if a product can be added to the cart, improving the user experience for subscription offerings.
Original PR description
A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is…
A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled Steps to reproduce: 1. Install eCommerce and Subscriptions 2. Go to Settings and enable `Prevent Sale of Zero Priced Product` 3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website 4. Go to Subscriptions > Pricelists and edit pricelist "Benelux" 5. In the Recurring Prices tab, create a new entry for product "subscription" with a Fixed Price of $20.00 and a monthly Recurring Plan 6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected) 7. Try to add it to the cart 8. Nothing happens and an error is displayed in the log Issue: When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs We reach this code https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart Solution: We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart. Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`. opw-5993614 Forward-Port-Of: odoo/enterprise#112699 Forward-Port-Of: odoo/enterprise#111624