Daily updates from Odoo
Wednesday, March 11, 2026
8 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where long titles in blog posts, events, and eLearning courses were causing horizontal page overflow and unnecessary scrollbars. The change ensures titles wrap correctly, maintaining readability and a clean user experience. This improves the visual presentation of content across key Odoo modules.
Original PR description
*:website_event, website_slides Before this commit, long titles in blog posts, events, and eLearning courses caused horizontal page overflow with an unnecessary scrollbar. This commit ensures long…
*:website_event, website_slides Before this commit, long titles in blog posts, events, and eLearning courses caused horizontal page overflow with an unnecessary scrollbar. This commit ensures long titles wrap correctly, preventing horizontal scrolling while keeping the text intact. Steps to reproduce the issue: 1. Install blog, events and eLearning modules 2. Add long titles to a blog post, event and course 3. Observe the text overflow causing a horizontal scrollbar | Before | After | | ------------- | ------------- | Blog Module | <img width="1631" height="422" alt="image" src="https://github.com/user-attachments/assets/8faa6e22-ac7a-4b59-9b54-f674978dc931" /> | <img width="1633" height="420" alt="image" src="https://github.com/user-attachments/assets/66a2de39-95e2-4871-827e-4965e571ed33" /> | | <img width="882" height="394" alt="image" src="https://github.com/user-attachments/assets/b807245f-0d84-47b6-a65b-ce0005037c50" /> | <img width="888" height="385" alt="image" src="https://github.com/user-attachments/assets/3c35cd12-08f2-4775-9c4d-d9d6e4555f00" /> | Event Module | <img width="1335" height="398" alt="image" src="https://github.com/user-attachments/assets/7d3af438-58f7-4a56-acd0-46e6dc90fe2a" /> | <img width="981" height="376" alt="image" src="https://github.com/user-attachments/assets/fb419243-4c0d-4c72-97ec-47812f81b378" /> | E-Learning Module | <img width="1534" height="317" alt="image" src="https://github.com/user-attachments/assets/3b03835c-c72b-40fb-bbf0-8fc91d3fafe5" /> | <img width="1423" height="393" alt="image" src="https://github.com/user-attachments/assets/551e332d-25af-453a-bfda-b669b04fdd39" /> | task-[5457179](https://www.odoo.com/odoo/project/974/tasks/5457179) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where large production quantities in Odoo's MRP module were causing errors. The fix ensures that the system correctly handles large production orders, preventing disruptions to manufacturing workflows. This improves the reliability of production planning and execution.
Original PR description
**Steps to repduce:** - Create `mrp.production` record with large number `Quantity` - Confirm and set same large `Quantity` value - Click on Produce all Button https://app.screencastify.com/v2/manage/videos/cy0tbiIT37R0KmST7FNv Description of the issue/feature this PR addresses:  Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a critical memory issue in the account asset module that was causing errors when processing large numbers of records. The fix uses a more efficient method to calculate depreciation, reducing memory usage and improving performance. This ensures the system can handle larger accounting environments without crashing.
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-3891767This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create the necessary accounting records. Now, when a customer pays more than the order total with a bank payment, a corresponding accounting line is created, ensuring accurate financial reporting. This prevents the system from incorrectly showing an outstanding balance.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700
This update corrects a recent issue where quotation documents with zero subtotal lines were being discarded during upload. The fix ensures that all lines, including those with a zero subtotal, are correctly processed, maintaining accurate quotation data. This resolves a regression introduced in a previous update.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#251463
This change corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the validator incorrectly flagged the file, but now the ZUGFeRD file passes validation across multiple platforms, ensuring proper e-invoice processing and compliance.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057
This update resolves an issue where appraisals marked as 'invisible to the manager' were incorrectly visible after switching companies within a multi-company setup. The fix ensures that appraisals remain hidden from managers when the employee and manager are in different companies, improving data security and user experience. This prevents managers from accessing appraisals they shouldn't see.
Original PR description
**Issue:** An employee's appraisal marked as "invisible to the manager" becomes visible to the manager when switching companies (the other company should be checked) **Steps to reproduce:** 1. Ensure the environment is configured for a multi-company setup (with both companies active). refer to the screenshot bellow  3. Create an appraisal as a user (e.g., demo): - Go to Appraisals -> New - Select an employee and a manager (e.g., Mitchell Admin) - Uncheck "Visible & Editable by Manager" - Confirm 4. Log out and log in as the chosen manager. 5. Go to the Appraisal Module. 6. Navigate to the previously created appraisal. 7. select the other company The feedback becomes visible when selecting the other company opw-4273581