Monday, April 13, 2026
9 changes · saas-18.4
Resolved issues and error corrections
Salesperson email notifications for newly created invoices now show the correct invoice reference and total amount instead of placeholder values. This helps sales teams quickly identify the right invoice and amount without confusion or follow-up checks.
Original PR description
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue:…
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue: --- - In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00. Root cause: --- - Here at [1], the record name is False because the invoice is still in draft state. - In [18], _sync_invoice sets amount_currency = line.balance for new lines, but balance is precomputed as 0 before the INSERT because _compute_balance returns 0 for invoice lines. In [17] it read price_subtotal directly, which is always correct. - In 17.0 the same mail fires at the same moment, but _sync_invoice had already set balance = −295 and amount_currency = −295 from price_subtotal, so the email reads the correct 295.00. Solution: --- - Use record.display_name instead of record.name, as display_name is always present regardless of the record state. - Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices. [1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478 [18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610 [17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585 Before: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" /> After: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" /> opw-6023827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258375 Forward-Port-Of: odoo/odoo#254862
The Timesheets dashboard KPI cards now respond correctly when users apply global filters such as Employee, Project, or Department. This ensures billable hours, non-billable hours, and billable rate reflect the selected data instead of being limited to one hardcoded user.
Original PR description
Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213 Forward-Port-Of: odoo/odoo#258412 Forward-Port-Of: odoo/odoo#224810
Attachments added to activity notes in the chatter now show their preview box after saving. This helps users confirm that uploaded files were correctly included and visible in the conversation history.
Original PR description
--- When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. 1. Open an app that…
--- When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. 1. Open an app that gives you access to the chatter, for instance, an invoice in Accounting. 2. Click on Activity. Click on Log a Note... and on the button Upload a file. Upload an attachment and save. The overview of the file (blue box with the name of the attachment) should appear. The overview doesn't appear Since 19.0, we want to replace static rendering with embedded components everywhere for rendering attachments, but this creates issues for the rendering of the overview in the chatter. Therefore, after internal discussion, we agreed to keep rendering overviews statically. Backport of: https://github.com/odoo-dev/odoo/commit/4a2412b93bcac9e71826f7c0101243cdb882ddf6 opw-6035026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258466 Forward-Port-Of: odoo/odoo#254814
Odoo now blocks related fields that rely on non-stored fields before they are saved. This prevents later errors in searches, reports, and other operations, giving administrators clearer feedback when configuring fields.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Sale). - Go to Settings → Technical → Database Structure → Fields. - Create a new field using Studio or manually. -…
**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.
**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.
- This leads to runtime issues such as:
- Cannot convert field to SQL because it is not stored
- Failures in search, domains, and reporting
- Inconsistent behavior depending on usage context
- Currently, no validation prevents users from configuring such invalid related fields.
**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.
- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.
This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.
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-prThis fixes an issue where spreadsheet lists with no records could fail to load their column headers and repeatedly try to fetch data. Empty lists now display their headers correctly, preventing unnecessary repeated loading and improving reliability for users working with spreadsheets.
Original PR description
The commit a4a709f was a bit wrong, it didn't work for an empty list. If the list had no value at all, `_load` had an early return, never fetched the headers, and we had an infinite loop of fetches. Task: [5900769](https://www.odoo.com/web#id=5900769&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 fix stops users from changing the Peppol reception journal to an incompatible type. It helps ensure incoming Peppol invoices can continue to be imported reliably without avoidable configuration-related failures.
Original PR description
Prevent changing a Peppol journal to a non-purchase type, to avoid import errors when receiving Peppol invoices. Step to reproduce: - Setup a company with Peppol - Change the Peppol reception journal type to non-purchase - Try to run Peppol cron to import invoice, it fails with "Cannot create a purchase document in a non purchase journal" opw-6071992 opw-6064502 Forward-Port-Of: odoo/odoo#258567 Forward-Port-Of: odoo/odoo#256823
This update fixes an issue where the system incorrectly displayed outstanding balances when settling POS dues after a refund was processed. The fix now includes refunds in the calculation, ensuring accurate due amounts are shown for customers using 'customer Account' payment methods. This improves the reliability of the POS settlement process.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113117 Forward-Port-Of: odoo/enterprise#107883
This update resolves an issue where the LU reports were incorrectly showing only the first product with a missing internal reference. The change ensures all products with missing internal references are now displayed, improving data accuracy for Luxembourgian reporting. This aligns with requirements for complete and accurate financial reporting.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296 Forward-Port-Of: odoo/enterprise#113452
This update resolves an issue where invoice reports were generating incorrect debit and credit totals due to negative values in invoice line amounts. The fix ensures that debit and credit calculations are accurate by using absolute values, preventing validation errors and improving report reliability. This impacts financial reporting accuracy.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113316