Friday, February 27, 2026
13 changes · 17.0
Enhancements to existing features
This update significantly speeds up a core process within Odoo that identifies relevant bank accounts for financial reporting. By optimizing the data retrieval method, the system now completes this task in milliseconds instead of seconds, leading to faster reporting and a smoother user experience. This change focuses on internal performance improvements.
Original PR description
Before this commit, retrieving the `account_ids` from the properties in the method `_get_default_amls_matching_domain` involved searching for all the properties and calling the method `get_by_record` on each record. The `accounts` were fetched only to get the ids to add them to the `blaclisted_stock_account_ids`. Since, the domain had the condition `value_reference != False`, and the field holds the model name and the id of the record, we can directly fetch the `ids` by doing a read_group to eliminate possible duplicates and add the ids to a set of `account_ids`. This will eliminate a search to every record of the `properties` fetched which will improve the performance significantly. The benchmark done below was on a database that fetched **15630** properties and it was only tied to **two** accounts. | Scenario | Time (seconds) | |-----------|----------------| | **Before** | **7s** | | **After** | **27ms** | opw-5868236
Resolved issues and error corrections
This update resolves a warning generated during testing related to fake PDF content. The change replaces these fake files with a minimal PDF file, ensuring consistent test results and preventing potential issues with the PyPDF library. This improves the reliability of our testing process.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278
This update resolves a bug that occurred when users clicked the status bar on Follow-up Reports after excluding certain records. The issue stemmed from a missing data field within the system, preventing proper report rendering. This fix adds a check to ensure the necessary data is present before processing, improving report stability.
Original PR description
This traceback occurs when the user clicks on the `statusbar` of `followup reports` by excluding all `aml's`. To reproduce this issue:- 1) Install `Accounting` 2) Open the `Follow-up-report` from…
This traceback occurs when the user clicks on the `statusbar` of `followup reports`
by excluding all `aml's`.
To reproduce this issue:-
1) Install `Accounting`
2) Open the `Follow-up-report` from `dropdown menu` of
`Customer Invoices` in `accounting onboarding dashboard`.
3) Open any one record by removing the default filter
4) Enable the `Exclude from follow-ups` for all `aml's`
5) Now click on the `status bar`
Error:-
```
KeyError: 1
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 76, in web_save
return self.with_context(bin_size=True).web_read(specification)
File "addons/web/models/models.py", line 129, in web_read
vals = many2one_data[values[field_name]]
```
When the user `Excludes` all the `Followups` and clicks on the `status-bar`,
the `web_read` method triggers with a record of `res.partner` having no `followup_line_id`.
Because of that, there will be no `many2one_data` as `extra_fields` are `{}`
values_list is also empty for the recursive call of many2one_data as `co_records` is also
having no recordsets.
Which leads to an exception from the below line (128).
https://github.com/odoo/odoo/blob/0d1399d06bd5ab30918b1a84abccb0f44504a508/addons/web/models/models.py#L116-L128
After applying this commit, it will resolve this issue by adding an extra check of "many2one_data" before assigning the value from many2one_data. Which makes the code more robust.
sentry-4982604710This update resolves a technical issue that prevented users from correctly attaching receipts to expense records. Specifically, a bug caused an error when a user canceled the attachment process. The fix ensures the system handles this cancellation gracefully, preventing a crash and improving the user experience.
Original PR description
A traceback is occurring when the user tries to attach a receipt in the expense To reproduce this issue: 1) Install `hr_expense` 2) Open any existing `my expense` record 3) Click on the `Attach Receipt` button and attach a file 4) Now again attach a file through the `Attach Receipt` button 5) This time click on `cancel` while attaching a file through `Attach Receipt` Error:- ``` IndexError: list index out of range ``` When the user clicks on the cancel button when trying to attach a file, it triggers an `orm` call with `attachments` as an empty list with respected `model` & `action`. Which leads to the above traceback in the backend. After applying this commit, will resolve this issue by checking the length of the file before triggering the form. Which makes code more robust. sentry-4705156379
This update resolves an issue where new sale orders were created without a specified Incoterm. The change ensures that the company's default Incoterm is automatically applied when a new sale order is created, streamlining the sales process and improving data consistency. This prevents manual entry of Incoterms and reduces potential errors.
Original PR description
Currently, when creating a new sale order Incoterm value remains empty. <b>Steps to reproduce:</b> 1) Install sales, stocks, and enable incoterms for sales in settings 2) Give the default Incoterms value in the settings 3) Try to create a new SO record <b>Issue:-</b> Even after providing the default incoterm value in the settings, The value of incoterm remains empty while creating the SO. <b>Solution:-</b> Give the company incoterm value as the default incoterm in the definition of incoterm in sale order. opw-4700346
This update fixes a bug that occurred when users entered a maximum appointment duration. The issue caused a system error due to an overly large number being processed. This change ensures the system can correctly handle maximum duration values without crashing, improving the user experience when scheduling appointments.
Original PR description
A traceback occurs when the user gives a maximum duration value while updating an appointment. To reproduce this issue: 1) Install appointment 2) Open an appointment record from the grant view of the calendar event 3) Give the maximum duration value 4) Click on preview Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value, it calculates the time from the below. https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/appointment/models/appointment_type.py#L623-L624 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves an issue where creating a new appointment with the maximum allowed duration caused a system error. The fix prevents an 'OverflowError' by correctly handling large duration values, ensuring users can accurately set appointment lengths without disrupting the system. This improves the appointment scheduling process.
Original PR description
A traceback occurs when the user gives a maximum duration value while creating a new calendar event. To reproduce this issue: 1) Install appointment 2) Create a new appointment from the Gantt view 3) Give the maximum duration value Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value it is used to calculate the time from the below. https://github.com/odoo/odoo/blob/a4c46f358401077a65106a6172b2a636755d41aa/addons/calendar/models/calendar_event.py#L369 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves a bug that caused an error when users attempted to access the website after deleting all websites within the Odoo system. The fix ensures a minimum website requirement is maintained, preventing the 'ValueError: Expected singleton: website()' error. This improves website functionality for all users.
Original PR description
Currently, a traceback occurs when the user deletes all the websites and tries to open the website. To reproduce this issue: 1) Install the website 2) Delete the default website from external identifiers in settings/technical 3) Now delete all websites from website/configuration/websites 4) Tries to access or open the website Error:- ``` ValueError: Expected singleton: website() ``` Initially, there is a check for at least one website while uninstalling the websites, But after the below commit the code is changed only to check for the default website. But if the user deleted the external identifier of the default website and deleted all the websites it leads to a traceback. https://github.com/odoo/odoo/pull/113405/commits/60adaf5632ddfe3f68da369a2e9642ad639da37e After applying this commit, it will resolve this issue by ensuring at least one website is required. sentry-5900356108
This update corrects a technical issue that prevented users from uploading files without a name, resulting in a traceback error. By providing a default value, the system now handles this scenario gracefully, ensuring a smoother user experience.
Original PR description
Currently, a traceback may arise when the user uploads a file with no name. Error:- ``` TypeError: Web_Editor.add_data() missing 1 required positional argument: 'name' ``` When the value of the `name` we get from the RPC call is `undefined`, we get this traceback on the backend. If there is no `name`, this case is already handled in the python side https://github.com/odoo/odoo/blob/6838782baf222db4591edce5fe80f5af3a39810c/addons/web_editor/controllers/main.py#L261-L266 So by just giving the fallback value if there is no name, we can resolve this issue. sentry-5741581459
This update resolves a technical issue that caused a traceback when users removed the UOM from Sale Order Lines. The fix ensures the UOM is correctly handled during price calculations, preventing errors and improving data accuracy. This impacts the pricing of sales orders.
Original PR description
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales…
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales configuration 3) Create a new pricelist with a `price rule` of `discount` and make sure to change the `discount policy` to `without_discount` from the pricelist configuration 4) Now create a new `Quotation` with the pricelist 5) Remove the `UOM` from the Order Lines and update the Quantity Error:- ``` ValueError: Expected singleton: uom.uom() ``` When the user removes UOM from the SOL it triggers a compute method `_compute_discount` through which another method `_get_pricelist_price`. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/sale/models/sale_order_line.py#L518-L522 In the second method, UMO is used to compute the price for the `pricelist item`, but in that `_compute_price`, `uom.ensure_one()` is used. Which leads to the above traceback. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/product/models/product_pricelist_item.py#L362-L364 By applying this commit will resolve this issue by taking UOM from product, which is a required field in product. sentry-5537497781
This update resolves an issue where the Odoo system incorrectly warned users about links to Google Shared Drive files, even when accessible. The fix adds a setting to the Google Drive API request, allowing the system to properly access files within Shared Drives. This ensures users can seamlessly integrate content from Shared Drives into their courses.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413
This update ensures the Knowledge HTML field continues to function as expected by maintaining the legacy dirty check mechanism. Previously, a change in the system's logic caused workflow inconsistencies. The fix involves adjusting the associated test to accurately reflect the Knowledge field's behavior.
Original PR description
Knowledge relies on the previous dirty check mechanism, and switching to the new simplified logic introduced inconsistencies in its workflow. To preserve the expected behavior, the Knowledge HTML field continues to use the legacy `_isDirty` mechanism. Additionally, the related test was using the standard `html_field` widget for convenience, since `knowledge_html_field` includes WYSIWYG helpers and comment features that are irrelevant for the test. Now that `_isDirty` differs between the two widgets, the test must explicitly patch `_isDirty` to align with the Knowledge behavior and properly validate the intended scenario. opw-5892291
This update resolves an issue preventing non-administrator users with 'Editor and Designer' access from adding images from Unsplash. Previously, access restrictions blocked image uploads, now these users can successfully add and save images through the web editor. This improves usability for a wider range of users.
Original PR description
Non admin users with either "restricted" or "editor and designers" access are not allowed to add images using unsplash because they require permission to make changes in the url field in attachment. Steps to reproduce: 1. Login via non admin user with "Editor and Designer" access. 2. Try to edit it via editor and add an image with unsplash. 3. Try saving it. You won't be able to save it due to the access right issue. opw-5221162