Saturday, August 29, 2026
8 changes · saas-19.2
New functionality added to Odoo
Adds support for sending Greek customer invoices through e-invoo, an AADE-certified provider, instead of transmitting them directly to myDATA. This helps Greek businesses stay compliant with local e-invoicing requirements while keeping invoice issuance integrated in Odoo.
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
This update speeds up internal database column lookups by using a more focused query instead of a broader system view. It reduces time spent on these repeated checks, which can make upgrades and module-heavy operations run more efficiently without changing user-facing behavior.
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#285419
Forward-Port-Of: odoo/odoo#216309Resolved issues and error corrections
When an X/Twitter account token becomes invalid, the system now disconnects the account instead of showing a generic error during feed refresh. This avoids confusing interruptions and guides users toward reconnecting the account to restore service.
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
French B2G invoices can now be identified and routed through Chorus Pro instead of Peppol when the customer is linked to the Chorus Pro platform. This helps businesses comply with French public-sector e-invoicing requirements while adding the needed invoice status tracking for Chorus Pro flows.
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
Helpdesk ticket forms on websites now keep their translations when generated for a team. This ensures customers see the form in the website or visitor language, regardless of the staff member's language settings when the team was configured.
Original PR description
When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the…
When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language. Steps to reproduce ================== 1. Set a language other than English as the website default language. 2. While your user language is English, create a helpdesk team with the website form enabled. 3. Open the team form on the website. => The form is rendered in English instead of the website language. Root cause ========== `_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view. Fix === Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language. opw-6303903 Forward-Port-Of: odoo/enterprise#129265 Forward-Port-Of: odoo/enterprise#121164
This fix ensures the Sign app uses the correct access group settings for users. It helps keep signing permissions consistent, reducing the chance of users seeing incorrect access behavior.
Original PR description
opw-6518598 Forward-Port-Of: odoo/enterprise#129647
This update replaces an older loop-writing style with the preferred clearer wording in a few internal server and IoT files. It helps keep automated quality checks passing and supports easier long-term maintenance without changing business functionality.
Original PR description
Ruff checks on runbot flagged `while 1:` Preferred syntax is to use `while True` [UP048](https://docs.astral.sh/ruff/rules/while-one) runbot-945983 Forward-Port-Of: odoo/odoo#284837 Forward-Port-Of: odoo/odoo#283962
This update makes text in Point of Sale search and form fields readable when dark mode is enabled. It improves usability for staff working in dark mode by ensuring browser-rendered controls follow the correct visual theme.
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