Friday, September 11, 2026
19 changes · master
New functionality added to Odoo
Field Service managers can now plan daily work using a combined map and timeline view, making it easier to balance routes, locations, and schedules at the same time. The two panes stay synchronized for folding, hovering, routes, stop numbers, and resource colors, reducing confusion during dispatch planning.
Original PR description
Introduces a new "Map Timeline" view for Field Service (Maps > Timeline), combining a map and a Gantt timeline side by side so managers can plan daily interventions from both a spatial and a temporal angle at once, grouped by resource, with inherited features (create, edit, drag-and-drop, buffer times, routing, etc.) preserved in both panes. On top of the base view, the map and timeline are also kept coherent with each other: - folding a resource group in one pane folds it in the other, including the "Open Shifts" and "Shifts to assign" groups - hovering a pin, a pin group, or a shift highlights its counterpart(s) across the map and the Gantt, as well as their side panels - hovering a pin group also highlights its route on the map, with stop numbers shown along it - resource colors (including materials) stay consistent across the Gantt, the map pins, and the map side panel task-6273718 Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com>
Adds a French annual report template aligned with the official Plan Comptable Général format, helping companies prepare the required reporting document in Odoo. The update also reuses information already available in fiscal declarations to reduce duplicate data entry and make the report more practical to complete.
Original PR description
The French companies have to submit a report containing a lot of info on their business. That report format is dicted by the Plan Comptable Général (PCG), Titre VIII. This PR adds a new knowledge article template for the Annual Report in accounting, following the format described by the PCG. Heavily helped by AI. task-6349733
Odoo Social now supports direct messages for Facebook and Instagram pages, making it easier for teams to manage private customer conversations from social channels. Businesses can also use AI assistance to respond when operators are unavailable, while respecting Instagram messaging rules and account requirements.
Original PR description
Purpose ======= Support direct messages for Facebook and Instagram pages. For Instagram, we have 24h to respond to a user, we also need to inform the Instagram user that he's talking to an automated…
Purpose
=======
Support direct messages for Facebook and Instagram pages.
For Instagram, we have 24h to respond to a user, we also need
to inform the Instagram user that he's talking to an automated
agent when it's the case. Only professional account are supported.
See https://developers.facebook.com/docs/instagram-platform/instagram-api-with-instagram-login/messaging-api/
When a message arrive, we fetch the last messages to get the user / LLM
some context of the previous conversation. One limitation for Instagram,
when fetching the message, we can get only the 20 last messages.
See: https://developers.facebook.com/docs/graph-api/reference/v25.0/conversation
Like `ai_livechat`, we can configure an LLM to answer to the user
(if no operators are available, etc). For traditional live chat, the
visitor has a button "Ask Human". This is not possible for all media,
so the LLM has a tool and it can ask a human when it's necessary.
Configuration Facebook
======================
Configure the webhook URL in the settings of the application
("Messenger" -> "Messenger API Settings" -> "Configure webhooks")
Configure the verify token in the settings of Odoo / IAP with the value
you want (you will need to use the same token in the Facebook
application settings).
Enter
- "<url of the database>"/social_facebook/webhook
- "<url of IAP>"/api/social/facebook/1/webhook
Then subscribe to the "messages" and "message_reactions" in the list.
The permission `pages_messaging` and `pages_manage_metadata` are needed.
Configuration Instagram
=======================
For Instagram, we need to setup the callback URL in "Messenger -> Instagram Settings",
the configuration is very similar to the Facebook steps.
Task-5948062Adds support for India's GST Composition Tax Scheme for eligible businesses, including company registration settings, composition tax rates, and purchase tax handling where input tax credit is not allowed. It also updates GST reporting and hides features that do not apply to composition taxpayers, such as e-Invoicing and HSN validations.
Original PR description
Previously, only the regular GST scheme was supported. India also provides the Composition Tax Scheme for eligible taxpayers, including goods suppliers with an annual turnover of up to ₹1.5 crore and service providers with an annual turnover of up to ₹50 lakh. This commit adds support for the Composition Tax Scheme. Added features: - Add a GST registration type and composition tax rate on the company. - Add composition purchase taxes, as taxpayers under the Composition Scheme cannot claim Input Tax Credit (ITC), and the tax amount must therefore be included in the cost of goods. - Add the `sale_composition_supplies` GSTR section for composition supply sales move lines. - Add a new `composition` value to `l10n_in_tax_type` for composition taxes. - Hide features that are not available under the Composition Scheme, such as e-Invoicing and HSN validations. ent:https://github.com/odoo/enterprise/pull/121367 upg:https://github.com/odoo/upgrade/pull/11250 task-3637966
The website AI assistant can now review external webpages to gather text, images, and screenshots for better page creation. It also saves externally referenced AI images into Odoo attachments when pages are saved, improving reliability and ownership of generated website content.
Original PR description
Added a new ai tool that allows the website ai agent to access webpages. It has the option to receive the text, images and screenshot for each indiviual page. The tools allow the ai agent to take inspiration from existing pages, provide appropriate sources and thanks to images tend to make the end result prettier. Since the ai will copy external image urls into the html, a new process has been added to download and save the images as attachments. This happens on all tagged images (all images produced by the ai are automatically tagged) when a page is saved. This works thanks to an async call to the website scraper server, this is the reason behind the new 'external' tool confirmation mode. Since the call is async, we need a way to resume the conversation once the result is finished. Since this process can be long (1-2 minutes), we hide the composer to prevent user from sending new messages while this is happening. Task: https://www.odoo.com/odoo/project/974/tasks/6143475
Adds support for Pakistani retailers to report paid POS orders to the Federal Board of Revenue in real time through Odoo. Receipts and invoices now include the required FBR invoice number and QR code, helping businesses meet local fiscal compliance requirements.
Original PR description
Description of the issue/feature this PR addresses: The Federal Board of Revenue (FBR) requires Pakistani retailers to report every POS sale in real time and print the returned fiscal invoice number…
Description of the issue/feature this PR addresses: The Federal Board of Revenue (FBR) requires Pakistani retailers to report every POS sale in real time and print the returned fiscal invoice number and QR code on the receipt. This PR adds l10n_pk_edi_pos to implement this for the Pakistani localization. Current behavior before PR: Odoo POS has no FBR integration: orders are not reported to the tax authority and receipts carry no FBR invoice number or QR code. Desired behavior after PR is merged: Each paid POS order is submitted to the FBR through the IAP proxy. The FBR invoice number and QR code are stored on the order and printed on the receipt and customer invoice; invoicing stays blocked until the order is reported. Refunds, the FBR service fee, 3rd Schedule products, buyer NTN/CNIC reporting and a sandbox mode are supported, all configured from the Point of Sale settings. task-4426796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The ESG app now replaces the former project-based approach with dedicated policies, actions, and targets, making sustainability work easier to structure and track. These items are also reflected in VSME and CSRD reporting templates, helping businesses align operational ESG plans with reporting requirements.
Original PR description
task-5253296
Odoo Sign now lets each signer apply their own itsme qualified electronic signature to documents, instead of relying only on the company seal. This strengthens signer attribution and supports stricter legal signing flows, while preserving existing signatures as documents move through each signing step.
Original PR description
Lets each signer sign the document with their own itsme® qualified certificate, producing a qualified electronic signature (QES) attributable to the signer instead of the company seal alone. In sign,…
Lets each signer sign the document with their own itsme® qualified certificate, producing a qualified electronic signature (QES) attributable to the signer instead of the company seal alone. In sign, the completed document is now built as a chain of incremental updates over the original bytes and sealed once at the end, so the signatures already applied stay valid. The model `sign.completed.document` becomes `sign.request.document`, a working copy that belongs to one request and carries the file through its whole life. A signer can now sign the document themselves (using external service), which puts the request in a strict signing order so that every signature covers the contributions made before it, and freezes the file while their signature is being produced before it is embedded or discarded. Because such a signature attests values that must not move under it, the flow is guarded on every side. The signer reviews the frozen bytes before their signature is collected. An answer changed afterwards gives the pending attempt up instead of signing content that is no longer current. The authentication of a role can no longer change once its turn has started, and a request can only hold one working copy per document. Those working copies and the signatures they carry are read only for sign users and they are removed together with the request. Signing for everyone in one session is refused if at least one signer signs the document externally, because each of them has to sign in person. In `sign_itsme`, a new signing role produces the signature with itsme®, charged in itsme® credits. Unlike the identity check it cannot be skipped when credits are missing, because here the qualified signature is the signature itself. A signer can sign several documents of the same request in one itsme® action (up to 70 documents). `sign_emsigner` is adapted to the incremental flow. --- task-4951149 Depends on odoo/odoo#253372 (incremental PDF signing utilities) and on the "generalize PDF signing with incremental merge" PR this branch is stacked on, #110345.
Enhancements to existing features
Point of Sale now applies employee role permissions more consistently across planning, settle-due, appointment, barcode lookup, sales planning, and UrbanPiper-related screens. This helps businesses limit sensitive actions to authorized staff and reduce operational mistakes at checkout and order management.
Original PR description
**= planning, settle_due, urban_piper Following this commit: ==== - Restricted POS features based on the employee's assigned role. task-6317141 Community PR : https://github.com/odoo/odoo/pull/284182 Upgrade PR : https://github.com/odoo/upgrade/pull/11117
Resolved issues and error corrections
Peruvian point-of-sale receipts now wait for the electronic invoice authorization data needed to print a valid legal receipt. The change keeps checkout efficient by delaying PDFs and emails as before, while ensuring the QR code and summary hash are available immediately on the printed receipt.
Original PR description
In Peru, the printed PoS receipt is the legal electronic invoice/receipt (Factura/Boleta Electronica): it must carry the QR code and the summary hash from the signed e-invoice. Since 19.4, PoS…
Code cleanup and technical improvements
Point of Sale employee roles have been renamed to clearer business terms and a new supervised role has been added. POS actions are now limited according to each employee's assigned role, helping businesses better control who can perform sensitive operations.
Original PR description
Following this commit: ==== - New `PosAccessRightPlugin` plugin has been inroduced for managing employees role in pos. - Minimal Employee has been renamed to Restrictive. - Basic Employee has been renamed to Cashier. - Advanced Employee has been renamed to Manager. - Introduced the Supervised Employee role. - Restricted POS features based on the employee's assigned role. task-6317141 Enterprise PR : https://github.com/odoo/enterprise/pull/128957 Upgrade PR : https://github.com/odoo/upgrade/pull/11117
AI agents can now build their knowledge from attachments, documents, knowledge articles, and web pages without first copying everything into attachments. This makes the AI knowledge system more flexible, improves cross-source answers, and avoids showing not-yet-processed content in search results.
Original PR description
Before, `ai.embedding` was geared specifically towards `ai.agent.source` and its attachments: every source had to materialise an `ir.attachment` before it could be vectorised, and RAG retrieval could…
Before, `ai.embedding` was geared specifically towards `ai.agent.source` and its attachments: every source had to materialise an `ir.attachment` before it could be vectorised, and RAG retrieval could only look at one model at a time. This PR generalises the embedding layer so that any model can be embedded and retrieved, and converts the existing source types to use it. ### `ai.embedding.mixin` New mixin owning the `embedding_ids` one2many and the embedding lifecycle. A model inheriting it implements the hooks: content extraction, chunking (tabular-aware), duplicate detection by checksum, domain of the records to embed, and the embedding models to use. Embedding creation is cron-driven, which supersedes `_update_sources_status`. `ai.embedding` itself loses `attachment_id`/`checksum` and gains `res_model`/`res_id`, so a chunk can point at any record. ### Direct embedding of every source type | Source | Before | Now | |---|---|---| | Attachment | embedding logic carried by `ir.attachment` | `ir.attachment` inherits the mixin | | Document | copied into an attachment, then embedded | `documents.document` embedded directly | | Knowledge article | HTML extracted into an attachment | `knowledge.article` embedded directly | | Web page | fetched into an attachment | `ai.web.page` embedded directly | The attachment-copy flows (`_sync_sources_content`, `_recreate_attachments_for_sources`) are dropped. Each model only picks up the records actually linked to an agent source. ### Retrieval - `_get_similar_chunks` now takes a `target_by_model` mapping instead of a single `res_model`, so one similarity search spans embeddings of heterogeneous models. `ai.agent.source._get_rag_target` is the overridable hook returning the (model, id) pair a source is embedded through, and `_get_models_map` builds the mapping. - Chunks whose `embedding_vector` is still NULL are excluded from retrieval. Their similarity was NULL and `NULLS FIRST` is the default for `ORDER BY ... DESC`, so between the creation of a source and the next cron run they outranked every genuine match and took all the `top_n` slots. ### Citations Inline citations reference `ai.agent.source` ids instead of attachment ids, and the link rendering is delegated to `_get_source_link`, implemented per source type (attachment/url in `ai`, document in `ai_documents_source`, article in `ai_knowledge`) instead of a hardcoded `/web/content` URL. The prompt instructions are updated accordingly. ### Also in this PR - `ai.agent.source.type` becomes a computed field, derived from whichever record field is set (`attachment_id`, `web_page_id`, ...). - `ai_app` accepts `.md` files as agent sources: the allowed extensions are extracted into a single `allowedExtensions` getter used both by the file input `accept` attribute and by the client-side validation. Markdown attachments are indexed as plain text, so no server-side change is needed. task-6283960 Upgrade PR: odoo/upgrade#10929
Approval requests no longer require approvers to act in a predefined sequence, so any assigned approver can approve when ready. This removes waiting statuses and next-approver handoffs, making approval workflows faster and less dependent on a strict order.
Original PR description
Previously, there was a sequence or ordering in approvals, the user was not able to approve if it is order hasn't come yet. 1 - Sequence field is deleted, there is no waiting status anymore. 2 - Setting the next approver mechanisms are dropped Test: Unit test to check random ordering in approvals task-6563332
Payroll runs now open directly on the payslips step, removing the previous multi-step flow and making payroll processing more direct. Key payroll actions have been moved to the main toolbar, with list and kanban views updated to keep important status, journal, and action information easy to access.
Original PR description
This PR aims to to completely remove the payrun steps logic (which could be visualized as bubbles in the header of any payrun views). Instead of having the `versions -> time -> payslips` flow, we now…
This PR aims to to completely remove the payrun steps logic (which could be visualized as bubbles in the header of any payrun views). Instead of having the `versions -> time -> payslips` flow, we now always end up on the payslips step by default, which is now the only step left! The payrun button used to validate/mark as paid/pay the payrun has been moved next to the "New" button at the top right corner. Since it relied on a custom compiler and rendering context, we had to move all of that from the payrun layout/payrun mixing to the payrun control panel. Other minor UI changes have been introduced, such as: - Added the states and the journal button in the payrun list view - Added back the action buttons (the one needing a custom compiler) on the kanban view cards - Added some columns on the payrun list view - Added back the paid time off allocation wizard - Added a variant to the t-menu of the kanban cards (that gets generated to a PayRunButtonBox) to make its three vertical dots render as a "More" button instead. - etc. (see the task's escalidraw) task-6486910
Odoo’s PayPal integration now supports guided seller onboarding, more local and alternative payment methods, and saved payment details for eligible merchants. This helps businesses activate PayPal faster, offer customers more ways to pay, and support repeat or subscription-style payments more easily.
Original PR description
**[IMP] payment_paypal: add seller onboarding via OAuth** First party Integrated Sign-Up enables partners to integrate the seller onboarding into their software allowing to seamlessly and securely…
**[IMP] payment_paypal: add seller onboarding via OAuth** First party Integrated Sign-Up enables partners to integrate the seller onboarding into their software allowing to seamlessly and securely onboard sellers before activating PayPal payments. In this commit, we integrate First party Integrated Sign-Up to Odoo. --- **[IMP] payment_paypal: add payment methods** We currently only support PayPal Wallet, but PayPal can also be integrated as a regular payment provider, offering many payment methods, and worldwide coverage. In this commit, we add the following payment methods: - Via PayPal's JS SDK: Pay Later, Venmo, and Advanced Credit and Debit Cards. - Via Orders API: Bancontact, BLIK, EPS, iDEAL, Multibanco, MyBank, Przelewy24, and Trustly. We also migrate PayPal Wallet integration from JS SDK to Orders API to uniformize the look of payment methods through different payment providers. --- **[IMP] payment_paypal: add tokenization support** Before this commit, customers had to re-enter their payment details for every PayPal transaction, and merchants could not charge them offline (e.g., for subscriptions or invoice follow-ups). This commit introduces the ability to tokenize PayPal Wallet and PayPal-provided cards. Tokenization is available if the merchant's account has the advanced vaulting capability enabled. We also handle the case where PayPal creates the vault asynchronously, generating the token via a webhook rather than the immediate checkout response. --- task-6095035
This update improves Odoo VoIP reliability when users receive calls across multiple browser tabs or devices, reducing duplicate call records and missed rings. It also adds QR-code setup for Linphone mobile calling and exposes a protected recovery payload so phone service tenants can be rebuilt if accidentally deleted.
Employee, payroll, and project document folders are now created and connected to the right business records automatically, reducing setup gaps and manual synchronization. HR and payroll access now relies on role-based groups, so new officers can access the relevant company folders without extra updates, while uploaded documents are linked to the correct employee or project more reliably.
Original PR description
### HR refactor Every feature of the HR bridges had to check `documents_hr_settings` and the existence of the company folder before doing anything. Those guards were fragile, easy to forget, and made…
### HR refactor Every feature of the HR bridges had to check `documents_hr_settings` and the existence of the company folder before doing anything. Those guards were fragile, easy to forget, and made the bridges harder to extend. As recently done for the other bridges, an installed bridge is now always used: the "Employees" folder of a company is required and created with it, and every employee of an active company gets their folder(s). Sharing relies on functional groups rather than on a copy of the HR (resp. payroll) officers on each folder, so a new officer reaches the folders of their companies without any resynchronisation. All payroll documents now end up in the employee's Payroll folder, which belongs to documents_hr_payroll alone. ### Documents mixin for employees and projects Employee and Project *folders* are now also linked to the record they belong to and documents inherit that link from their parent folder. Therefore, documents uploaded in such folders will automatically be linked to the record. Task-6344800 Task-6310302
Invoices and sales orders in the South Korea localization can now record the proof of issuance used for each transaction, such as tax invoice, credit card, or cash receipt. This improves VAT report accuracy and reduces manual setup by using customer or vendor defaults while simplifying the tax list businesses need to manage.
Original PR description
South Korean tax law classifies each transaction under a specific proof of issuance (세금계산서, 계산서, 신용카드, 현금영수증, ...), and which VAT report box a transaction is reported under depends on that…
South Korean tax law classifies each transaction under a specific proof of issuance (세금계산서, 계산서, 신용카드, 현금영수증, ...), and which VAT report box a transaction is reported under depends on that classification, not just on its taxes. Add `l10n_kr_issuance_type` to `account.move` so this can be recorded per invoice and used to drive VAT report generation. Since a given customer or vendor typically uses the same proof of issuance across transactions, add `l10n_kr_default_issuance_type` on `res.partner` (under Customer Invoices) so users don't have to pick it manually every time. `sale.order` carries the same field and passes it along when an invoice is created from the order, so issuance type can be set from the Sales app without needing access to Accounting. Also add: - `l10n_kr_edocument_number` on `account.move`, next to Customer Reference, to record the e-document number issued for the transaction. - South Korea's Tax ID label (`res.country.vat_label`) as "BRN" (Business Registration Number), matching local terminology. Now that proof of issuance is tracked separately, the `account.tax` templates no longer need one tax per rate/issuance-type combination: collapsed ~64 taxes (e.g. separate `10% TI`, `10% CR`, `10% Card` sales taxes) down to ones keyed only by rate and nature (standard, zero-rated, exempt, fixed-asset, non-deductible, deemed/recycled input VAT, ...), carrying just the base VAT tag. `general_tax_report.xml` and `simplified_tax_report.xml` were updated to derive their per-issuance-type boxes from `l10n_kr_issuance_type` on the move directly instead. [task-6216393](https://www.odoo.com/odoo/my-tasks/6216393)
Loyalty programs can now set an expiration period for earned points, helping businesses manage outstanding rewards more accurately. Customers can see when their points expire, and the system uses points nearing expiration first so balances better reflect usable rewards.
Original PR description
Loyalty points had no expiry, and `loyalty.history` was only a log kept beside the balance: `loyalty.card.points` was a stored column, and the rows recorded what an order earned and spent without either side being authoritative. Expiring points needs to know which points are which, so the history becomes the balance itself. `points` is now computed from it, and a row records one movement in one direction. A line spending points links to the award it draws from, so it stops counting once those points expire, and a spend with no award behind it never expires. Awards are drawn from oldest expiry first, so the points closest to lapsing are used before the ones that are not. Programs of type `loyalty` gain an `expire_after` delay in days, and the portal shows the customer when each award expires. task-4711900 Enterprise PR: https://github.com/odoo/enterprise/pull/125634 Upgrade PR: https://github.com/odoo/upgrade/pull/10869
In Peru, the printed PoS receipt is the legal electronic invoice/receipt (Factura/Boleta Electronica): it must carry the QR code and the summary hash from the signed e-invoice. Since 19.4, PoS invoice PDF/EDI generation became asynchronous by default (deferred to a cron) to speed up checkout, but l10n_pe_edi_pos was never updated to opt out of that for Peru, so the signed data doesn't exist yet when the receipt is printed right after validating the order. Steps to reproduce: ------------------- * Install l10n_pe_edi and activate SUNAT Signature Provider Setting * Create and validate a PoS order and set "invoice" to true * Print the receipt (Full Receipt or Simplified Receipt) > Observation: Neither receipt includes the QR code or the summary hash, so the printed receipt is no longer a valid electronic document. Why the fix: ------------ Forcing the whole invoice (PDF + email + e-invoice) to be generated synchronously would block checkout on a live SUNAT call, and would leave failed orders with no way to be retried by the deferred-invoice cron. PosOrder._generate_pos_order_invoice() now lets the PDF/email stay deferred to the cron as before, but posts the e-invoice to SUNAT synchronously on its own (no PDF, no email), so the receipt gets its QR code/hash right away. This matches the pattern already used by l10n_sa_edi_pos (generate_pdf=false + a synchronous EDI-only step), as opposed to l10n_co_edi_pos, the only module forcing generate_pdf=true. A chatter message is posted on the invoice if SUNAT rejects it, since calling the EDI step directly bypasses the notification that account.move.send would otherwise post. opw-6426510 Forward-Port-Of: odoo/enterprise#126345