Daily updates from Odoo
Friday, June 5, 2026
19 changes
2 changes
Enhancements to existing features
This update adjusts the Obox application's position within the main menu. The app is now listed after 'Apps' and before 'Settings,' improving discoverability for users. This change streamlines the user experience by placing a key application in a more intuitive location.
Original PR description
This commit changes the Obox menu sequence so that the app appears at the end of the apps list by default (just before Apps and Settings). task-6275407 Forward-Port-Of: odoo/enterprise#119337
This update allows for easier customization of Unsplash image access within our SaaS environment. Previously, a key limitation prevented modules from overriding the Unsplash access key, now patchable methods have been added for retrieval. This change ensures greater flexibility and control over image sourcing for SaaS users.
Original PR description
__Before commit__ The Unsplash querying logic was moved out of the controller in odoo/odoo@e5151524. The Unsplash access key was now retrieved directly using the ICP instead of using the dedicated method of the controller. This made it impossible for a module to override the access key used by `_fetch_unsplash_images`, which is required on SaaS. __After commit__ Add some patchable methods to retrieve the Unsplash access key and app ID.
1 change
Enhancements to existing features
This update adjusts the Obox application's position within the main menu. It now appears at the end of the list, just before 'Apps' and 'Settings'. This change improves user discoverability and simplifies navigation for Obox users.
Original PR description
This commit changes the Obox menu sequence so that the app appears at the end of the apps list by default (just before Apps and Settings). task-6275407 Forward-Port-Of: odoo/enterprise#119337
1 change
Enhancements to existing features
This update improves the speed of searching for partners (customers and suppliers) within the Point of Sale system. By optimizing the search process, particularly on large databases, the system responds more quickly, leading to a smoother and more efficient user experience. This change focuses on internal performance improvements.
Original PR description
Improve partner search response time on large databases (1M+ rows): - Implement smart field selection based on input type (phone, email, text). - Use prefix search (=ilike) for identifiers and exact match for barcodes. - Remove expensive sorting by complete_name in the backend. - Increase search limit to 500 to reduce network round-trips. task-id: 6143737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260347
1 change
Enhancements to existing features
This update simplifies VAT reporting for Odoo users in Norway. The default VAT periodicity has been set to bi-monthly (every 2 months), aligning with the standard reporting frequency used in Norway. This change reduces the administrative burden for Norwegian businesses using the Odoo Enterprise system.
Original PR description
Set the default VAT periodicity for Norwegian companies to every 2 months, aligning with the most commonly used reporting frequency in Norway. task-6209940 Forward-Port-Of: odoo/enterprise#117054
6 changes
Enhancements to existing features
This update aligns the default VAT reporting frequency for Norwegian businesses within Odoo Enterprise to bi-monthly (every 2 months). This change simplifies reporting for our Norwegian customers, matching the most common reporting practice in Norway and reducing potential administrative burden. It’s a straightforward improvement to the accounting process.
Original PR description
Set the default VAT periodicity for Norwegian companies to every 2 months, aligning with the most commonly used reporting frequency in Norway. task-6209940
This update enhances the Odoo profiling tool by automatically tracking the time taken for database queries. Previously, profiling data was incomplete. Now, the system captures query execution times and commits this data periodically, providing more accurate performance insights.
Original PR description
Modify the query collector so that it add an entry before the query runs and updates the time after it runs. use the async collector periodic sampling to commit the profiler after a time limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250383 Forward-Port-Of: odoo/odoo#215034
This update enhances how Odoo identifies partners during UBL imports, primarily by using exact name matches and bank account details. This prevents incorrect partner matches and ensures accurate VAT data is applied, leading to more reliable data import and reconciliation.
Original PR description
Before this commit: Partner was searched using contains on the name, which could match unrelated partners with similar names (e.g. `Global Tech` matching `Global Technologies Ltd`). With this update: - Partner retrieval now uses an exact name match to avoid incorrect matches caused by partial name search. - For UBL imports for Peppol, bank details are also used to help identify the partner by matching the bank account number. The retrieval logic has also been improved: 1. If VAT exists in the XML: - If a partner found with no VAT then enrich that partner by filing VAT from xml - If a partner found with a different VAT than the one in the XML, then a new partner will be created Also fix the test case where it finds `partner_1` through the `bank account number` and creates a new partner instead of returning the correct `partner_2`. task-5485563 Forward-Port-Of: odoo/odoo#261759 Forward-Port-Of: odoo/odoo#250309
This update implements webhooks for Peppol documents within the French localization (l10n_fr_pdp) module. This was previously missing in the 18.0 release and is now enabled through integration with the IAP platform, ensuring compliance with French tax regulations. It improves data exchange efficiency for French business operations.
Original PR description
We did not have webhooks in 18.0 for Peppol and we did not have time to implement / test it during the FW-porting. This commit adds the route on community side that is called from IAP. task-None IAP PR: https://github.com/odoo/iap-apps/pull/1639
This update improves the DEP7 export process by switching from PDF to JSON files, aligning with regulatory requirements for German tax reporting (BMF/RKSV). The new JSON format is machine-readable and optimized for compatibility with official BMF tools, ensuring accurate and compliant data submissions.
Original PR description
In this commit: ------------------- - Updated the DEP7 export to generate a zip with JSON files instead of PDF, in compliance with BMF (RKSV) requirements. - The export now produces a valid JSON document containing the machine-readable data expected by the official BMF tools. - The filename format has also been adjusted to follow common conventions (e.g. `Name_Duration_DEP_KassenID.json`). Task: 6071034
This update introduces a new button to streamline the process of reregistering accounts between Peppol and PDP for French users. This change addresses a previous issue during testing where the demo company's settings were incorrectly configured, causing problems with the reregistration flow. It improves usability and ensures a smoother transition for users managing their PEPPOL accounts.
Original PR description
#### [IMP] l10n_fr_pdp: fix visibility for peppol (non-PDP) #### [IMP] account_peppol,l10n_fr_pdp: reregister This commit adds a button so that users can reregister more easily. This is i.e. useful to switch from Peppol to PDP for French users. #### meta task-6265603 Forward-Port-Of: odoo/odoo#267946
6 changes
Enhancements to existing features
This update allows users to automatically associate return reasons with barcode scans during picking. By adding a return reason ID to the OBTRETU barcode, the system now correctly creates returns and links them to the selected reason, streamlining the return process.
Original PR description
This commit adapts OBTRETU to also fetch and select the return reason with the barcode. Details: Here we have added the `return.reason` ID after the OBTRETU barcode. When this barcode is scanned, it will also scan the return reason and pass that ID in the context of `_returnProducts`. Then it will retrieve that context and set it on the generated return for this delivery. For example is user select `return.reason` with ID 4 new barcode will be OBTRETU:4, so when user scan this QR in picking it will create return and set `return.reason` with ID 4. task-4160966 Community PR: https://github.com/odoo/odoo/pull/234112
This update streamlines the invoicing process by automatically reconciling invoices created directly from sales orders. Previously, this required manual steps; now, a new system passes a context key, enabling automatic reconciliation within the accounting system. This improves efficiency and reduces the risk of errors when generating invoices from sales transactions.
Original PR description
This commit will allow to automatically reconcile the invoice create from the sale order by passing a context key that will be used in the create_invoices function. task-5502964 Forward-Port-Of: odoo/enterprise#117875 Forward-Port-Of: odoo/enterprise#108546
This update ensures that stacked bar charts created within Odoo spreadsheets automatically include a total line, mirroring the standard behavior of charts in the main Odoo graph view. This improves consistency and makes spreadsheet charts more intuitive for users who are familiar with Odoo's charting capabilities. It addresses a visual discrepancy between spreadsheet and standard charts.
Original PR description
## Description When inserting a stacked bar graph view into a spreadsheet, enable showTotalLine on the generated chart definition. This keeps inserted spreadsheet charts aligned with the Odoo graph view, where stacked bar charts display the Sum line by default. Task: [5886277](https://www.odoo.com/odoo/project/2328/tasks/5886277)
This update adds detailed labels to LLM requests, identifying the source (like agents or web search) and the specific model used. This enhanced tracking allows us to better understand how our AI tools are being utilized and optimize token usage for cost efficiency.
Original PR description
Tag each completion request with a human-readable label identifying what issued it (the agent, web search, AI field, AI server action, ...) so token usage can be attributed to a given source-model combination. Agent-driven requests are prefixed with "Agent:" to set them apart from feature calls. Example: ``` AI: [Agent: Ask AI] gemini-2.5-flash-lite request [0.68s] - Tokens: 115 in (0 cached)|5 out|0 reasoning AI: [Agent: Ask AI] gemini-3-flash-preview request [2.64s] - Tokens: 5295 in (4050 cached)|79 out|186 reasoning AI: [web search] gemini-3-flash-preview request [21.24s] - Tokens: 562 in (226 cached)|708 out|1343 reasoning AI: [Agent: Odoo Image Generation Agent] gemini-2.5-flash-image request [8.25s] - Tokens: 423 in (0 cached)|1324 out|0 reasoning ``` Forward-Port-Of: odoo/enterprise#118811
This update enhances the creation of TSS (Tax Service Statements) in the Odoo Enterprise system by requiring user confirmation before creation. Once created through Fiskaly, the associated IDs are made read-only, and a copy button is added for easy record retrieval. This improves data accuracy and simplifies tracking.
Original PR description
In this commit: -------------- - We have introduced a “Create TSS” button. The system now asks for user confirmation before creating the TSS and client. - Once the TSS and client are successfully created in Fiskaly, the fields displaying their IDs become read-only. Additionally, a Copy button has been added to allow users to easily copy these values for later investigation or reference. task- 5457231
This update streamlines the import of invoices by introducing a generic reload flow. The system now intelligently prioritizes structured XML attachments over OCR-processed versions, ensuring data accuracy and efficiency. This change improves the reliability of invoice data within the system.
Original PR description
The account module now provides a generic reload flow for imported invoices. Keep the OCR-specific reload data behavior for invoices which must be handled by OCR, while letting invoices with regular imported source attachments fall back to the generic account reload flow. task-6159853 ----------------------------------------------------------------------------------------------------------------- In case there is a structured attachment like xml whether it's the original imported attachment or an embedded one, disable the OCR logic as structured attachments are 100% accurate and don't require digitization tokens so we should always prefer them, for example if the uploaded file is an xml having a pdf as an embedded attachment or the uploaded is a pdf having an xml as an embedded attachment then in both cases we will prefer the xml. task-6158911
2 changes
Enhancements to existing features
This update introduces a new button to streamline the reregistration process for French users, particularly those transitioning between Peppol and PDP systems. It addresses a previous testing issue where changes to the demo company's Peppol settings caused problems during the reregistration flow. This enhancement improves usability and simplifies a key business operation.
Original PR description
#### [IMP] l10n_fr_pdp: fix visibility for peppol (non-PDP) #### [IMP] account_peppol,l10n_fr_pdp: reregister This commit adds a button so that users can reregister more easily. This is i.e. useful to switch from Peppol to PDP for French users. #### meta task-6265603
This update enhances the synchronization of point-of-sale (POS) transactions with Fiskaly, a key partner for German businesses. It separates retail and restaurant order flows, optimizing data transmission and ensuring accurate reporting by only sending updated product quantities during restaurant kitchen synchronization. This improves the reliability of financial data.
Original PR description
In this commit: ------------------ - Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx) orders as discussed with the Fiskaly team. - `Initialize order transactions` with an empty payload when the `first product` is added. - Start `receipt transactions` with an empty payload when the `first payment line` is added. - For retail flows, no intermediate order updates are sent to Fiskaly before finalization. - For restaurant flows, create additional transaction updates during kitchen synchronization. Ensure already synchronized products are not resent, and only newly added or updated quantities are included in the payload. - `Finalize order and receipt transactions` with complete order lines and payment details when we validate the order. task: 6208963 Reference: <img width="1863" height="1285" alt="de_tss_flow" src="https://github.com/user-attachments/assets/9140788e-7948-4a08-9f11-27197b22ca8b" />