Daily updates from Odoo
Tuesday, April 7, 2026
6 changes · 17.0
Resolved issues and error corrections
This update corrects a bug that prevented users from editing the Amazon fulfillment channel in the Odoo Enterprise system. The issue was due to a read-only display widget. Now, the channel is correctly editable, allowing for accurate management of Amazon sales fulfillment.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended.
This update addresses an issue where delivery confirmations were failing due to missing tracking data from Easypost. The fix prevents errors when the 'tracker' object is null, ensuring picking validation and correct carrier tracking URLs. Easypost support suggested a slight delay between order placement and data retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415
This update resolves an issue where negative values in the Mod 390 tax report were not being properly marked with the 'N' indicator, as required by Spanish tax regulations. The fix adds a necessary parameter to ensure accurate reporting and compliance with official documentation, preventing potential discrepancies with the Agencia Tributaria.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706
This update corrects a flaw in how the digest KPI for connected users is calculated. Previously, it only considered a user's default company, leading to inaccurate counts. Now, the KPI correctly accounts for users working across multiple companies, providing a more reliable measure of user engagement.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940
This update fixes an issue where sales orders with fully delivered and returned products incorrectly displayed as 'Fully Invoiced'. The fix ensures the invoice status accurately reflects zero delivered and invoiced quantities after a customer return, preventing incorrect invoicing and improving order accuracy.
Original PR description
### Issue before this commit: When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this…
### Issue before this commit: When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice". ### Steps to reproduce the issue: 1. Create a new quotation for a storable product. 2. Confirm the order. 3. Validate the delivery of the product. 4. Perform a return for the product 5. Validate that return to simulate a customer return. 6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced". ### Cause of the issue: The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced. ### Reason to introduce the fix: A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns. opw-6014772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Too many items to display' error appeared in the search panel when dealing with large datasets, specifically when filtering by partners. By adding a limit to the search panel's data display, the error is now prevented, ensuring a smoother and more reliable user experience.
Original PR description
Have a search view with searchpanel having a filter or a category with a limit. For exemple in sale.order:
```
<searchpanel>
<field name="partner_id" icon="fa-filter" groupby="parent_id" limit="80" enable_counters="True"/>
</searchpanel>
```
On a database with a lot of data, in the category partner of search panel, there is an error 'Too many items to display.'.
Now in the search view, add a filter to restrict the number of records, and hence the number of partners in the search panel below the limit.
Before this commit, the error was still displayed. Now, it isn't, and the data are properly displayed.
Closes #257749
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