Daily updates from Odoo
Thursday, June 18, 2026
17 changes · 19.0
New functionality added to Odoo
This update adds support for several popular food delivery services – including Talabna, Mandoob, and DiDi Food – expanding our restaurant partner options. These integrations allow Odoo to connect with a wider range of delivery providers, improving convenience for both our restaurants and customers. This is a new feature addition.
Original PR description
In this commit: - We are introducing new delivery providers like Talabna, Mandoob, Snoonu, DiDi Food and Zyada for different countries and backporting Radyes, ToYou, The Chefz, InstaShop and Smiles. Task-6263289,6263272,6263203,6263165,6310690
Enhancements to existing features
This update enhances the global filters in Odoo Enterprise by providing an option to return the customer's label instead of just their ID. This change offers greater flexibility for users who need the customer's name or description within their filters, improving data usability.
Original PR description
Before this commit: If you use ODOO.FILTER.VALUE and have a customer set in the global filter, it returns the id of the customer. That can be useful in some cases but in others you might simply want the label. Task: 6167605
Resolved issues and error corrections
This update resolves an issue where opening the chatter in the accounting module was unintentionally unfolding financial lines. This change ensures a smoother and more efficient user experience when accessing chatter, avoiding potential performance impacts. The fix focuses on streamlining the chatter opening process.
Original PR description
Before this commit, open_chatter use the selectStatementLine function that will unfold the line. But we don't want the unfold when opening the chatter. task-6306311
This update fixes an issue where a specific invoice origin code was incorrectly triggering a cancellation request to Mexican tax authorities (CFDI). The change ensures that only invoices with origin code '04' (for substitution) are used to cancel down payments, preventing unintended cancellations of the initial payment.
Original PR description
**Steps to reproduce:** - Install Sales, Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ZAPATERIA URTADO ÑERI) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Payment Way: Efectivo * Payment Policy: PUE * Product: [any product with a UNSPSC Category] * Taxes: [any] (e.g. 16%) - Confirm the SO - Create a down payment (e.g. 60%) - Confirm the down payment - Send it to CFDI - Copy the fiscal folio - Go back to SO - Create the final invoice - Set the copied fiscal folio prepend with "07|" as CFDI Origin - Confirm the invoice - Send to CFDI **Issue:** A cancellation request is sent to CFDI for the down payment. "07" origin code is used to link the invoice to a down payment. It should not cancel the down payment. It should only be done with "04" origin code used for substitution of a previous invoice. opw-6266678
This update significantly speeds up appointment scheduling by optimizing how available resources are checked. The system now processes multiple resources simultaneously, reducing the time it takes to determine availability, especially for businesses with many tables or resources. This results in a faster and more responsive scheduling experience.
Original PR description
In the current code, for each slot, and for each "available" resource, we check if the resource is available on the slot, based on availability values. Then, we check the remaining capacity of that…
In the current code, for each slot, and for each "available" resource, we check if the resource is available on the slot, based on availability values. Then, we check the remaining capacity of that resource. Also, linked resources information is added when computing the original resource remaining capacity. If many linked resources exist, this will be done several times and is not useful. This commit makes that loop disappear. We now check all resources at once in terms of availability, and linked resources that could be selected (in the appointment resources, in the slot resources (if any restricted resource)) at the same time. Then, the total capacity is the sum of the resource remaining capacity and the ones of available linked resources. Therefore, _slot_availability_is_resource_available is renamed to _slot_available_resources, as it now takes more than one resource and returns all resources among 'resources' that are valid on the slot, based on the availability_values, slot restrictions and booking lines. A noticeable difference is mainly seen when using many resources (and linked resources). For instance, a restaurant with a lot of small tables will have their slot availability check much shorter. BENCHMARK, LOCAL (time only, as number of requests does not change) Only appointment installed For a restaurant with - 10 tables of 2 - 5 tables of 2 linked, 2 times - 10 tables of 4 - 2 table of 2 - time then auto assign On loading /appointment/id: ~ 3.1s -> ~ 1.6s On selecting any number of people (1 to 10): [2s, 2.5s] -> [0.6s, 0.8s] Task-4144524
This update resolves an issue where creating RFQ approval requests could trigger access errors when using supplier pricelists with inaccessible vendors. The fix ensures that the system correctly handles vendor access restrictions, preventing errors and improving the approval process for users with limited vendor visibility. This improves the reliability of the approval workflow.
Original PR description
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two…
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two companies A and B and two users u1 and u2 - user u2 only have access to company A - With user u1: - Create two vendors v1 and v2 without any company assigned - Create vendor pricelists for a product for each vendor and assign the company A to the pricelist - Add the company B for the vendor v2 - With user u2: - Open approval application - Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected) - Save it -> An access error is thrown **Cause** Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`. opw-6203910 Forward-Port-Of: odoo/enterprise#120251
This update ensures that sales and purchase reports exported as XLSX files from the Philippines (SLSP) consistently display partner VAT values and row sequences. Previously, the order of these rows was unpredictable, leading to test failures. This fix guarantees a reliable and accurate export format.
Original PR description
Description of the issue this commit addresses: SLSP XLSX partner rows were emitted in a non-deterministic order, which made the PH sales/purchases export tests sometimes swap partner VAT values. --- Desired behavior after this commit is merged: This commit keeps the SLSP partner rows in a stable order so the XLSX export always matches the expected partner VAT and row sequence. --- runbot-[162182](https://runbot.odoo.com/odoo/error/162182) Forward-Port-Of: odoo/enterprise#120052
This update significantly reduces memory usage and speeds up the loading of large General Ledgers, particularly when displaying journal lines. The change optimizes how Odoo fetches display names, preventing unnecessary data loading and improving overall system performance. This results in a smoother user experience when working with extensive financial reports.
Original PR description
### Issue Loading a large General Ledger (e.g., during an "Unfold All" action) and retrieving display names for thousands of journal lines (`account.move.line`) causes excessive memory and…
### Issue Loading a large General Ledger (e.g., during an "Unfold All" action) and retrieving display names for thousands of journal lines (`account.move.line`) causes excessive memory and performance overhead. Profiling with `memray` showed that one of the main memory hotspots was located in `custom_label_builder`. **Previous behavior:** Accessing `record.display_name` in a loop without an explicit `fetch()` call triggered lazy computation of the field via `_compute_display_name()`. When the compute method accessed stored dependency fields (such as `name`, `ref`, `move_id`), each cache miss went through `_fetch_field()`, which greedily loaded **all fields sharing the same prefetch group** on the model, far beyond the dependencies of `display_name` alone. This caused the ORM cache to be filled with many unnecessary stored fields for every record in the prefetch set. --- ### Dataset Volume The performance metrics were captured using a dataset consisting of: * **455,694** Journal Items (`account.move.line`) * **19,947** Journal Entries (`account.move`) --- ### Solution Add a single `fetch(['display_name'])` call on the browsed recordset. By calling `fetch(['display_name'])` upfront, the ORM goes through `_determine_fields_to_fetch(['display_name'])`, which walks only the declared `field_depends` of `display_name` and fetches **only those specific stored fields**. nothing more. --- ### Impact & Results | Metric | Before Optimization | After Optimization | Change / Note | | :--- | :--- | :--- | :--- | | **Peak Memory** | ~856 MB | ~223 MB | ~74% reduction | | **Execution Time** | 2.48s | 2.13s | About the same time with multiple tries | OPW-6275158
This update enhances the visual clarity of the account reconciliation search dialog. The changes remove text truncation and reposition date and balance fields, making it easier for users to quickly review key financial information. This improves the user experience for managing bank reconciliations.
Original PR description
This commit will remove the text-truncate from the reference so that we have it full. Also removing the align item so that the date and balance are on top. no task id
This update resolves a crash that occurred when users manually corrected bank statement lines within the Odoo Enterprise system. The issue stemmed from a missing context setting, preventing the correct journal from being assigned, leading to errors and data inconsistencies. This fix ensures accurate bank statement processing.
Original PR description
When the manual correction tool was used to fill in the lines, we weren't passing the active context when creating the new records. In the case of bank statements, it could be an issue as the `default_journal_id` key is expected to be present to set the correct journal on the newly created bank statement line. Without this key in the context, it would default to the first journal with a valid type (see function `_search_default_journal`). If the journal found this way didn't match the current journal, a crash would occur when modifying the newly created lines. opw-[6294117](https://www.odoo.com/odoo/unassigned-tasks/6294117)
This update corrects a previous issue where fully settled customers with past pay-later payments were incorrectly prevented from seeing their customer statements. The fix now checks for any past pay-later payment lines, ensuring the statement button remains visible regardless of the customer's overall balance. This improves the user experience for customers who have completed their payments.
Original PR description
The override of _compute_has_moves was checking `total_due != 0` to set `has_moves` on for PoS pay_later customers. Once the customer is fully settled however, `total_due` is 0 and the check does not pass anymore, so `has_moves` goes back to `False` and the Customer Statement button hides for them, even though they had past pay_later payment lines. The fix is to check directly for any past pay_later `pos.payment` instead, which covers the cases where partner had used pay_later payment methods before, regardless if they have settled their total due or not. opw-6173760 Forward-Port-Of: odoo/enterprise#120770 Forward-Port-Of: odoo/enterprise#116536
This update resolves an issue where focusing on the end date within a daterange widget was incorrectly modifying the start date. The fix ensures that the correct date field is updated when a user interacts with the end date input, improving data accuracy and preventing unintended changes.
Original PR description
When a daterange widget is used (e.g., `deferred_start_date` coupled with `deferred_end_date`), focusing on the end date input was incorrectly modifying the start date field. This occurred because the `focusin` event was resolving the field name from the parent widget rather than the specific input focused. This commit updates `onFocusFieldWidget` and `getFullFieldName` to accept and evaluate the specific `event.target`. For `o_field_daterange` widgets, it now extracts the correct field name from the target's `data-field` attribute, ensuring the correct date field is updated. opw-6250048
This update resolves an issue where sending NFC-e invoices would halt the POS synchronization process when IAP credits were exhausted. The change prevents a blocking error, ensuring that POS transactions continue to sync smoothly even without available IAP credits for tax calculations. This improves the reliability of the POS system.
Original PR description
When sending an NFC-e, tax calculation is done by calling Avatax through IAP. If the IAP account has no credits left, iap_jsonrpc() raises an InsufficientCreditError. opw-6290857
This update corrects a problem that occurred when the Fiskaly API key was updated. Previously, changes in the API key would cause order signing to fail due to incorrect SCU and cash register information. The fix ensures these details are properly reset and recreated for the new Fiskaly organization, allowing orders to be signed correctly.
Original PR description
When the Fiskaly API key/secret is changed, the company is bound to a new Fiskaly organization (owner). The SCU and cash registers stored on the company and POS configs were created under the previous owner and no longer exist for the new one, so signing orders fails with E_CASH_REGISTER_NOT_FOUND. Clear l10n_at_pos_company_scuid and each config's l10n_at_cash_regid together with the access token so they are recreated under the new organization on the next authentication. opw-6297695
This update resolves a minor issue in the marketing automation dashboard by correcting calculations for key engagement metrics. Specifically, the KPI engagement rate and its n-1 counterpart are now accurately calculated using error handling to prevent display issues when data is missing. This ensures more reliable reporting on marketing campaign performance.
Original PR description
This commit fixes two issues:
- KPI engagement rate ('Mailing Statistics'!B16) should be =iferror((B7+B9)/B10),0)
- KPI engagement rate n-1 ('Mailing Statistics'!C16) should be =iferror((C7+C9)/C10),0)
Task: 5418449This update corrects an issue where appointment invitations weren't always sent correctly, particularly when appointments were cancelled or updated. The fix ensures invitations are now sent only for 'booked' or 'requested' appointments, and for new attendees added to existing booked appointments, streamlining communication and improving appointment management.
Original PR description
This PR fix three issues related to the sending of the appointment invitations. Each one has its own commit: - Commit 1 sends invitations only if the event either "booked" or "request". Previously they were sent even if the appointment was cancelled. - Commit 2 prevents the sending of regular invitations and always sends appointment invitation to new attendees of existing booked appointments. - Commit 3 sent appointment invitations if the status of an existing event is set "request". It also add the status change in the log as it would have been if it was done at the creation. Community PR: https://github.com/odoo/odoo/pull/260073 Task-6139036
Code cleanup and technical improvements
This update ensures that references to a key function, `fragment_to_query_string`, are correctly managed as it's integrated into the core HTTP handling within Odoo. This refactoring improves the stability and maintainability of the social media controllers, ensuring consistent behavior across the platform.
Original PR description
The aim of this commit is to keep referencing fragment_to_query_string correctly as it is moved into `http.py`. task-id: 6071808