Saturday, August 29, 2026
8 changes · saas-19.1
New functionality added to Odoo
Odoo now sends outgoing Greek customer invoices through the Greek EDI IAP service and e-invoo, an AADE-certified provider, instead of transmitting them directly to myDATA. This helps Greek businesses issue invoices in a legally compliant way while keeping the process 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 an internal database lookup used to inspect column information, especially during upgrades or operations on large databases. By replacing a slower generic database view with a more focused query, it can reduce time spent on these checks 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
The Twitter/X feed refresh now distinguishes expired or invalid account tokens from other errors. When a connection is no longer valid, the account can be disconnected cleanly instead of showing a confusing error to users.
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 business-to-government invoices are now identified and routed through Chorus Pro instead of the standard Peppol path. This helps companies send invoices to public-sector customers correctly while adding the required status tracking for Chorus Pro processing.
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
Recurring maintenance requests no longer create an extra reminder on the completed request when moving it to a done stage. This keeps reminders focused on the next scheduled maintenance item and avoids confusing duplicate tasks for responsible users.
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 fixes a checkout issue where a new customer's personal contact name could be replaced by their company name when they entered a valid VAT number. Customers and businesses can now submit billing details with both contact and company information without losing the intended contact name.
Original PR description
Steps to produce: --- - Install website_sale module without demo. - Create a new product and publish it. - From the incognito, go to shop and add that product to cart. - While doing checkout > fill…
Steps to produce: --- - Install website_sale module without demo. - Create a new product and publish it. - From the incognito, go to shop and add that product to cart. - While doing checkout > fill the address form. - Add the all details including the company name and valid VAT. (ex. BE0477472701) - Submit the form. Issue: --- - When a public or guest user submits a new address with both a contact name and a company name along with a valid VAT number, the contact's name was being overwritten with the company name. Root cause: --- - The _compute_is_company heuristic in res.partner automatically sets is_company=True for partners with valid VAT. In [commit] `_create_or_update_address`, the condition `elif partner_sudo.is_company:` was designed to rename existing companies, but incorrectly caught newly created individuals marked as companies due to VAT, causing their name to be overwritten instead of creating a parent company. Solution: --- - Replaced the is_company check with explicit conditions: the partner has no parent_id, has contact-type child_ids. - This ensures the rename-company branch only fires for actual company heads that the logged-in user belongs to, not for individuals that happen to have is_company=True due to a valid VAT. [commit]: https://github.com/odoo/odoo/commit/8f3a32170c842f5f42edc79bf8620276f0da7be4 opw-6356772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Helpdesk forms created for a website now keep all available translations, so visitors see the form in the correct website language. This prevents forms from being stuck in the language of the employee who created or edited the helpdesk team.
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 makes text in Point of Sale dark mode forms readable again, including search fields inside popups and order screens. It ensures the POS follows the selected light or dark theme so staff can use these controls without visibility issues.
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