Wednesday, October 15, 2025
31 changes · saas-18.3
Resolved issues and error corrections
Payroll work entry generation no longer fails when a fully flexible employee has overlapping sick leave and a public holiday. This prevents blocking errors during payroll preparation for companies using flexible schedules and overlapping leave scenarios.
Original PR description
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry…
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation when sick leave overlaps with public holiday **Steps to Reproduce:** 1. Go to the **Employees** app and create a new employee. * Set the working hours to **empty (fully flexible)**. 2. Go to **Contracts** and create a new contract. * Set the **Work Entry Source** to *Attendance*. * Save and make the contract **Running**. 3. Go to **Time Off** → **New**, and create a sick time off for the employee. * Example: from **25th to 29th**. * Approve the time off. 4. Go to **Configuration** → **Public Holidays**, and create a new public holiday. * Example: **27th**, which overlaps with the sick time off. * Work Entry Type = **Paid Time Off**. 5. Go to **Payroll** → **Work Entries**. * A **traceback** occurs. **Root Causes:** - In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types. **Fix:** - Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types This resolves payroll blocking issue for deployments using the Fully Flexible employee feature, where employees may have overlapping leave types and no assigned working calendar. Test : [PR](https://github.com/odoo/enterprise/pull/93902) opw-4979974 Forward-Port-Of: odoo/odoo#223448
The privacy lookup process now detects invalid email addresses before running the search. This prevents a technical crash and gives users a clearer error when contact data needs correction.
Original PR description
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address. **Steps to reproduce:** - Install CRM modules. - Create a new contact with an invalid email…
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address.
**Steps to reproduce:**
- Install CRM modules.
- Create a new contact with an invalid email address (missing @ - e.g; `demo`).
- In the contact form, click the gear icon and select "**Privacy Lookup**".
- Click on "**Lookup**" button.
**Error:**
```
UndefinedFunction
operator does not exist: character varying = boolean
LINE 55: WHERE email_normalized = false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Cause:**
Here, Execution of the query fails because `email_normalized` is set to a Boolean value, which is being computed at [1]. And method `tools.email_normalize` returns `False` for invalid email inputs - [2].
**Fix:**
This commit raises an error if the email address is invalid before executing the query.
A similar case is already handled in the mail blacklisting module. ([Ref](https://github.com/odoo/odoo/blob/c7f86c3250c59130ae0b95c6847050d3a6fc7a6d/addons/mail/models/mail_blacklist.py#L29-L31)):
[1] - https://github.com/odoo/odoo/blob/e6c0e963c5379ba7ad8da00ba4ea6c2bb259d95c/addons/privacy_lookup/wizard/privacy_lookup_wizard.py#L49
[2] - https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/odoo/tools/mail.py#L734-L735
sentry-6881416673
Forward-Port-Of: odoo/odoo#227697A regression test was added to ensure work entries can be generated when a flexible employee has overlapping absences, such as sick leave and a public holiday. This helps prevent payroll or attendance processing errors from returning in future updates.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#93902
Accounting users limited to a company branch can now access and select the appropriate accounts from the parent company when creating journal entries. This prevents blocked accounting work caused by accounts appearing unavailable for branch-only users.
Original PR description
**Steps to reproduce:** - Install accountant - Create a company branch for a company - Create a non-admin user with Accounting rights and access to the branch only - Connect with the created user - Go to "Accounting / Accounting / Journal Entries" - Create a journal entry and try to set an account on a line **Issue:** There is no account available. The accounts from the parent company should be selectable. **Cause:** The accounts are searched with a "parent_of" domain on "company_ids" field, which is a many2many field. However, as the user doesn't have access to the parent company, the parent company is excluded from the search when parsing the domain. opw-5096437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231352 Forward-Port-Of: odoo/odoo#230797
Point of Sale receipts, customer displays, and self-order payment pages now create QR codes directly in the browser instead of relying on the server. This helps stores continue printing receipts with QR codes even when the POS is offline and keeps receipt layouts consistent.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from creating new workplace entries directly from the Swiss payroll contract screen when that shortcut could cause an error. Users can still select existing workplaces, reducing interruptions during HR contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
The Shop Floor "Add Operator" action now uses the public employee list, so users without access to private employee profiles can still add operators. This prevents unnecessary access warnings and keeps manufacturing work order flows running smoothly.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702 Forward-Port-Of: odoo/enterprise#96745
When customers add more of a lunch product, Odoo now updates only the pending "To order" cart line instead of also changing already ordered lines. This prevents accidental quantity changes to confirmed lunch orders and keeps cart totals accurate.
Original PR description
**Issue**
When a user has two instances of the same product in their lunch cart, one with state "To order" and one with state "Ordered", and places a new order for that product, both the "To order" and "Ordered" records have their quantity incremented. Only the "To order" record should be updated.
**Steps to Reproduce**
- Add two lunch orders for the same product: one with state "To order" and one with state "Ordered".
- Place a new order for the same product.
- Observe that both records ("To order" and "Ordered") have their quantity incremented.
**Root Cause and Changes Made**
The _find_matching_lines method does not restrict the search to orders with state "new" ("To order"). As a result, it returns all matching records for the product, regardless of their state. When update_quantity is called, it updates the quantity for all these records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228712Odoo Studio now bases edited views on the correct main view instead of an intermediate inherited view. This prevents incorrect customizations and helps ensure Studio changes behave as expected for users.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#96636 Forward-Port-Of: odoo/enterprise#94747
This change prevents SEPA direct debit installation or updates from failing when the optional Account Payment module is not installed. It moves a shared payment method field into the core Accounting module so related payment screens can load reliably.
Original PR description
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from…
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module. I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)). Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" /> Here’s the screenshot after changing to this commit <img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" /> [OPW](https://www.odoo.com/es_ES/my/tasks/5139827) [PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477) @moduon MT-12067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231052
New timesheet entries on helpdesk tickets now appear in the expected newest-to-oldest order immediately after creation. This removes confusion for users and avoids needing to refresh the form to see the correct sorting.
Original PR description
In version saas-18.3 and later, when creating new timesheets for helpdesk tickets, they are added to the bottom of the list instead of being sorted from newest to oldest. **Steps to reproduce:** 1.…
In version saas-18.3 and later, when creating new timesheets for helpdesk tickets, they are added to the bottom of the list instead of being sorted from newest to oldest. **Steps to reproduce:** 1. Install helpdesk_sale_timesheet 2. Navigate to Helpdesk > Tickets > Timesheets 3. Create a new timesheet **Issue:** The timesheet is added to the very bottom of the list. It is not sorted from newest to oldest until the form view is refreshed. **Causes:** When helpdesk_sale_timesheet module is installed, an issue occurs. The overridden `write()` method on `helpdesk.ticket` accesses `self.timesheet_ids` too early, before the new timesheet is actually added, resulting in the new entry being appended at the end of the list. **Solution:** Avoid evaluating `self.timesheet_ids` when there is no need to process recompute_so_lines. This prevents premature evaluation and allows the ORM to attach and sort the new timesheet correctly, ensuring it appears in the expected order without requiring a form refresh. [opw-4864981](https://www.odoo.com/odoo/project.task/project.task/4864981)
Document upload request emails now greet the person being asked to upload the document, rather than the sender. Invitation and reminder emails are also sent in the recipient's language, making requests clearer and more professional for users.
Original PR description
Currently, the email template inviting a user to upload a document displays the document owner's name in the greeting instead of the requestee's. This commit updates the template to display the correct name. Steps to reproduce: 1. Log in as Mitchell Admin 2. Go in the Document app 3. Click on the New > Request 4. Enter a document name and select Joel Willis as requestee 5. Send the request by clicking on the "Request" button => The invitation email is correctly sent to Joel Willis but it says "Hello Mitchell Admin" instead of "Hello Joel Willis" Additionally, this PR ensures that the reminders and the invitation emails are sent in the requestee's language rather than the sender's. Task-5130591 Forward-Port-Of: odoo/enterprise#96941 Forward-Port-Of: odoo/enterprise#96161
Fixed an issue in the HTML editor where changing the color of selected text or content could accidentally recolor a larger parent area when an icon was nearby. This keeps formatting changes precise and prevents unintended visual changes in edited pages or emails.
Original PR description
After this [commit], we'd have an issue when we tried to change a color and there was an `fa` icon next to our selection. Instead of changing the color of only the selection it would change it for the closest element with `color`, `background-color`, or `background-image` style properties. To reproduce the bug: - Set selection on an element that has a color style property on its parent, and the parent has .fa icon but not directly on our element - Try to change its color => Color of the whole parent changes task-5107147 [commit]: https://github.com/odoo/odoo/commit/927f4b973932d14961c148e13473017651a60dc0 Forward-Port-Of: odoo/odoo#229311
Reverse charge taxes can no longer be configured as included in displayed prices, and the tax calculation engine now consistently treats them as price-excluded. This prevents incorrect tax setup and helps ensure accounting calculations follow the expected reverse charge behavior.
Original PR description
After this commit, you no longer can set a custom "price_include_override" on a tax using the UI. Even if you do, the tax engine forces such tax to be price-excluded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231384
This change removes an unreliable automated test check in Discuss calls that could fail unpredictably without reflecting a real user issue. It helps keep quality checks stable so updates can move forward with fewer false alarms.
Original PR description
Before this commit ([1]), we were testing the absence of a button for mobile, but the test can lead to undeterministic behavior as `isMobileOS` is not reactive as we do not expect a live transition of userAgent, like from desktop to mobile, so testing for this behavior is not useful. A dedicated test for call mobile was introduced in v19 ([2]) https://runbot.odoo.com/odoo/runbot.build.error/233350 [1]: https://github.com/odoo/odoo/pull/177374 [2]: https://github.com/odoo/odoo/pull/218119 Forward-Port-Of: odoo/odoo#231191
This fixes an unreliable automated test in the mail app by ensuring the message editor is ready before testing the Escape key discard action. It helps keep quality checks stable and reduces false failures in the release process.
Original PR description
Before this commit, test "discard on pressing escape" failed non-deterministically with the following error: ``` Failed to find 0 of ".o-mail-Composer" (Timeout of 3 seconds). Found 1 instead. ``` This happens at the very last step of the test: we click on composer of message to have the focus, so that we can then press ESCAPE and discard the editing of message and thus remove the composer. The issue happens because while we click on composer, we don't await the composer being logically focused, which is necessary for the good working of the ESCAPE feature to discard the message editing. This commit fixes the issue by awaiting the composer is logically focused after click on composer, so that pressing ESCAPE is properly expected to cancel the editing and thus remove the composer. Fix runbot-error-233394 Forward-Port-Of: odoo/odoo#231431
Product pages with only one image no longer show an error when shoppers click to zoom. This keeps the shopping experience smooth for products without additional media.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable zoom-on-click on product page; 2. have a product page with only a single image; 3. click on the image. Issue ----- > Odoo Client Error > Caused by: TypeError: can't access property "addEventListener", carousel is null Cause ----- Commit 83b79c198eac added event listeners to make the carousel interactive. Issue is that the carousel element doesn't exist in the DOM if there's no extra media. Solution -------- Check if the carousel element exists before adding event listeners. opw-4937009 Forward-Port-Of: odoo/odoo#230795
Odoo now stops sending attendee-specific event emails, such as badge or QR code messages, once an event is finished. This prevents outdated or unnecessary attendee communications while still allowing post-event messages intended for all event participants.
Original PR description
Forward-Port-Of: odoo/odoo#229960 Forward-Port-Of: odoo/odoo#227986
Fixed an issue where project budget totals could show the wrong color when expense budgets used positive amounts. This makes budget status indicators consistent between individual budgets, totals, and project cards, reducing confusion when reviewing project finances.
Original PR description
#### Issue: - Color for project budget and total project budgets are inconsistent #### Step to reproduce: - In Settings: - activate Project > Timesheet - activate Accounting > Budget Management - Create a project - Go to Dashboard - Add a budget of type 'Expense' - Add a line with a positive amount #### Current Behavior: - Color for the budget is correct - Color for the total budget is wrong #### Expected behavior: - Color for the budget and total budget are consistent While computing budget color, expense budget are dealt as if they were negative. Therefore having a positive amount for purchase order result in some problem on the color of the total of different budgets. This commit creates temporary variables to compute progress of the global budget. Project cards in kanban view use the `total_budget_progress` field, so it also needed to be updated the same way. opw-4812468 Forward-Port-Of: odoo/enterprise#93221
This fix prevents the POS preparation display from crashing when record dates are missing or stored in an unexpected format. It helps keep point-of-sale kitchen or preparation workflows running reliably even when some data fields are incomplete.
Original PR description
The create_date and/or write_date can be null or boolean.And if one these values is null we get this error: `TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'bool'`. Also we cannot give pass null values to max, as this will cause this error: `TypeError: '>' not supported between instances of 'NoneType' and 'int'`
This fixes an issue where adding certain localized financial report variants to Annual Statements could fail. Composite report variants are now expanded into their sections, preventing errors and ensuring the correct localized reports appear automatically.
Original PR description
The "Annual Statements" report comes with additional code at create() and write() of account.report, so that any new localized variant of the Balance Sheet, Trial Balance or Profit & Loss will automatically replace its root report in the Annual Statements report's sections. The idea behind that is to "magically" replace those generic reports by the right variant when it's created. The problem with that came when you tried adding a variant to one of those reports that was itself a composite report. In such case, you got a traceback stating a composite report's sections could not have sections themselves. We indeed only support one level of hierarchy for composite reports. We solve the issue by adding all the sections of such composite variant to the Annual Statements instead of adding the variant itself. Bug originally reported by Upgrade, here https://github.com/odoo/upgrade/pull/8571 .
Mobile users can now tap dashboard charts such as scorecards and gauges to open the related Odoo menu, matching the desktop experience. This fixes a navigation gap that previously made mobile dashboards less useful and harder to act on.
Original PR description
Current behavior before PR: - Clicking on a chart in mobile did nothing, unlike on desktop where it redirects to the linked Odoo menu. Desired behavior after PR is merged: - Clicking on a chart in mobile also redirects to the corresponding Odoo menu. - The test has been refactored to remove duplication and improve readability. Task: [4884509](https://www.odoo.com/odoo/2328/tasks/4884509) Forward-Port-Of: odoo/odoo#231469 Forward-Port-Of: odoo/odoo#225372
Corrects a bug where hierarchy-based filters on related records could miss child records that the current user cannot directly access. This helps ensure searches and business rules return consistent results when using stored parent-child structures.
Original PR description
We introduced a regression in https://github.com/odoo/odoo/pull/170009 for 'child_of'/'parent_of' operators on relational fields: With a domain leaf like `[('X2X', 'child_of', ids)]` where the X2X comodel has `_parent_store=True`, we don't take into account inaccessible children from the current user. That's incorrect, and we already fixed this behavior in ae038904face6766d93695dcaa9b07346d05282a, but the test added targeted 'res.partner' which has `_parent_store=False`.
Fix it by using a `_search()` on the sudoed comodel instead of the 'any' operator. In 19.0 we should use 'any!' operator instead.
Forward-Port-Of: odoo/odoo#231458Restaurant point-of-sale orders now keep combo meals together when staff move an item to another course. This prevents parts of the same combo from being split across courses, reducing order mistakes and improving service accuracy.
Original PR description
Steps to reproduce: ------------------------- - Install POS restaurant & create order with multiple courses - Add a combo product in one of the course - Select a combo child line and try to transfer course Issue: ------- - Only the selected child line is transferred to the new course instead of the entire combo. Cause: --------- - The system currently transfers only the selected order line without checking whether it belongs to a combo. Fix: ---- - Updated the logic to check if the selected order line is part of a combo. If so, the entire combo (parent and child lines) will now be moved to the new course together. task: 5005141 Forward-Port-Of: odoo/odoo#222423
Gift Card and E-Wallet products now appear in the Point of Sale screen even when the PoS is limited to selected product categories. This ensures staff can sell these payment products in-store without needing extra category setup.
Original PR description
Before this commit: =================== If the PoS configuration is restricted to specific categories, but the Gift Card and E-Wallet products do not have any category assigned, these products will not be visible in the PoS UI. After this commit: ==================== Gift Card and E-Wallet products are now always visible in the PoS UI, regardless of whether a PoS category is assigned or not. Purpose: ============ Gift Card and E-Wallet products should always be available for sale in the PoS. This ensures they can be sold physically from the PoS UI without requiring category assignment. Task-5103770 Forward-Port-Of: odoo/odoo#231465 Forward-Port-Of: odoo/odoo#228395