Saturday, August 29, 2026
5 changes · 19.0
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
Recurring 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