Wednesday, October 15, 2025
19 changes · saas-18.2
Enhancements to existing features
A new automated test checks a specific India tax setup where two included taxes share the same configuration and should produce equal amounts. This helps reduce the risk of future tax calculation regressions without changing day-to-day user workflows.
Original PR description
Added a missing test case in India tax computation, where both taxes have the same configuration as below: - amount: same for both taxes - price_include: True - include_base_amount: True - is_base_affected: False In this case, both tax amounts should be equal. This commit ensures that scenario is properly covered in the test suite. Forward-Port-Of: odoo/odoo#231364
The salary configurator sidebar now has clearer spacing between field labels and tooltip icons. This small visual improvement makes the interface easier to read and more polished for users configuring salary details.
Original PR description
In the salary configurator sidebar some fields have a tooltip to explain how the value is calculated, the icon for that tooltip had no margin between itself and the label. This commit adds a margin between them to make it more visually pleasing. Task ID: 5138530 Forward-Port-Of: odoo/enterprise#96483
Resolved issues and error corrections
This change moves a payment method field into the core accounting module so SEPA direct debit can install or update reliably even when the separate payments module is not installed. It prevents setup failures and keeps accounting-related payment workflows available in the expected module configuration.
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
The privacy lookup flow now checks for invalid email addresses before running the search. This prevents an unexpected error and gives users a clearer outcome when contact data contains a malformed email.
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#227697This fixes lunch cart behavior so adding more of a product only increases the pending “To order” line, not lines that have already been ordered. It prevents completed lunch orders from being changed accidentally and keeps cart quantities 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#228712This fixes an issue where changing text color in the HTML editor could accidentally recolor a larger parent section when an icon was nearby. Users can now apply color changes more precisely to their selected content, preserving the surrounding layout and styling.
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
Restaurant POS now keeps combo meals together when staff move an item to another course. This prevents incomplete combo transfers and helps orders stay accurate during table service.
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
This change removes an unreliable automated test check related to mobile call controls in Discuss. It helps reduce false test failures in the development pipeline without changing the user experience.
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
Fixes an editor issue where typing next to a link created within formatted text could lose the intended formatting. This helps users maintain consistent document and website content styling when adding or editing links.
Original PR description
Problem: If we add a link on a slice of formatted text we end up being able to type unformatted content at the link edges. Cause: After https://github.com/odoo/odoo/commit/3bcbd6f34facb9c88290dbd6496cc5103665a0a2 the `span` can be split and `feff`s are placed around the link, precisely between the link and the `span`. This allows writing unformatted content at the caret when placed between them. Solution: Ensure that the link is created inside the `span`. Also prevent the formatting applied by `.btn` when the link is inside a `span`. Steps to reproduce: 1. Add "abc". 2. Format all the text: set font size 48 (or whatever). 3. Select "b". 4. Create a link on "b" only. 5. Put caret before "a". 6. Press Arrow left. 7. Type any character. → The character is not formatted as the link content. task-5092298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228353
This fixes an unstable automated test for the Mail app by ensuring the message editor is fully ready before simulating the Escape key. It helps keep quality checks reliable 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
This fix prevents an error when shoppers click to zoom a product image on pages that only have one image. It keeps the product page working smoothly and avoids a disruptive client-side crash during browsing.
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
This fix adds the missing sample records needed for an automated website blog check. It helps ensure the blog tag/date behavior can be tested reliably even in setups that do not include demo data.
Original PR description
With PR [1], the blog_tags_with_date tour was introduced, but the required demo data were missing, causing the tour to fail when executed in an environment without demo data. This commit adds the necessary demo records to ensure the tour runs successfully even when no demo data are present. [1]: https://github.com/odoo/odoo/pull/225845 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#231202 Forward-Port-Of: odoo/odoo#230753
This fix prevents the web editor from subscribing users to document update channels when they do not have the required access rights. It avoids repeated reconnect attempts and excessive log messages, improving stability without changing normal user workflows.
Original PR description
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img…
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" /> Each reconnect attempt causes a log entry: ``` 2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Marc Demo (id=6) doesn't have 'write' access to: - Lead/Opportunity, Modern Open Space (crm.lead: 25) Blame the following rules: - Personal Leads If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. ``` Current behavior before PR: Reconnect loop. Desired behavior after PR is merged: Do not add channels without sufficient rights. Related to: https://www.odoo.com/de_DE/my/tasks/5026412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223890
Bounce emails for journal aliases now use the company linked to the email alias instead of always showing the main company. This prevents customers or vendors from receiving failed-email notices with the wrong company name or email address in multi-company setups.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231436
This update makes a small test-related styling value explicit so automated checks produce the same result across environments. It helps prevent avoidable build failures without changing the user experience.
Original PR description
Problem: Runbot build fails due to different resulting `border-color` values. Cause: The default `border-color` can change depending on the environment, leading to non-deterministic behavior. Solution: Specify the `border-color` explicitly to ensure consistent results. runbot-233297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231003
A regression test was added to ensure payroll work entries continue to be generated correctly when a fully flexible employee has overlapping absences, such as sick leave and a public holiday. This helps prevent a previous error from returning and improves reliability for attendance-based payroll processing.
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
This update prevents users from creating a new workplace directly from the contract workplace field when that shortcut could trigger an error. Users can still select existing workplaces, reducing interruptions when managing Swiss payroll contracts.
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 instead of private employee profiles. This prevents access warnings for users who are not allowed to view private employee data, making operator selection work smoothly while respecting privacy rules.
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
Project budget totals now use the same color logic as individual budgets, including expense budgets entered as positive amounts. This makes dashboard and project card budget indicators easier to trust and prevents misleading status colors.
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