Saturday, August 29, 2026
8 changes · 19.0
New functionality added to Odoo
Odoo adds a new Greek e-invoicing bridge so customer invoices are sent through the Greek EDI IAP service and e-invoo, an AADE-certified provider. This helps Greek businesses meet legal e-invoicing requirements instead of transmitting invoices directly to myDATA.
Original PR description
Greek customer invoices were transmitted directly to myDATA, but this is not legally compliant as odoo is not AADE-certified yet. Add a bridge module that routes outgoing Greek invoices through the Greek EDI IAP service and e-invoo, an AADE-certified YPAHES provider. IAP PR: [1788](https://github.com/odoo/iap-apps/pull/1788) task-[6395556](https://www.odoo.com/odoo/project/967/tasks/6395556) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281739
Enhancements to existing features
French electronic invoicing now identifies business-to-government customers through the official directory and routes those invoices through Chorus Pro instead of Peppol. Businesses can handle public-sector invoices more accurately while using existing Chorus Pro fields, with added status tracking for sent, suspended, and completed invoices.
Original PR description
B2G invoices are not sent via Peppol but to Chorus Pro (via the approved platform). Chorus Pro is the platform with ID 9999 on the annuaire. Any invoice to partner associated with that platform on…
B2G invoices are not sent via Peppol but to Chorus Pro (via the approved platform). Chorus Pro is the platform with ID 9999 on the annuaire. Any invoice to partner associated with that platform on the annuaire is considered B2G (business to government). From a user point of view nothing much changes, except that they have to set some additional fields for which we rely on the existing module `l10n_fr_facturx_chorus_pro`. From a technical PoV we store the information whether a partner is behind Chorus Pro in the `peppol_supported_documents` field. (By putting the special document identifier for Chorus Pro invoices there.) We retrieve the information whether a partner is behind Chorus Pro / B2G from the annuaire lookup. The following new lifecycle statuses have been added. They are required for the functional tests for the Chorus Pro connection. - Sent (sent by the platform) - Suspended - Completed (to "resume" the "Suspended" state) See the related IAP PR: https://github.com/odoo/iap-apps/pull/1804 task-6278159 Forward-Port-Of: odoo/odoo#284677
Resolved issues and error corrections
When a connected X/Twitter account token becomes invalid, the system now disconnects the account instead of showing a generic error while refreshing the feed. This prevents avoidable disruption and gives users a cleaner path to reconnect the account.
Original PR description
Bug === If the token because invalid, then an UserError is raised instead of disconnecting the account. This is because we "blind raise" all errors we get from X, instead of filtering the error linked to the stream configuration. Task-6499283 Forward-Port-Of: odoo/enterprise#129560 Forward-Port-Of: odoo/enterprise#129110
This change speeds up internal database column checks by using a more direct query instead of a slower standard database view. It can reduce time spent on these repeated checks during upgrades or operations on large databases, improving overall backend performance without changing user-facing features.
Original PR description
Using the view `information_schema.columns` is slow compared to a simplified query using PG catalog tables. Here we propose to cherry pick the parts of the view that we actually use. Below we show…
Using the view `information_schema.columns` is slow compared to a simplified query using PG catalog tables. Here we propose to cherry pick the parts of the view that we actually use.
Below we show the timings of both queries as reported by the system on an upgrade 18->master with a runbot DB (many modules installed). All values are in milliseconds.
```
Original:
min: 0.931
max: 16.786
mean: 1.8790601284296555
sum: 25750.64
len: 13704
New:
min: 0.224
max: 11.832
mean: 0.8649024372446001
sum: 11852.623
len: 13704
```
Total time spent in queries was halved as seen in the `sum` statistic above.
Technically, the new queries are base on the original information schema view definition as returned by `\d+ information_schema.columns`. With all unused info removed.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#285220
Forward-Port-Of: odoo/odoo#216309Recurring preventive maintenance requests no longer create an extra reminder on the completed request when the next request is generated. This keeps activity lists cleaner while preserving the correct reminder on the new maintenance request.
Original PR description
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an…
Steps to reproduce: 1. Create a maintenance request with these values: * Maintenance Type: Preventive * Recurrent: enabled * Repeat Every: 1 day, forever * Scheduled Date: today 2. Confirm that an activity is created for the responsible user. 3. Mark the activity as done. 4. Move the request to `Repaired`, or another done stage. 5. Check the newly generated request in the recurring series. When a recurrent maintenance request is moved to a done stage, Odoo creates the next request in the series. The existing activity on the completed request is marked as done and automatically unlinked by `activity_feedback()`. Previously, `activity_update()` was then called on all requests whose stage changed. Since the completed request no longer had a pending activity, this created a new one on that request. The newly generated recurring request also received its own activity, resulting in one activity on the completed request and another on the new request. Only call `activity_update()` for requests that remain in a non-done stage. This prevents a new activity from being created on a completed request while preserving the reminder on the next recurring request. opw-6409396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279470
This update fixes several issues in Odoo's website and text editing experience, including formatting selections, table editing, carousel saving, and style handling. It also tightens some internal platform behavior to reduce compatibility problems and improve stability for developers and customers.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale interface now correctly adapts form fields to dark mode. This prevents search and input text from appearing too dark to read, improving usability for staff working in dark mode.
Original PR description
**Description of the issue/feature this PR addresses:** When using the POS in dark mode, certain form control elements display black text on a dark background, making them illegible. This occurred…
**Description of the issue/feature this PR addresses:** When using the POS in dark mode, certain form control elements display black text on a dark background, making them illegible. This occurred because the POS application lacked the `color-scheme` CSS property. While the backend web client correctly applied this property, its absence in the POS meant the browser still assumed a light theme, forcing default User Agent styles (black text) onto native form controls that escaped standard view helpers. This commit resolves the issue by applying the `$o-webclient-color-scheme` variable to the POS application. This signals the browser to render form controls and UI elements based on the current web client color scheme, ensuring text remains legible within the POS app. **Steps to reproduce:** - POS > Open Restaurant Register - Hamburger icon (top right) > Switch to Dark Mode - Register > vertical ellipses icon (bottom left) > Quotation/Order > type in the search bar > observe black text on dark grey background **Current behavior before PR:** <img width="1911" height="588" alt="Before 1" src="https://github.com/user-attachments/assets/99581745-23eb-45e1-96f7-bca78853369c" /> <img width="1919" height="550" alt="Before 2" src="https://github.com/user-attachments/assets/b7eb9726-e2d2-492b-ad2b-6c0cc6613bb8" /> **Desired behavior after PR is merged:** <img width="1910" height="433" alt="After 1" src="https://github.com/user-attachments/assets/419b7a2a-234e-47c8-854e-22adf6a7c5c1" /> <img width="1915" height="513" alt="After 2" src="https://github.com/user-attachments/assets/8f1cf5c9-5ad1-4aac-9879-840d6d9d537e" /> opw-6508945 Forward-Port-Of: odoo/odoo#284831
Users requesting a French PDP migration now see a consistent message instead of an inaccurate “available tomorrow” timeline. This helps avoid confusion by setting clearer expectations while the migration status cannot yet be shown individually.
Original PR description
Currently when the user requested a migration, we don't show it in any way to the user, and the only timeline we give ("available tomorrow") is completely false. Because we don't have any field we could use for this client-side (maybe from 19.3 we can use the catch-all-json field) So just make the message same for everybody.
no-task
Forward-Port-Of: odoo/odoo#283702
Forward-Port-Of: odoo/odoo#283594