Daily updates from Odoo
Wednesday, April 15, 2026
9 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue preventing Point of Sale (PoS) users from accessing the sinvoice symbol. By granting the necessary access rights, this change ensures PoS users can properly utilize the feature as intended. This improves functionality for retail operations.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, presenting accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
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-6092595
Forward-Port-Of: odoo/enterprise#113515This 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 empty chat is definitively confirmed, improving the overall user experience. This ensures tours function consistently and reliably.
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. Forward-Port-Of: odoo/odoo#258921
This update fixes a discrepancy in the 'To Pay' dashboard by ensuring it accurately reflects all outstanding payments, including receipts, alongside invoices and refunds. Previously, the dashboard only considered invoices, leading to an inaccurate count and amount. This change ensures dashboard metrics 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 Forward-Port-Of: odoo/odoo#254295
This update corrects a discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate record counts. Now, receipts are incorporated, ensuring dashboard metrics align with the actual data for a more reliable view of financial activity.
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 Forward-Port-Of: odoo/enterprise#111142
This update fixes an issue where the 'Back to edit mode' link in the land portal invoice was incorrectly directing users to the wrong Odoo app. By switching to the correct action, the webclient now consistently directs users to the Invoicing app, ensuring accurate invoice management. This improves the user experience and prevents incorrect navigation.
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 Forward-Port-Of: odoo/odoo#257841
This update fixes a problem where multiple email aliases could lead to duplicate records being created when emails were processed concurrently. The fix uses a locking mechanism to ensure that only one record is created for each email, regardless of how many aliases receive it. This improves data accuracy and prevents potential issues with reporting and analysis.
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#258847 Forward-Port-Of: odoo/odoo#250027
This update corrects a flaw in how appointment booking capacities are calculated, ensuring resources are accurately reserved rather than reserving full party sizes. This fix improves the reliability of appointment scheduling and prevents overbooking issues. The change was driven by a bug fix and includes updated testing.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113805
This update resolves an issue where empty or missing attachments in invoices could cause the system to crash during import. The fix now gracefully falls back to default journal and move type settings, ensuring invoices are created and any errors are logged. The underlying cause of the empty attachments is still being investigated.
Original PR description
Empty attachments (ex: False/None) could crash parsing during import, this commit falls back on default journal and move type in case of error, allowing the invoice to be created and the issue logged properly. Root cause of empty XML remains unclear, likely a 3rd party error. opw-6113211 Forward-Port-Of: odoo/odoo#259294