Friday, August 28, 2026
19 changes · saas-19.3
Resolved issues and error corrections
This fix makes text in Point of Sale search and form fields readable when dark mode is enabled. It ensures the POS follows the same light or dark display setting as the rest of Odoo, 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
This update fixes an automated Knowledge calendar test that could fail when creating or editing calendar item properties. It improves release stability by ensuring this validation flow runs reliably without blocking quality checks.
Original PR description
In `knowledge_calendar_command_tour`, we were experiencing two issues 1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to…
In `knowledge_calendar_command_tour`, we were experiencing two issues 1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to not being able to locate the dropdown option to create a new property. This only occurs if you don't set a step delay on the tour. This happens because in the `editSelectMenuInput` helper, we first check if the dropdown is open bfore we proceed. Since the tour runs so fast, we detect that the dropdown for the first property is open, so we pass the check. However, this then closes since we've moved on to the next dropdown, and since nothing has been input into the next dropdown, the create option doesn't appear. Now, we ensure that the create option will be present before attempting to click it 2. Later in the tour, we attempt to edit the properties on a new calendar item. We previously used `edit` to edit the property name, however this resulted in the "Select a template" modal being opened, which broke the tour, since we needed to click elements behind it. Using `fill` instead to populate the text field doesn't produce this behavior, allowing the tour to proceed without error. [runbot-939647](https://runbot.odoo.com/odoo/error/939647?debug=assets) Forward-Port-Of: odoo/enterprise#128830
The Real Margin pivot now keeps the standard analytic entries list available when users drill into details. This prevents users from being sent to the timesheet list by mistake, making project margin review more accurate and less confusing.
Original PR description
**Steps to reproduce:** 1. Open a project. 2. Click on the Real Margin stat button or top menu action. 3. The pivot view opens by default. 4. Click on a cell in the pivot view to drill down into the list view. **Issue:** The system opens the timesheet list view instead of the standard analytic entries list view. **Cause:** Overwriting action['views'] erased the default list view, causing to fall back to the timesheet view during drill-down. **Fix:** Used a list comprehension to inject the custom pivot view while preserving the original view types. Added all view options to the Real Margin top bar. task-6192267
The inventory PDF report now keeps its table columns aligned when warehouse locations are shown. This prevents missing gridlines and broken borders, making printed inventory reports clearer and more professional.
Original PR description
When new columns were added to the stock inventory report, the location grouping row was not updated. This results in mismatched column counts, causing missing gridlines and broken borders in the PDF output Fixed by ensuring the location row's column count matches the header <img width="603" height="200" alt="image" src="https://github.com/user-attachments/assets/86872bee-f315-4bdd-b3f2-a525e3bb5fe0" /> ### Steps to reproduce: - Ensure warehouses are activated in the settings - Go to Barcode -> Count Inventory - Add a Product - Select the gear Icon then "Print Inventory" - You will notice that the location row has missing gridlines opw-6307728 Forward-Port-Of: odoo/odoo#275918
The project real margin grid view has been corrected so the top bar displays as intended. This helps sales and project teams review margin information more clearly and reliably.
Original PR description
- update the grid view in project real margin top bar task-6192267
Belgian payroll meal voucher reports now handle employees with a zero meal voucher amount without crashing. This lets payroll teams generate reports for sick leave or corrected payslip cases while still showing the employee line with a zero total.
Original PR description
**Steps to reproduce:** - In a belgium company - Put an employee in sick time off during a whole month - Generate a mealvoucher report for this month Another steps to reproduce: - Create a payslip for an employee that has mealvoucher input > 0 - Mark the payslip as paid - Put the mealvoucher input at 0 for the employee - Correct the payslip - Generate a mealvoucher for the payslip month **Current behavior:** Crash **Expected behavior:** The line should show lorie poiret in the report with 0 total. It is debatable to either filter out the 0 line from the report or not as it is not a standardized report and that all providers has their interpretation. We decided to show it. task-6487876
This fixes an access error that could occur when Belgian payroll time off allocations were validated. It ensures the validation check can run correctly, reducing interruptions for HR users managing employee leave allocations.
Original PR description
A sudo was missing in the check of the validity of the allocation.
Appraisals now keep the generic template chosen by the user when they are confirmed or reset, instead of switching back to the first available template. This keeps appraisal records accurate and ensures filtering by the selected template continues to work as expected.
Original PR description
Issue: When a user selects a generic appraisal template other than the first one, confirming or resetting the appraisal silently replaces that selection with the first generic template. Filtering…
Issue: When a user selects a generic appraisal template other than the first one, confirming or resetting the appraisal silently replaces that selection with the first generic template. Filtering appraisals by the originally selected template then fails to return the appraisal. Steps to reproduce: * Configure multiple appraisal templates without department restrictions. * Create an appraisal and select a template other than the first one. * Confirm the appraisal. * Filter appraisals by the selected template. Cause: `_compute_appraisal_template()` only preserved templates directly linked to the appraisal's department. Generic templates have no department relation, so a valid selected template was discarded whenever the computation was triggered by a state dependent department recomputation. The generic fallback then stored the first template instead. https://github.com/odoo/enterprise/blob/5c57ccbb13269af28de0a6c7f35454be52424f43/hr_appraisal/models/hr_appraisal.py#L195-L209 Solution: We need to distinguish the generic default loaded on an unsaved form from a compatible generic template already stored on an appraisal. Preserve the latter across recomputations while retaining department template priority during creation and rejecting templates that no longer match the appraisal's department or company. opw-6449041 Forward-Port-Of: odoo/enterprise#127566
This fix makes an automated mail test more stable by ensuring it waits for the correct mention suggestion list, not a separate status update elsewhere on the page. It helps prevent false test failures in Odoo's validation pipeline without changing end-user behavior.
Original PR description
Before this commit, the test "select @ mention from the suggestion list being filtered" could fail on runbot, on the check that follows the first "@": Failed to find 2 of ".o-mail-Composer-suggestion" (Timeout of 10 seconds). Found 0 instead. This happens because the test holds a render open on ImStatus, a component the member list renders as well as the composer. The composer tells the server that the user is typing, the bus sends the status back, and the member list re-renders its ImStatus with another class. The hold catches that render, the one that also brings the suggestions on screen. This commit gives the children of NavigableList an inNavigableList environment flag, and holds the render only on an ImStatus that has it. https://runbot.odoo.com/odoo/error/946282 Forward-Port-Of: odoo/odoo#284872 Forward-Port-Of: odoo/odoo#284484
Customers can no longer set optional products on sales orders to zero or negative quantities through the portal. This prevents confusing or invalid order amounts and keeps special quantity adjustments under salesperson control.
Original PR description
Since the fusion of `sale.order.option` model into `sale.order.line` model, the optional products (editable from portal) lines are not deleted when reaching a quantity of 0 or below. This could allow some customers to set negative quantities, which makes no sense as it's only something that should be set by the salesman if necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284493
This fixes an issue where submitting expenses for multiple companies could send duplicate emails. It helps keep expense communications accurate and avoids unnecessary repeated notifications for users and approvers.
Original PR description
Fix a small issue resulting in mail duplication when submitting expenses from multiple companies that appeared in the infamous 704a5a19 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#284861 Forward-Port-Of: odoo/odoo#283013
Updated an automated social CRM test to use a unique test contact name, avoiding conflicts with existing demo data. This prevents false test failures and helps keep validation of CRM conversion behavior stable across module setups.
Original PR description
The social CRM conversion test creates a partner named "John Doe" and expects the post-to-lead wizard to automatically match it. This relies on "John Doe" being unique in the database. Since `pos_restaurant.customer_1` is also named "John Doe", the wizard's `name_search()` can return multiple partners depending on the modules already installed when the test is run. In that case, the wizard correctly considers the match ambiguous and leaves `partner_id` empty, causing the test to fail. This commit uses a test-specific author name instead, ensuring that the test actually provides the single matching partner described by its docstring and does not depend on unrelated demo data or module installation order. [error-243065](https://runbot.odoo.com/odoo/error/243065)
Copying an image that was already linked to another record now reuses the existing attachment instead of leaving an unnecessary duplicate. This keeps stored website or editor content cleaner and avoids redundant files accumulating behind the scenes.
Original PR description
Copying an image attachment already linked to another record could leave a redundant duplicate behind instead of reusing the existing one. opw-6463012 Forward-Port-Of: odoo/odoo#284610 Forward-Port-Of: odoo/odoo#282287
Delivery fee lines no longer appear in the Invoiced not Delivered report because they are not items that need to be delivered. This makes the accounting review more accurate and prevents users from investigating false delivery discrepancies.
Original PR description
Issue: --- Delivery lines are included in `invoiced not delivered` report, which is wrong as delivery lines are not deliverable. Steps: 1- Create a SO with a good product and add a delivery line. Set the product line as delivered and create an invoice. 2- Open accounting, and from review tab, open `Invoiced not Delivered`. As you see, delivery lines are included in the report. Fix: --- On stable we could fix it inside `_get_accrual_domain` by checking if `delivery` is installed. On master we need to implement a solution to be able to differentiate the lines that won't be delivered. opw-6360894 Forward-Port-Of: odoo/enterprise#123517
Self-order restaurant receipts now include the customer's name on preparation tickets. This helps staff identify orders more easily and reduces confusion during food preparation and pickup.
Original PR description
The customer name is written in `floating_order_name` which is never passed to the preparation receipt in self order. This commit fixes it.
This fix makes an automated CRM forecast check wait until a lead is fully marked as won before continuing. It reduces random test failures in the deployment pipeline, helping teams get clearer validation results without changing business functionality.
Original PR description
The crm_forecast tour is red randomly on runbot on the Won banner step. We click the won button and go back directly, so the kanban can be loaded before the lead is won. Now we wait for the ribbon first. runbot-242139 Forward-Port-Of: odoo/odoo#284721
This fix prevents an unexpected error from appearing when the system handles certain report actions. It improves reliability for users by avoiding a disruptive traceback in affected workflows.
Original PR description
opw-6360013 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#274977
The French PDP registration wizard no longer shows an unnecessary “Production” label when the system is already in production mode. This avoids confusing wording for users during registration and makes the setup flow clearer.
Original PR description
It makes no sense to mention (Production) on pdp registration wizard when you are in prod mode Forward-Port-Of: odoo/odoo#280501 Forward-Port-Of: odoo/odoo#280360
Invalid VAT warning messages now show the exact VAT number entered by the user instead of dropping part of the country prefix. This reduces confusion for users validating or importing customer tax details and makes it easier to correct invalid VAT entries.
Original PR description
Before this change: When entering or importing a VAT number (e.g., CHE-115.391.649), an invalid VAT warning displays a string missing its country_id (e.g., E-115.391.649). This confuses users and masks the actual input string that triggered the validation failure. To reproduce: 1. Open any contact record and set the Country to Switzerland. 2. Enter an invalid or manually formatted Swiss VAT number like `CHE-115.391.649`. 3. Save or trigger the VAT validation check. 4. Observe the warning banner showing `E-115.391.649` instead of `CHE-115.391.649`. After this change: The validation warning logic preserves the original user input when constructing the alert message, ensuring error notifications accurately display VAT number. Issue introduced by: * https://github.com/odoo/odoo/commit/ac95d2d6d80a368dfb190d0ac21da2af479a8488 * https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0 opw-6474217 Forward-Port-Of: odoo/odoo#284305