Wednesday, October 15, 2025
28 changes · 19.0
Resolved issues and error corrections
This fix corrects a table name error that caused the database neutralization process to fail when the Australian HR Payroll API module was installed. It helps ensure test or copied databases can be safely neutralized without interruption.
Original PR description
****Behavior:**** When calling neutralize, an error occurs. The table name in the SQL file was wrong. **Steps to reproduce:** - Create a new DB and install this application (odoo-bin -d TESTDB --addons-path=odoo/addons,enterprise -i l10n_au_hr_payroll_api --stop-after-init) - Run Neutralize (odoo-bin neutralize -d TESTDB --addons-path=odoo/addons,enterprise) - You should see the error opw-5142610
Privacy Lookup now checks whether a contact's email address is valid before running the search. This prevents an unexpected error and gives users a clearer issue to correct when a contact has an invalid email address.
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 update removes an unstable automated test assertion in Discuss that could incorrectly fail depending on how mobile detection behaved during testing. It improves test reliability without changing the product experience for users.
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
Spreadsheet pivot tables now reload when a user's locale changes, such as when the first day of the week differs by region. This prevents day-of-week grouped data from showing incorrect values after changing locale settings.
Original PR description
Chaning the locale can change the first day of the week. But the normalization of the server value depends on this `locale.weekStart`, se we need to reload the pivot when the locale changes, otherwise we might display wrong values for a "day_of_week" grouping. Task: [5149508](https://www.odoo.com/web#id=5149508&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#231337 Forward-Port-Of: odoo/odoo#230949
This fix ensures Point of Sale test setup includes required country information for companies. It prevents automated test failures in environments with country-dependent localizations, helping keep releases and validation runs stable.
Original PR description
Before this commit, some tests would fail when localizations requiring a country were installed, because the created company did not have a country set. runbot-233158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230114
This fixes a display issue on the online shop page where choosing the card layout caused product cards to resize unevenly. Restoring the missing layout setting keeps product listings visually consistent for shoppers and website editors.
Original PR description
**Issue:** The issue occurs when selecting the card layout on the website shop page — the height of all cards changes. In version 18.4, it worked as expected, but in version 19.0, one class "h-100"…
**Issue:** The issue occurs when selecting the card layout on the website shop page — the height of all cards changes. In version 18.4, it worked as expected, but in version 19.0, one class "h-100" was missing, which caused the issue. **Solution:** I have added the class "h-100" again to fix the problem. **Steps to Reproduce:** Create a demo database. Install the website_sale module. Go to the Shop page and click Edit. Select the Card Layout option. The issue can also be reproduced on the runbot. **Before Fix:** <img width="1151" height="811" alt="Before" src="https://github.com/user-attachments/assets/0e20dfb6-0ae7-4372-ac6a-c960b77700eb" /> **After Fix** <img width="1176" height="649" alt="After_fix" src="https://github.com/user-attachments/assets/e5209bb0-ded8-40e9-ac16-21e5514a72b2" /> [OPW:5150748](https://www.odoo.com/odoo/project/70/tasks/5150748?debug=1) 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
This fix ensures the blog editor correctly recognizes bold text inside quoted sections. It prevents users from losing bold formatting or being unable to reapply it when editing blog posts, making content editing more reliable.
Original PR description
Problem: The bold check inside a blockquote in Website Blog is incorrect. Cause: `isBold` checks if the node’s computed font weight is higher than `500` or if the `closestBlock` has a different weight than the node. However, this is wrong when an ancestor (that is not a block) has a different font weight — that ancestor should also be considered in the check. Solution: Instead of comparing with the `closestBlock`, find the closest ancestor that has a different computed font weight and use it for the bold check. Steps to reproduce: 1. Go to a blog post. 2. Select text inside a blockquote that is already bold. 3. Click the bold button → bold is removed. 4. Click the bold button again → text is not bold (incorrect). task-2906482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The call menu now shows the “is talking” outline in the correct color when dark theme is enabled. This makes active speaker indicators easier to recognize and keeps the call experience visually consistent across the interface.
Original PR description
Before this commit, call menu "is talking" outline color had the wrong color in dark theme. This happens because it uses the color of white theme, which is a light green that works in white theme but in dark theme this is using a darker green color. To make this dark green color, call UI elements override the color. The call menu UI was not overriding the color in dark theme, even though it had code to deal with it. This commit fixes the issue by adding the override of "is talking" color in call menu in dark theme, to have intended color like other call UI elements with "is talking". Before <img width="958" height="381" alt="Screenshot 2025-10-15 at 12 34 51" src="https://github.com/user-attachments/assets/c8cd7a18-fff0-49e4-a26a-9b191b364111" /> After <img width="958" height="422" alt="Screenshot 2025-10-15 at 12 33 41" src="https://github.com/user-attachments/assets/d8d6d635-4d0c-40c0-b343-71ca0fd75eb2" />
This fixes how Odoo Studio identifies the original view structure when simplifying customized views. It helps prevent incorrect view normalization in cases where inherited views also act as main views, improving reliability for Studio customizations.
Original PR description
Since commit 52f27c457e50a61c3b11c59e3fdd5ddd383f1317, the normalize function applies on `self` (ir.ui.view) and can take a string representing the arch to normalize. The normalization then occurs on the combination of the two, outputing a simplified version of the arch passed as a string in arguments. The base arch (`combined_arch`) is retrieved from self. Before this commit, this was done by controlling on self.inherit_id, which did not cover all bases to retrieve the main view's combined arch without the studio inheritance. After this commit, this is done by controlling on self.mode, because an inherited view can also be a root view. opw-5154217
This updates a mail module test so it handles different valid outcomes when encrypted PDF support is available in the environment. It helps keep automated checks reliable without changing how business users work with attachments.
Original PR description
The `test_first_page_access_of_mail_attachment_pdf` test is failing on `runbot`.
**Error:**
```
FAIL: TestDiscussAttachmentController.test_first_page_access_of_mail_attachment_pdf Traceback (most recent call last):
File '/data/build/odoo/addons/mail/tests/discuss/test_discuss_attachment_controller.py', line 82, in test_first_page_access_of_mail_attachment_pdf
self.assertEqual(response.status_code, 415)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 200 != 415
```
**Root cause:**
The test expects a `415 status code` when accessing the first page of `encrypted`
PDFs. When `PyPDF2` and `PyCryptodome` are installed, the response
returns `200`, causing the `assertion` to `fail`.
**Fix:**
Update the test to accept both `415` and `200` as valid status codes.
This commit fixes test failures caused by https://github.com/odoo/odoo/pull/230713
runbot-233411The accounting report dashboard is corrected so it remains available only to accounting users. This helps keep finance-related reporting aligned with the intended access rules and avoids exposing it in the wrong area.
Original PR description
Forward-Port-Of: odoo/enterprise#96731
This change restores the standard way the Payroll Employees menu opens now that recent platform updates handle the navigation correctly. It avoids an unnecessary full page reload, so users should reach the Employees screen more quickly and smoothly.
Original PR description
This reverts commit bbb22f4835197419be538a7e2a82c1743fac3fa3. The fixes in the commit reverted is no longer needed thanks to the recent changes by the framework to better manage the routing in backend. Moreover, the fixes made by calling a client action to change the url will trigger a hard reload and so the employees action will take more time than before since all OWL components have to be mounted instead of just mounting to needed owl components to load the Employees action.
The Shop Floor “Add Operator” option now uses the public employee list, so users can add operators without needing access to private employee profiles. This prevents unnecessary access warnings and keeps manufacturing work order workflows moving 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
The Time Off Overview no longer shows an access error when users without Employee app access use the My Department filter. This keeps managers and employees able to view relevant department time off information without needing extra permissions.
Original PR description
Before this commit, the filter `My Department` filter displayed in the `Overview` of Time off app returns an Access Error when the current user has no access to employee app. This commit adds a related field to do the compute and search on that field in sudo to know if the employees in the Overview are part of the department of the current user. Steps to reproduce the issue: ============================ 1. Install Time off app with demo data 2. Log in as Marc Demo 3. Go to Time Off app > Overview 4. Enable `My Department` filter Expected Behavior: ----------------- The gantt view of Time Off Overview should be loaded without any errors. Current Behavior: ---------------- An Access Error is occurred because the user has not accessed to `hr.version` model. runbot-error-233311 Forward-Port-Of: odoo/odoo#231383
Fixed a display issue where dropdown menus could appear misaligned or leave unwanted space after their content changed. This improves the consistency and usability of selection menus and tooltips in the web interface.
Original PR description
This commit fixes the position of the SelectMenu, that was not aligned properly when the content of the menu is larger than the toggler width before applying any maxWidth. Because the 'fit' variant sets the same width to the popper by default, and the code was applying this width after the computation of the position of the popper, the menu was displaced. Now, the width is applied before positioning the menu, which then computes accordingly. A test has been added as well. task-4674144 Forward-Port-Of: odoo/odoo#230983 Forward-Port-Of: odoo/odoo#224568
Document upload invitation and reminder emails now address the person being asked to provide the document, rather than the sender. These emails are also sent in the requestee's language, improving clarity for recipients.
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
This fixes an installation and update issue for SEPA Direct Debit when the optional payment module is not installed. The payment method information is now available from the core accounting module, so affected accounting workflows 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
The call participant volume control now only appears when the user is actively in the call. This avoids confusing controls being shown to people who are viewing a call but cannot use participant audio settings.
Original PR description
Before this PR, the volume slider for call participants was visible even when the user was not part of the call. This PR fixes the behavior by ensuring the volume slider is only available when the user is in the call. task-[5092826](https://www.odoo.com/odoo/project/1519/tasks/5092826) Forward-Port-Of: odoo/odoo#231235 Forward-Port-Of: odoo/odoo#227803
This fix makes an automated Mail app test wait until the message editor is fully ready before simulating the Escape key. It reduces random test failures in the development pipeline, helping keep releases stable without changing user-facing behavior.
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 update ensures attachment fields in Indian localization reports can be accessed correctly when needed. It prevents users from running into missing or blocked attachment results in relevant reporting workflows.
Original PR description
Follow-up of fd4fcb1bd87, we should set `bypass_search_access` on `ir.attachment` many2many fields.
Fixes an error that could appear when shoppers clicked to zoom a product image on pages with only one image. This improves the shopping experience by ensuring the image viewer opens without crashing in that scenario.
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
IoT users and administrators can now open IoT pages even when they do not have Point of Sale access. POS-specific options are only shown or used for people with the right POS permissions, preventing unnecessary access errors.
Original PR description
Before this commit, if an IoT user/admin attempted to access any IoT view while `pos_iot` was installed, they would get a permission error if they were not also a POS user. After this commit, we check if the user is in a POS group before showing any POS related fields. We also check the group when autoconfiguring a new IoT box with a POS, this feature will simply be skipped if the user cannot access POS. Forward-Port-Of: odoo/enterprise#97133
The Maltese localization now maps fiscal positions to the correct sales or purchase taxes with matching tax rates. This prevents incorrect tax handling for EU and non-EU partners when using a Maltese company.
Original PR description
### Steps to reproduce: - Install "l10n_mt" and switch to a Maltese company - Check the fiscal position "EU Partner", it maps Sales taxes to Purchase ones - "Partner outside the EU" maps Purchase taxes to Sales ones ### Solution: Fix the CSV. We map the taxes respecting Sales/Purchase and with the same percentage. opw-5065298 Forward-Port-Of: odoo/odoo#230638 Forward-Port-Of: odoo/odoo#227423
Fixes an issue where document icons on website pages could disappear when editing a translated version of the page. This keeps uploaded document visuals clear and consistent for visitors across languages.
Original PR description
This commit permits to keep document icon visible during the translation of a website page. Steps to reproduce the issue: - Have a website in English (main) and French - Edit the website in the main lang (English) - Drop Image text block - Change the image to a document - Save - Edit the translation in French => The document logo becomes invisible. This commit fixes this issue. task-3626918 Forward-Port-Of: odoo/odoo#165109
This update corrects access settings for Swiss payroll employee information so payroll users have the right permissions. It helps HR officers access employee records as expected and prevents related automated workflow failures.
Original PR description
Some fields on the version were still with the hr_user group where they should be payroll_user. This was causing some tour to fail when an HR officer tries to access an employee. Build error: https://runbot.odoo.com/odoo/runbot.build.error/233204 Forward-Port-Of: odoo/enterprise#97096
New timesheet entries on helpdesk tickets now appear immediately in the expected newest-first order. This removes the need for users to refresh the form to see the correct list order, improving day-to-day ticket and time tracking accuracy.
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) Forward-Port-Of: odoo/enterprise#94369
This change removes a non-essential test check that could fail unpredictably when product loading conditions changed. It helps keep point of sale loyalty testing stable without changing customer-facing behavior.
Original PR description
Before this commit, some tests could fail randomly if a new product was included in the list of limited loading products. The part of the test that checked whether the product was not loaded was not essential, so it has been removed to prevent unnecessary failures. opw-5109838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228364
Project dashboards now show consistent color indicators for individual budgets and total project budgets. This prevents misleading budget status colors when expense budgets use positive amounts, helping users read project budget health more accurately.
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 -…
#### 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#97211 Forward-Port-Of: odoo/enterprise#93221