Tuesday, July 15, 2025
17 changes · saas-18.2
Resolved issues and error corrections
Fixes an error that appeared when testing a live chat chatbot step that creates a lead and forwards the conversation. This helps teams validate chatbot flows reliably without encountering a crash during setup or testing.
Original PR description
When user tests the chatbot with create lead and forward step, A traceback will appear. Steps to reproduce the error: - Install ``website_crm_livechat`` module - Go to Livechat > Configuration >…
When user tests the chatbot with create lead and forward step, A traceback will appear. Steps to reproduce the error: - Install ``website_crm_livechat`` module - Go to Livechat > Configuration > Chatbots > Open Welcome Bot > Add a line > Step Type: Create Lead & Forward > Save & Close - Test > the chat will open > Click on ``I have a pricing question`` > The Bot will ask for an email > Enter a valid email > Send Traceback: ``` KeyError: im_livechat.channel() ``` When user clicks the Test button a discuss channel is created as shown in [1]. In this case, the discuss channel created for the chatbot test script does not have a ``livechat_channel_id``. https://github.com/odoo/odoo/blob/5c7a4716ef1b1c55e1ce8848c11c27c79768d1ec/addons/crm_livechat/models/chatbot_script_step.py#L109-L111 Here, ``livechat_channel_id`` will be an empty record. So, It will raise the above traceback. [1]: https://github.com/odoo/odoo/blob/5c7a4716ef1b1c55e1ce8848c11c27c79768d1ec/addons/website_livechat/controllers/chatbot.py#L52 sentry-6729421960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217902
Internal users without Accounting permissions can now add sub-contacts to customers that use Spanish FACe Center roles. This prevents unnecessary access errors and makes contact management smoother while keeping the change limited to read access for role types.
Original PR description
**Steps to reproduce:** - Install l10n_es_edi_facturae - With an admin user, create a contact - From the contact, add a "FACe Center" sub-contact with a Role - Save the contact - With a user that doesn't have any Accounting rights, try to add a sub-contact to the previously created contact **Issue:** An access error is raised because some Accounting rights are needed to access "l10n_es_edi_facturae.ac_role_type" records. **Cause:** "l10n_es_edi_facturae.ac_role_type" is only readable for "account.group_account_invoice" group and "account.group_account_readonly" group. **Solution:** There's is no point to restrict the read access to an Accounting group. The model is made readable for all internal users. opw-4788636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217370
This fixes an error that could occur when changing reordering quantities for manufactured products after a related manufacturing order was scheduled. Users can now adjust replenishment rules without the page failing, improving reliability in inventory and manufacturing planning workflows.
Original PR description
**Steps to reproduce:** - Install MRP module - Create a new product tracked by quantity and set its route to manufacture - Create a new BoM and set the Manuf. Lead Time to 2 days - Create a new…
**Steps to reproduce:**
- Install MRP module
- Create a new product tracked by quantity and set its route to manufacture
- Create a new BoM and set the Manuf. Lead Time to 2 days
- Create a new reordering rule, set the minimum quantity to 2 and click on order
- Navigate to the newly created manufacturing order and set the scheduled date to the next day
- Try increasing the minimum quantity on the reordering rule
- `KeyError` is triggered
**Issue:**
When computing `unwanted_replenish` field, the `_quantity_in_progress` function builds a dictionary (`res`) created using the IDs of current 'stock.warehouse.orderpoint' records as keys.
During `onchange()` process the keys can be set as temporary IDs (`NewID` class). But, when evaluating domains, `orderpoint.id` is returned as the real ID (`orderpoint._origin.id`), which make the index lookup fails when checking value of existing model:
```
self.id => NewId origin=6
res => {<NewId origin=6> : 0.0}
orderpoint.id => 6
res[orderpoint.id] => KeyError
```
This mismatch occurs due to the implicit conversion when using `NewId` inside domain filters with `.ids`. In which case they return the elements which matched the `_origin` id (for previous existing records). Domains will return the matching records with real IDs, but the dictionary still expects `NewId` as key.
**Fix:**
Ensure safe lookup by explicitly checking whether the dictionary has either the real ID or the `NewId` wrapper.
opw-4729116
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#209505The website editor sidebar now displays layout options correctly when translated text is longer, such as in Spanish. This prevents unwanted horizontal scrolling and makes snippet editing smoother for users working in different languages.
Original PR description
Step to reproduce: - Set the odoo backend language to spanish (tested in V16.0) - Go to edit mode - Drop "Text-Image" snippet. - Click on Image from dropped snippet. - Bug: The sidebar "Layout" menu overflows, there is a horizontal scrollbar. Issue: There was an issue with the dynamic width of the we-buttons within the button group. The text in the "Layout" options was overflowing, causing the sidebar to overflow. Solution: This commit addresses the specific issue with the layout option. Without altering any other styles and assuming this is the only case, we equally divide the available space between the buttons using the grid template. task-4378522 Forward-Port-Of: odoo/odoo#217722 Forward-Port-Of: odoo/odoo#189856
Point of Sale invoices now automatically include the related order name in the Customer Reference field. This makes invoices easier to identify and match with POS orders in the backend, reducing manual lookup work.
Original PR description
## Short functional explanation of the error When selling items in the point of sale module with an invoice, when we check said invoice in the backend, the customer reference field is empty. ##…
## Short functional explanation of the error When selling items in the point of sale module with an invoice, when we check said invoice in the backend, the customer reference field is empty. ## Reproduction Steps 1. Go to Point of sale and open a shop interface. Add a random item to the basket and select a customer. 2. Click on payment, then check Invoice, select a payment method, and Validate. 3. Click on the hamburger menu on the top right and click on Backend. 4. Hover the box of the shop you opened with your mouse. In the top right corner of the box should appear a 3-dot menu. Click on it and click on Sessions. 5. Click on the latest session ID. On the top of the page, click on the "Orders" smart button. 6. Click on the order you just finalized. On the top of the page click on the "Invoice" smart button. 7. Click on "Other info" tab. ### Expected behavior The Customer Reference field should be filled with the name of the order. ### Unexpected behavior The Customer Reference field is left empty. ## Origin of the issue When setting the values for the invoice, the field 'Ref' was absent. opw-4732492 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an employee is archived, Odoo now correctly removes their user from any approver role they held for other employees, even if they were only assigned to one approval field. This prevents outdated approver assignments from remaining after someone leaves or is deactivated.
Original PR description
Currently, a user needs to be time off, expense and timesheet approver of an employee for those links to be removed by the departure wizard. If not all the approver fields are the same user, that link will not be removed. Steps to reproduce: - Set Marc Demo as only Time Off approver on an employee. - Archive Marc Demo's employee (This does not remove time off approver from the previous employee) To rectify this issue, we correctly group the `user_domain` so that their contents are properly OR'd. Forward-Port-Of: odoo/odoo#213513
Fixed an issue in Manufacturing where printing a Bill of Materials could fail if a byproduct had a quantity of zero. The report now handles that case safely by showing zero cost instead of stopping the print process.
Original PR description
**Issue**:
Printing the BOM crashes when one of the byproduct quantity is set to 0
**Steps to reproduce**:
- Open the manufactoring app
- Go to settings and activate by-product settings
- Go to Products > Bills of Materials
- Open a BOM
- Put the quantity of one the by-product by 0
- Click on overview
- Click on the print button
**Cause**:
In the `mrp_report_bom_structure.xml` template, there is this division:
- `<td class="text-end" t-esc="byproduct['bom_cost'] / byproduct['quantity']" t-options='{"widget": "monetary", "display_currency": currency}'/>`
without checking if `byproduct['quantity']` is different than 0.
**Solution**:
Added the check on `byproduct['quantity']` in the foreach
**Additional notes**:
Since it makes no real sense to have a non-zero BoM cost associated with a byproduct whose quantity is zero, the cost is set to 0 when the quantity is 0.
opw-4853525
Forward-Port-Of: odoo/odoo#213936Fixes an issue where archiving an employee could lose departure-related information if that employee was responsible for another employee's time off. The departure wizard now keeps the correct employee selection so HR records are updated reliably during offboarding.
Original PR description
When we archive an employee that is the time off responsible of another employee, the `_clean_leave_responsible_users` method will clear our cache before we set some departure related fields. This will cause us to have to recompute the relation for `employee_ids` and the domain that ensures the suggested employees in the wizard are not already archived will prevent us from finding the employee we were archiving. To ensure these fields are written properly, we save the value of `employee_ids` before archiving the employee. opw-4729600 Forward-Port-Of: odoo/odoo#211174
A problem in the Survey app could cause translation lookup warnings when preparing answer statistics. The fix changes how translated text is retrieved so survey statistics work more reliably for multilingual users.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-135198 Forward-Port-Of: odoo/odoo#216030
Manufacturing users can now create a new workcenter directly while setting up an operation, even before selecting a Bill of Materials. This removes an unnecessary company preset that was causing an error and blocking setup work.
Original PR description
**Current behavior:** Can't create a workcenter from the operations (workorder) form view without having a BoM filled in (due to company check issue). **Expected behavior:** Can **Steps to reproduce:** Open `Manufacturing / Configuration / Operations` -> create new -> type in a new workcenter name -> hit create -> error **Cause of the issue:** in `mrp_routing_workcenter_form_view` we get some context for a `default_company_id`- it's not only unnecessary because `Mrp.Workcenter` will get a default company just fine via its its `resource.mixin` inheritance. The currently provided company comes from the BoM, thus the issue happens when the BoM has not yet been filled in on the view. **Fix:** Remove the context in the view. opw-4836904 Forward-Port-Of: odoo/odoo#217950
Access errors during Point of Sale data loading are now recorded instead of failing silently. This helps support teams identify and investigate configuration or permission issues faster, improving traceability without changing the user workflow.
Original PR description
Previously, an access error during PoS data loading would silently fail, leading to unresolved issues and poor traceability. This commit introduces logging for access errors that occur when a model's data is loaded in the PoS. This provides better insight and simplifies investigation of such issues. opw-4801774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how property fields appear when users build filters, server actions, or group list views. Separators are now hidden where they should not appear, and grouped lists no longer show confusing parent names in column labels.
Original PR description
Bug 1 ===== When inserting properties in a domain, or in the server action form view, the property separator should not be visible. Don't show separator in group by. Bug 2 ===== Name change in list view after grouping by a property 1. Add a property in the list view 2. Group by a property => The name of the parent is added in the column. Task-4896271 Forward-Port-Of: odoo/odoo#217551 Forward-Port-Of: odoo/odoo#217468
Internal users who have a passkey can now complete the portal identity check without being sent into an unsupported verification flow. This prevents a rare but disruptive access issue while keeping the portal on its current password-based check until passkey support is added later.
Original PR description
When an internal user has a passkey and attempts to pass the portal identitycheck, then the identitycheck's auth_method is set to webauthn which breaks the flow since portal's identitycheck only supports passwords. This scenario is unlikely to occur but it does break the internal users' portal. This is a temporary solution because once I implement passkeys for portal users, I will allow portal users to use webauthn to verify their identity. Forward-Port-Of: odoo/odoo#218427
This fixes an automated test for the Discuss public channel so it selects the intended message when editing or reacting. The change reduces random test failures and helps keep release validation more stable without affecting end users.
Original PR description
Before this commit, "test_discuss_channel_public_page_as_internal" tour would fail non-deterministically at following step: ``` FAILED: [21/33] Tour discuss_channel_public_tour.js → Step Click on edit (trigger: .o-mail-Message-moreMenu [title='Edit'], .o-mail-Message [title='Edit']). ``` This happens because this tour is run twice, and in the 2nd run the selector to hover and click on 'Expand' is just targeting the 1st message. This works fine in the 1st run, but in the 2nd run this picks the message of previous test instead of the 2nd one. A full run of tour posts a message "cheese" and edits its content to "vegetales", so targeting the message with content "cheese" ensures the right message is picked, which is what this commit does to fix the issue. This commit also properly targets the right message for message reaction. Fixes runbot-error-227756 Forward-Port-Of: odoo/odoo#219009
This fix makes an automated mail test wait until sending is actually available before pressing Enter. It reduces random test failures and helps keep release validation for public mail group pages stable.
Original PR description
Before this commit, tour "test_mail_group_public_page_as_portal" failed non-deterministically at the following step: ``` FAILED: [14/37] Tour discuss_channel_public_tour.js → Step Check message is…
Before this commit, tour "test_mail_group_public_page_as_portal" failed non-deterministically at the following step:
```
FAILED: [14/37] Tour discuss_channel_public_tour.js → Step Check message is shown (trigger: .o-mail-Message-body:contains("cheese")).
```
When looking at screenshot from runbot, it shows that the message is indeed not on UI, but the composer still contains "cheese" in input, which means the message hasn't been effectively posted.
This can happen when the press Enter is made before the composer is not in a state to send the message. In practice the conditions should be met: have some text in composer and some attachments have been attached and fully uploaded. However test it running steps fast and it can trigger the "press Enter" sooner than it's actually made available.
This commit fixes the issue by pressing Enter when the "send" button is enabled, which is the right time when press Enter is also available to use.
Fixes runbot-error-229828
Forward-Port-Of: odoo/odoo#218999This fix ensures Hong Kong payroll autopay files use the same rounded amounts shown on payslips. It prevents rare payment mismatches caused by HSBC file formatting removing decimal places, reducing payroll reconciliation issues.
Original PR description
Explanation: In some rare cases, the autopay amount in payslip and the amount in hsbc autopay file doesn't match. This is due to hsbc autopay files are trimming all the decimal places, and the amount in payslip are rounded. Forward-Port-Of: odoo/enterprise#89118
Miscellaneous changes
Currently when /iot/setup method is called if the iot box record exists we always update the record with the received data, even if the data is the same as the record's data. This PR only updates it if the data changes Forward-Port-Of: odoo/enterprise#88043
Original PR description
Currently when /iot/setup method is called if the iot box record exists we always update the record with the received data, even if the data is the same as the record's data. This PR only updates it if the data changes Forward-Port-Of: odoo/enterprise#88043