Tuesday, April 14, 2026
17 changes · 18.0
Resolved issues and error corrections
This update fixes an issue preventing users from renting products with 'Daily' pricing when selecting today's date. The fix addresses a mismatch between the rental product's start date (without time) and Luxon's datetime, which includes time. Now, same-day rentals with daily pricing function correctly.
Original PR description
**Steps to reproduce:** - Install `website_sale_stock_rental` module - Create a rental product with "Daily" pricing - Open product on website - Try to set today's date for renting **Observation:** - A restriction occurs when selecting today’s date with the error: “Your rental product cannot be prepared as fast, please rent later.” **Cause:** - With Daily rental pricing, the startDate considers only the date without time. - When compared against Luxon’s current datetime (which includes time), the condition is always satisfied, resulting in the error message. - For Hourly rental pricing, it works fine because the startDate includes both date and time. https://github.com/odoo/enterprise/blob/7b5d2e123e3f14f2fbf775ee6b5bd2e51b4520d4/website_sale_stock_renting/static/src/js/renting_mixin.js#L18-L20 **Solution:** - Add a condition: if the duration is without hours, use only the date in Luxon time comparison. opw-5016324
This update corrects a discrepancy in the sale and purchase journal dashboards by including receipt data. Previously, receipts weren't reflected in the dashboard metrics, leading to inaccurate counts. This change ensures that dashboard reports align with the actual recorded transactions, providing a more reliable view of financial data.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828
This update simplifies the point of sale display for transactions processed with Worldline. Previously, a transaction ID was shown alongside the amount, which caused confusion and was incorrectly interpreted as a negative value. Removing this ID clarifies the display for cashiers and improves the user experience.
Original PR description
This PR removes the transaction id shown next to the amount in point of sale for transactions used with Worldline. The transaction id preceded by a "-" was confusing for some cashiers and interpreted as a negative amount. Since the transaction id isn't useful for cashiers it's removed from the xml. Before: <img width="705" height="422" alt="image" src="https://github.com/user-attachments/assets/19ebfe49-e16d-45ea-b770-e445fe8b473d" /> After this PR: <img width="1182" height="353" alt="image" src="https://github.com/user-attachments/assets/f7cd1b7c-75fa-4fe9-ae20-7c5e6d834488" /> opw-6085975
This update corrects a display issue in the Batch Payment reports. Previously, the report would include default placeholder text ('ABC Holder Name' and 'Demo Ref') when the Account Holder Name field was left blank. This change ensures that the report is clean and accurate when the Account Holder Name is not specified, improving the professional appearance of generated invoices.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595This update resolves an issue preventing Point of Sale (PoS) users from accessing the sinvoice symbol within the Odoo system. The change adds the necessary access rights, allowing PoS staff to utilize this important feature. This ensures PoS operations can fully leverage the edi functionality.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it.
This update corrects a visual issue in the product expiry module where all products without removal dates were incorrectly highlighted in red. Now, only products with expired lots/serials or quantities below zero will be flagged as expired, ensuring accurate product tracking and inventory management. This change improves the usability of the product expiry feature.
Original PR description
**Description of the issue/feature this PR addresses:** Install product_expiry and have products in stock with a quantity greater than 0 and not having any serial or lot configuration. **Current behavior before PR:** All lines which have no valid removal_date set (normally just those which are to be subject to be expired) will be marked red. **Desired behavior after PR is merged:** The tree view is showing as intended only if a product lot/serial is expired or a quantity less than zero will be marked red. Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258980
This update resolves a technical issue where the 'Back to edit mode' link in the land portal invoice section of the Invoicing app was incorrectly directing users to the wrong application. By switching to the correct action, the system now reliably directs users to the Invoicing app, ensuring a smoother user experience.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256
This update ensures that the system only generates supported documents for Odoo partners who are correctly identified as participating in Nemhandel. Previously, the process would incorrectly attempt to generate documents for invalid partners, leading to test failures. This change improves data accuracy and stability.
Original PR description
The method to fill the supported documents of a partner was called even if it was not a valid Nemhandel participant. This would cause some test to fail as the call was unexpectedly done on tests without any setup for it.
This update resolves an issue where printing surveys without answer scoring would leave out participant responses, leading to inaccurate reports. The change ensures all survey answers are consistently included when printing, providing complete and reliable data. This improves the quality and trustworthiness of survey results.
Original PR description
Previously, printing surveys of type scoring_without_answers omitted participants' answers, resulting in incomplete and inconsistent reports. This commit ensures answers are always included, regardless of survey type. Task-5407701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258616
This update fixes a technical issue where multiple emails with the same identifier could be created, leading to data duplication. The change ensures that Odoo correctly handles concurrent email processing by checking for existing records before creating new ones, preventing these duplicates. This improves data accuracy and efficiency.
Original PR description
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with…
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with both aliases as recipient. The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions. We expect one record per alias/team, but duplicates may be created. ### Cause This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation. Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions. When two concurrent transactions process the same email: 1. Both enter `message_process` and take their snapshot. 2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing. 3. Both create records. Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates. ### Fix After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal. opw-5116492 Forward-Port-Of: odoo/odoo#250027
This update fixes a discrepancy in the 'To Pay' dashboard metrics by including receipts alongside invoices and refunds. Previously, the dashboard didn't accurately reflect the total amount to pay due to missing receipt data. This ensures the dashboard numbers align with the detailed records available in the action view.
Original PR description
- The "To Pay" section in the purchase/sales dashboard was only considering invoices(`in_invoice` and out_invoice) and refunds(`in_refund` and `out_refund`) when computing the number and amounts to pay. - However, the corresponding action view includes receipts (`in_receipt` and `out_receipt`), leading to an inconsistency where the dashboard count and amount did not match the records shown after clicking. - This commit updates the dashboard query to also include receipts, ensuring consistency between the displayed metrics of the coreesponding purchase/sales dashboard and the action view. Related PR: https://github.com/odoo/enterprise/pull/111142 taskID-6040828
This update fixes an issue preventing Odoo from correctly processing German hybrid-style invoices through the Peppol exchange. The change ensures the 'zugferd' format is handled correctly, aligning it with the 'facturx' format and resolving a potential processing failure. This improves the accuracy of invoice data exchange.
Original PR description
The 'zugferd' key was missing from the `_get_customization_ids` mapping, causing potential failures when attempting to identify the correct CustomizationID for German hybrid-style invoices being processed through the Peppol exchange. This is because the 'zugferd' format was wrongly considered as peppol edi format, whereas it should behave like the 'facturx' format and be excluded from the peppol edi formats. opw-6009214 Forward-Port-Of: odoo/odoo#256696
This update ensures that tax amounts are accurately calculated when users group lines on an invoice. Previously, discrepancies in tax could occur. The changes also streamline the process by removing a redundant context key and updating a key test case to reflect Belgian tax regulations.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#252719
This update resolves an issue where Odoo prevented the posting of vendor bills with numbers that didn't follow a strict, sequential order. This was due to the system's hashing logic, which requires continuous numbering. Now, vendor bills from third parties with varying document numbers can be processed correctly.
Original PR description
**Steps to reproduce** Install modules l10n_ar and l10n_latam_invoice_document. Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that…
**Steps to reproduce** Install modules l10n_ar and l10n_latam_invoice_document. Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that uses LATAM documents. Create and post a vendor bill with a high document number (e.g., '00001-00009999'). Create another vendor bill with a lower document number (e.g., '00001-00000100') and try to post it. **Issue** Posting the second vendor bill fails with a UserError: \"This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it.\" This happens because core Odoo hashing logic enforces a strict, continuous sequential numbering per journal and prefix. The _get_chain_info method identifies moves to be secured by searching for entries with a sequence number strictly greater than the last hashed move in that chain: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4091-L4145 When a vendor bill is entered with a lower number than an already hashed one, it is excluded from the search, triggering the no_document warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4140 And the subsequent UserError in _get_chains_to_hash: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4180-L4184 Similarly, jumps in vendor numbering trigger a gap warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4130 Causing the error at: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4185-L4188 Since vendor bills are issued by third parties, we do not control their sequence, and forcing them into a single continuous chain is functionally incorrect. opw-6076673
This update resolves an issue preventing the posting of vendor bills with non-sequential document numbers. The system previously enforced strict sequential numbering, causing errors when bills didn't follow this pattern. This change allows for more flexible vendor bill numbering, aligning with typical business practices.
Original PR description
**Steps to reproduce** Install modules l10n_ar and l10n_latam_invoice_document. Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that…
**Steps to reproduce** Install modules l10n_ar and l10n_latam_invoice_document. Go to Accounting > Configuration > Journals and enable \"Lock Posted Entries with Hash\" on a Purchase journal that uses LATAM documents. Create and post a vendor bill with a high document number (e.g., '00001-00009999'). Create another vendor bill with a lower document number (e.g., '00001-00000100') and try to post it. **Issue** Posting the second vendor bill fails with a UserError: \"This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it.\" This happens because core Odoo hashing logic enforces a strict, continuous sequential numbering per journal and prefix. The _get_chain_info method identifies moves to be secured by searching for entries with a sequence number strictly greater than the last hashed move in that chain: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4091-L4145 When a vendor bill is entered with a lower number than an already hashed one, it is excluded from the search, triggering the no_document warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4140 And the subsequent UserError in _get_chains_to_hash: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4180-L4184 Similarly, jumps in vendor numbering trigger a gap warning: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4130 Causing the error at: https://github.com/odoo/odoo/blob/976c9778c038e821176fc3b273bf4ad58bdc4810/addons/account/models/account_move.py#L4185-L4188 Since vendor bills are issued by third parties, we do not control their sequence, and forcing them into a single continuous chain is functionally incorrect. opw-6076673
This update resolves a bug that caused tests to fail unpredictably when activities were canceled. The fix ensures the system correctly waits for canceled activities to disappear before allowing users to complete other tasks, improving the reliability of the activity management feature. This enhances the overall user experience.
Original PR description
Recent fix of activity cross-tab data sharing [1] added a new test to make sure the feature works as expected. This test may fail non-determinstically after "cancel" of an activity. The failure happens because while this activity has been canceled, the next step is to click on "mark as done" on the other activity, but due to not awaiting the removal of the cancelled activity, the "mark as done" button may mistakenly target the activity that has just been cancelled. This commit fixes the issue by awaiting that the cancelled activity has been removed from UI, so that the selector to click on "mark as done" button is necessarily on the other activity [1] https://github.com/odoo/odoo/pull/255785
This update fixes a potential issue where website tours could incorrectly proceed if the chat feature was temporarily empty. The change implements a more reliable check to ensure the tour only continues when the chat is definitively empty, improving the overall user experience. This ensures tours execute correctly and consistently.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed.