Thursday, June 4, 2026
14 changes · 19.0
Resolved issues and error corrections
Live Chat users could run into an error when filtering sessions by chatbot messages, because that filter exposed information reserved for administrators. The update limits that filter field to administrators, preventing the error and keeping session searches usable for regular Live Chat users.
Original PR description
**Steps to Reproduce** 1. Install the **Live Chat** module in version 18.4 or above. 2. Go to: **Settings → Users** * Open your user and change the access rights from **Live Chat / Administrator** to…
**Steps to Reproduce**
1. Install the **Live Chat** module in version 18.4 or above.
2. Go to: **Settings → Users**
* Open your user and change the access rights from **Live Chat / Administrator** to **Live Chat / User**.
* Alternatively, create a new user giving him rights of the **Live Chat / User** group.
3. Login using the Live Chat user.
4. Open the **Live Chat** application and navigate to: **Live Chat → Sessions**
5. Open any existing session. The session and its messages are accessible without any issue.
6. In the search bar, click: **Filters → Custom Filter**
7. Select the field `Chatbot Messages (chatbot_message_ids)`. You will face the below traceback.
**Issue Description:**
The issue happens because `discuss.channel` records are accessible to users having the `im_livechat_group_user` group through the Sessions menu: https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/views/im_livechat_channel_views.xml#L310-L315
The field `chatbot_message_ids` is defined as:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/models/discuss_channel.py#L165
This field points to the `chatbot.message` model, but access to that model is restricted to `im_livechat_group_manager` only:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/security/ir.model.access.csv#L15
As a result, when a Live Chat user tries to use `chatbot_message_ids` in a custom filter, Odoo attempts to read `chatbot.message` records and raises an `AccessError`.
This issue started happening after the access rights changes introduced in pr : https://github.com/odoo/odoo/pull/201880
Specifically, the following ACL changes:
https://github.com/odoo/odoo/pull/201880/changes#diff-c1592d633a34db44a7cc2a527482cecc56127cbba72649e7318dcf63ccf477afR19-R20
**Solution:**
To fix this issue, added the group `im_livechat_group_manager` on the field `chatbot_message_ids` so only those user can access the field who belong to the group.
**Traceback:**
```.py
odoo.exceptions.AccessError: You are not allowed to access
'Chatbot Message' (chatbot.message) records.
This operation is allowed for the following groups:
- Live Chat/Administrator
Contact your administrator to request access if necessary.
```
opw - [6169395]
upg - [4274573]
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#264682This update corrects how Odoo calculates the available gaps within a defined range when some intervals fall partly or fully outside that range. It helps prevent incorrect scheduling or availability results in features that depend on these interval calculations, and adds tests to cover the affected edge cases.
Original PR description
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. [commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c Forward-Port-Of: odoo/odoo#267917
Portal users viewing shared projects will now see checklist items in task descriptions as checkboxes instead of bullet points. This keeps shared task details accurate and easier to follow for external collaborators.
Original PR description
**Steps to reproduce:**
- Create a project
- Create a task and add a checkbox in the task description
- Share the project with a portal user
- Login as the portal user and open the task description
**Issue:**
In project sharing, checkboxes in the task description are displayed as bullet points.
**Cause:**
The required styles from `html_editor` were not loaded in the project sharing assets, so the related SCSS was not applied.
**Fix:**
Load the following missing SCSS files in the project sharing assets:
- html_editor/static/src/scss/html_editor.common.scss
- html_editor/static/src/scss/base_style.scssThis fix updates the HTML editor so the remove-formatting button tooltip displays its keyboard shortcut consistently. It helps users discover a faster way to clean up text formatting and includes test updates to prevent regressions.
Original PR description
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 update corrects how the French PDP verification display status handles company-specific context. It helps prevent errors in the partner merge wizard, improving reliability for businesses using French e-invoicing features.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
Authorize.net payments no longer fail when customers enter address details that exceed the provider's length limits. The system shortens overly long fields before sending them, helping more card payments complete successfully.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
Users can now save journal settings when the next check number includes letters or other non-numeric characters. This prevents an unexpected error in check printing configuration and keeps payment setup workflows from being interrupted.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
The Google address autocomplete field now correctly becomes non-editable when a form or field is marked read-only. This prevents users from accidentally changing protected address information and keeps the interface consistent with access rules.
Original PR description
**Issue:** The `google_address_autocomplete` widget remained editable even when the view or field was set to `readonly`. **Solution:** Modified the `AddressAutoCompleteTemplate` to conditionally render the component. If `props.readonly` is true, the template now renders a `<span>` with the field value. Task~5182770 Forward-Port-Of: odoo/odoo#265242 Forward-Port-Of: odoo/odoo#260952
This update fixes a bug that prevented quality checks on manufacturing MOs when an invalid measure was entered. The change reflects a recent update to the system's MO structure, ensuring stability and proper functionality for quality control processes. It utilizes the first lot/serial from the MO when available.
Original PR description
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and confirm MO for the product. - Update the Quality Point: Remove the 'manufacturing' operation type and add 'receipts' type. Change Control per to 'Quantity'. - Open the MO and start a quality check. - Enter an invalid measure and try to validate it. ## Error: `AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'` ## Cause: Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error. ## Fix: This commit uses the first lot/serial from the MO. Note: Multiple produced lots are only possible for serial-tracked products. sentry-7511513479
This update fixes an issue where negative line items in the MX CFDI tax reporting were incorrectly distributed. The change addresses a conflict introduced by new features like discounts and down payments, which made the previous method of checking line types obsolete. This ensures accurate tax reporting for Mexican businesses using the CFDI format.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119254
This update fixes an error in the executive summary report that was incorrectly calculating the period length. Previously, it was measuring the gap between dates instead of the number of days, leading to inaccurate metrics like Average Debtor Days. This change ensures the report accurately reflects the period's length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
A recent test failure in the website rental product functionality was caused by inconsistent timezone settings. This update has standardized all timezone data to UTC within the test environment, resolving the issue and ensuring reliable test results. This ensures accurate product display and functionality for rental products.
Original PR description
The test_add_accessory_rental_product test failed on the runbot due to a timezone ambiguity where two of them were used. I changed the website timezone to UTC in the test data definition to uniform them. Runbot error: 233282
This update corrects a display problem on the POS Kanban view for businesses not using the 'blackbox' configuration. The update now correctly retrieves session information from the POS session model, ensuring accurate version badges and session details are shown. This improves the user experience and data accuracy for standard POS setups.
Original PR description
- Hide the FDM version badge on the POS kanban view for non blackbox config - Read `bookingPeriodId` and `bookingDate` from the frontend `pos.session` model instead of the computed `current_session_id` backend field on `pos.config`.
This update fixes an issue where the tag container overlapped with the header in the sign module due to longer translated strings. The changes automatically adjust the container's position and reduce its height to ensure a clean layout across different languages and content lengths. This improves the user experience and visual consistency.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />