Wednesday, October 15, 2025
52 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#227697Preparation tickets in Point of Sale now handle combo products correctly when different printers are assigned to different product categories. Each printer receives the combo name plus only the relevant items for its category, reducing kitchen or service confusion.
Original PR description
Before this commit: =================== - When using separate printers for product categories, combo products were not printed correctly. - All child products of a combo were sent to every printer, regardless of their category. After this commit: ================== - Combo products are now handled properly in preparation tickets. - Each printer will print the combo product title along with only the child products that belong to its assigned category. Task: 5056115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230982 Forward-Port-Of: odoo/odoo#225658
This 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
Accounting users limited to a branch can now access the appropriate accounts from the parent company when creating journal entries. This prevents blocked or incomplete journal entry creation for branch-only accounting 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
This fixes an issue where country-specific point-of-sale fields could disappear when multiple devices were connected to the same session. Businesses using Chilean or Peruvian electronic invoicing in PoS will now keep required session information consistent across devices.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/odoo/pull/228419 opw-5073848 Forward-Port-Of: odoo/enterprise#95455
This fix ensures Spain-specific Point of Sale session information stays present when updates are synchronized between multiple devices. It prevents important localization data from being accidentally removed after real-time notifications, improving reliability for multi-device PoS setups.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/enterprise/pull/95455 opw-5073848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228419
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
AI attachment handling now better supports tabular files such as CSV and spreadsheet formats by organizing rows in a way that can be processed more reliably. This helps users add spreadsheet-like documents as AI sources and improves the quality of information retrieval from those files.
Original PR description
This PR aims to properly support and chunk tabular attachments including csv, xls, xlsx, and ods attachments. task-id-5045336
Shipping labels can now be sent to a selected printer based on the warehouse operation type instead of automatically using the first compatible printer. This helps businesses route labels to the correct location and avoid printing mistakes in multi-printer setups.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. Task: 4792491 Forward-Port-Of: odoo/enterprise#97034 Forward-Port-Of: odoo/enterprise#86818
Returning a non-rental product from a rental order now correctly reduces the delivered quantity on the sale order. This prevents inaccurate order status and invoicing information after rental-related returns.
Original PR description
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a…
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a rental order with (in that order!): - A rental product - A non-rental product - Confirm the rental order. - Open the related sale order. - Go to the delivery and validate it. - Return the delivery and validate the return. - Observe that the delivered quantity in the sale order is incorrect. **Cause**: The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return. **Solution**: Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location. opw-4894358 Forward-Port-Of: odoo/odoo#224714 Forward-Port-Of: odoo/odoo#222093
Fixes several issues in the document extraction manual correction interface, including crashes, disappearing selection boxes, and inaccurate line matching. This makes it easier and more reliable for users to correct extracted data from images and documents.
Original PR description
**[FIX] iap_extract: fix crash when clicking on another column of x2many** When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling…
**[FIX] iap_extract: fix crash when clicking on another column of x2many** When a x2many field is filled using the rectangular selection tool, a crash could occur when the component is busy filling the values for a field and the user clicks on another column. This happened because the `getNewRecordValues` function was using the current value of `this.activeBoxType` to get the value for the new record. This is incorrect as `this.activeBoxType` can change when the user clicks on another column of the x2many. --- **[FIX] iap_extract: fix line matching in manual correction component** In the logic that handles the matching of selected boxes with existing lines, it was assumed that the existing lines were sorted from top to bottom, but that wasn't guaranteed. When it's not sorted, the out-of-order existing lines couldn't be match to the selected boxes. --- **[FIX] iap_extract: fix loss of focus when clicking on image viewer** When the attachment showed by the viewer is an image and the selected field is a date, a click on the image (to start a rectangular selection or to click a box) would cause a loss of focus on the field which caused the boxes to disappear, making it unusable. This happened because the date fields are displaying a calendar popup which listens on the `pointerdown` event to hide itself when the click occurs outside of it. This causes the loss of focus of the field which hides the boxes. On top of this, we also need to prevent the propagation of the click event when it occurs on the box layers, as it also causes the loss of focus on x2many fields (there is a global click event listener that exits the edit mode when the click occurs on another element). These issues weren't noticed before as they only occur on image attachments. On PDFs, the viewer is embedded in an iframe that prevents the `pointerdown` and `click` events to be visible to the main document. --- **[FIX] iap_extract: fix rectangular selection on scrollable images** The rectangular selection needs to be adjusted when the user scrolls while selecting boxes. This was already properly handled for PDFs, but not for image attachments.
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
The website builder’s AI command now works correctly when used on product pages. This prevents a “Missing Record” error and lets users continue editing product descriptions without interruption.
Original PR description
__Current behavior before commit:__ Using `/ai` in the website builder sends the record id as a string leading to an error in the backend because `browse` expects an integer as input. __Description of the fix:__ Use `search` instead of `browse` to support id sent as string as well as to validate ACL and existence of the record. __Steps to reproduce the issue on runbot:__ 1. Go to `/shop`. 2. Click on a product. 3. Open the website builder. 4. Enter `/ai` in the description below the product title. => A "Missing Record" error appears.
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
Fixes delivered quantities when customers return non-rental items that were sold on the same order as rental products. This keeps sales orders accurate after returns, reducing billing and fulfillment confusion for rental workflows.
Original PR description
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a…
**Issue**: Returning a non-rental product in a rental order does not correctly update the delivered quantity. **Steps to reproduce**: - Enable rental transfers via Settings > Rental. - Create a rental order with (in that order!): - A rental product - A non-rental product - Confirm the rental order. - Open the related sale order. - Go to the delivery and validate it. - Return the delivery and validate the return. - Observe that the delivered quantity in the sale order is incorrect. **Cause**: The [_get_outgoing_incoming_moves](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/sale_stock/models/sale_order_line.py#L200C17-L200C85) method fails to detect incoming moves when the destination location has `usage='internal'` (as in rental flows), instead of `customer` (see [_is_outgoing()](https://github.com/odoo/odoo/blob/ea6776f095d556e3429d2b847a66f78f2e866380/addons/stock/models/stock_location.py#L464)). This causes the delivery quantity not to be decremented on return. **Solution**: Relax `_is_incoming()` logic to consider moves as incoming if they come from a rental and go to an internal location. opw-4894358 Forward-Port-Of: odoo/enterprise#93442 Forward-Port-Of: odoo/enterprise#91825
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.
This fix makes reconciliation models accessible in the invoicing app so accounting workflows no longer get blocked when those models are needed. It also cleans up awkward related views, making the invoicing experience smoother for users managing payments and reconciliation.
Original PR description
Currently flows are stuck if you don't have the models. And some views are really weird (create a reconciliation model line). 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#230775
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
This fix ensures Odoo Studio edits are based on the correct main view rather than a nearby extension view. This helps prevent customization issues and keeps Studio changes applied in the expected place.
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
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
Auto-forwarded emails with multiple recipient addresses no longer cause unrelated email addresses to be added as followers when alias local-part matching is enabled. This keeps follower lists accurate and avoids unnecessary notifications to unintended contacts.
Original PR description
Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if…
Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added. Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers. opw-4896074 Forward-Port-Of: odoo/odoo#230004 Forward-Port-Of: odoo/odoo#216737
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
This fixes a formatting issue in the HTML editor where colored or gradient text inside lists could lose its color, become invisible, or create invalid nested formatting when users changed text styles. It helps keep list formatting, checklist strikethroughs, and text entered after a list visually consistent.
Original PR description
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list…
Steps to Reproduce: - Create a list in the editor. - Apply a text color to an item. - Change the font type of the text inside the list (e.g., to H1–H6). - Apply a gradient color to text inside a list item. - Move the cursor outside the list by pressing Enter twice and start typing in the new container. Current behavior before PR: - When changing the font type (H1–H6) after applying a color, the text color turns to default color. also when applying a gradient color and then changing the font type, the text becomes transparent. - This happens because the gradient style was incorrectly applied both on the `<li>` and its child `<font>` element. As a result, Checklist items lose their line-through when checked. Also new base container outside the list ends up with a `<font>` wrapping another `<font>`. Desired behavior after PR is merged: - All child elements inside the list item inherit the color and Gradient styles are applied only to the `<font>` element. - Checklist items correctly show the line-through when checked and No invalid nested `<font class="text-gradient">` tags are created when writing outside the list after pressing Enter twice. task-5039499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231390 Forward-Port-Of: odoo/odoo#224262
Point of Sale loyalty rewards now check whether an order meets the configured earning rules before adding new points. This prevents customers from receiving points when minimum item quantities are not met and avoids incorrect negative point adjustments when claiming free products.
Original PR description
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative…
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product. > Setup of the Loyalty Program (Discount & Loyalty): Program Type : Loyalty Card Rule : minimum 5 items => 10 Loyalty Points per $ Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points Steps to reproduce: ------------------- * Open the pos Shop * Select a customer with loyalty points * Add a Simple Pen * Click on * Reward > Free Product - Loyalty Program > Observation: Customer shouldn't 'win' points here New Total is mathematically correct but not logic Why the fix: ------------ We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points. opw-4914774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231056 Forward-Port-Of: odoo/odoo#221570
Reverse charge taxes can no longer be configured as included in product prices through the interface. This prevents incorrect tax handling by ensuring these taxes are consistently treated as added separately, improving accounting accuracy and compliance.
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 fixes how Odoo decides whether expense reports can be edited, reset, or approved. It ensures those actions reflect the actual user's permissions instead of treating every check as if it had elevated access, reducing the risk of incorrect actions being available.
Original PR description
The field is_editable which used the compute method _compute_is_editable and the field can_reset which used the compute method _compute_can_reset, where called with the argument compute_sudo=True. Those 2 method then used the self.env.su which was always True. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224573
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
Live chat agents marked as busy will now still be considered available to answer chats, while agents marked away remain unavailable. This prevents customers from being routed away from active support staff who only wanted to suppress notifications or show they are busy.
Original PR description
Before this commit, when a human agent had the IM status "busy", the agent was not considered available for live chat. The "busy" feature is intended only to not receive notification and to show to others we are busy, but is not meant to disable availabily as a live chat operator. The issue happens because availability of the operator required the "online" IM status, which ignored "busy" that was added recently. Note that "away" is considered as not available for operator: the "away" IM status can be set manually by user but also can be triggered automatically when agent is away for a long time, and in these cases users already expect to not be considered as available live chat agents. This behavior is kept in this commit. opw-5150332 Forward-Port-Of: odoo/odoo#231475
QR code payments in Point of Sale now update the payment screen once the payment is completed. This prevents staff or customers from seeing an outdated QR code and avoids errors when finalizing the order.
Original PR description
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup…
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup manually and performing another action resulted in a `Finalize order` error. - This happened because the WebSocket handler flow were not updating the order state properly. After this commit: =============== - Ensure the frontend refreshes payment status directly from the server when the current order is updated. - Remove unnecessary synchronization calls to prevent stale state. - The order is now correctly marked as paid, and no finalize error occurs after closing the QR popup. Issue: =============== - The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION` was fetching the full `pos.order` unnecessarily, because the order state is already updated by another WebSocket flow. - `notify_synchronisation` in the self order flow was redundant, as updates are already handled in the `pos_self_order` module’s `pos.order` file. Task - 5107009 Forward-Port-Of: odoo/odoo#231444 Forward-Port-Of: odoo/odoo#229847
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
The website HTML editor now avoids creating invalid page structure when users change text formatting inside elements that visually behave like blocks. This helps preserve content layout correctly in browsers and reduces unexpected editing results.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block and we change its font style. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. task-5123274 Forward-Port-Of: odoo/odoo#230682 Forward-Port-Of: odoo/odoo#229043
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
Project revenue totals now continue to include prepaid service products even after those products are archived. This keeps project status and profitability reports accurate when older or discontinued products are no longer active.
Original PR description
**Steps to reproduce:** 1. Install the Sale, Project, and Timesheet modules. 2. Create a service-based product with `invoicing policy > Prepaid`, linked to `Create on Order > Project and Task`. Add a project template. 3. Create a sale order with that product. 4. Go to the created project and check the project status. **Observed behavior:** * Revenue is visible in project status while the product is active. * Once the product is archived, its revenue disappears. **Root cause:** Archived products were not considered when calculating revenue. **Solution:** Backport the fix from v18 to include archived products in revenue calculations. v18 pr : https://github.com/odoo/odoo/pull/129089 added test for product archive case. opw-5070289 Forward-Port-Of: odoo/odoo#231503 Forward-Port-Of: odoo/odoo#229485
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
Spreadsheet list side panels now handle missing or deleted fields gracefully. This prevents editing from being blocked after migrations or custom field removals, improving reliability for users managing spreadsheet-based lists.
Original PR description
If a field disappeared from a list following a migration or a deleted custom field, the list could no longer be edited in the sidepanel because we tried to access the missing field info (name & string) Task-4915281 Forward-Port-Of: odoo/enterprise#97179 Forward-Port-Of: odoo/enterprise#96158
This fix prevents access errors when branch users create Point of Sale orders for products owned by a parent company while real-time inventory valuation is enabled. It helps sales operations continue smoothly across company branches without blocking order creation.
Original PR description
Before this commit, if a product was assigned to company A and a user from one of its branches tried to create an order with real-time inventory valuation enabled, the system would raise an access error when reading the product's cost_currency_id field. opw-4969390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229825 Forward-Port-Of: odoo/odoo#223951
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
Users can now print or export their own timesheets from a single private project without hitting an access error. This removes an inconsistent reporting issue for employees who are assigned work on private projects and need to share or keep timesheet records.
Original PR description
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as…
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view. - If the selected timesheets come from only a single private project : an Access Error is raised - If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error. **Expected:** Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell. So now when printing or exporting a timesheet from a single private project, no Access Error is raised. **Steps to reproduce:** - Create 2 different projects - Create a task in each - Assign it to another user (Make sure the other user only has user access to timesheets and projects) - Set each project's visibility setting to private - Log in with the other user - Go to Timesheets --> List View Single projects: - Select one or multiple timesheet entries from one of the private projects - Select Print -> Timesheets - You should see an Access Error Multiple projects: - Select one or multiple timesheet entries from a combination of both private projects - Select Print -> Timesheets - You should not have any Errors opw-5127526 Forward-Port-Of: odoo/odoo#231188
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