Tuesday, July 1, 2025
25 changes · saas-18.4
Resolved issues and error corrections
This fix prevents module installation from failing if the default “Hours” unit of measure was deleted earlier. The system now recreates that required unit when needed and adds protections to avoid the same problem in related planning flows.
Original PR description
Steps to reproduce: --- - Install `sale_management` module - Enable `Units of Measure & Packagings` - Delete `Hours` in Units & Packagings - Install `sale_planning` module Traceback: --- ```…
Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module
Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
<field name="name">planning.role.list.inherit.sale.planning</field>
<field name="model">planning.role</field>
<field name="inherit_id" ref="planning.planning_role_view_tree"/>
<field name="arch" type="xml">
<field name="resource_ids" position="after">
<field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{ 'default_type': 'service', 'default_planning_enabled': True, 'default_planning_role_id': id, 'default_uom_id': %(uom.product_uom_hour)d, }"/>
</field>
</field>
</record>
```
The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.
This commit resolves the issue by calling the `ensure_uom_hours` method before updating the "Hours" unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.
Also restrict deletion of uom Hour in `sale_planning`.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216715
Forward-Port-Of: odoo/odoo#213293The website builder now uses the correct internal actions for the Facebook snippet settings. This prevents an error when users add the snippet and open its configuration panel, improving reliability for website editing.
Original PR description
Problem: Dropping the Facebook snippet and interacting with its options caused a traceback due to unregistered or incorrect builder action IDs. Steps to Reproduce: 1. Drop the Facebook snippet in website builder. 2. Click on the snippet to open its configuration panel. 3. Observe the traceback due to unrecognized builder actions. Root Cause: The action IDs used in the XML template (`website.FacebookOption`) did not match the registered plugin action IDs. Fix: Updated the mismatched action IDs in the builder components: * Replaced `checkFacebookLinkAction` → `checkFacebookLink` * Replaced `dataAttributeListAction` → `dataAttributeList`
The website editor now limits header and navigation bar color choices to the intended solid and custom options, avoiding unsupported preset selections. It also lets users properly clear a customized website color so the editor no longer shows a removed color as still selected.
Original PR description
[FIX] website: restrict header navbar colorpicker to solid and custom
Since `html_builder`, the header navbar "Format" colorpicker makes it
possible to pick a preset. This should not be the case.
This commit removes the access to the "Presets" tab for that
colorpicker.
task-4367641
[FIX] website: support removing a customized website color
When `html_builder` was introduced, the `customizeWebsiteColor` action
was created to support assigning colors to specific SCSS variables.
However, it did not support the removal of a previously set color.
This commit handles the removal of such colors.
Note that it assigns no color, which still overrides the initial value.
This is the same behavior as before `html_builder`.
Steps to reproduce:
- select header
- pick a background color
- reset the background color
=> The background color remained selected.
task-4367641Website editors can now click items inside navbar dropdown menus without the menu closing unexpectedly. This makes editing navigation links, including overflow and account menus, smoother and avoids needing to reload the editor.
Original PR description
**Problem** This commit addresses two problems related to navbar dropdown menus closing on click during editing. The first problem concerns the "more" dropdown menu that appears when there are too…
**Problem** This commit addresses two problems related to navbar dropdown menus closing on click during editing. The first problem concerns the "more" dropdown menu that appears when there are too many links. The second problem concerns the dropdown containing the links "my account" and "logout". How to reproduce problem 1: 1. Start editing a page that doesn't have a "more" dropdown in its navbar 2. Click on a navbar link, then click on the "edit menu" icon 3. From the "Edit Menu", add enough menu items to make the "more" dropdown appear (adding mega menu items works too) 4. Click on the "more" button to open the dropdown 5. Click on an item of the dropdown 6. PROBLEM: the dropdown closes 7. Reload the editor, now it works properly How to reproduce problem 2: 1. Start editing a page 2. Click on the username dropdown in the navbar 3. Click on "My Account" or "Logout" 4. PROBLEM: the dropdown closes **Solution** This commit introduces an edit interaction that adds the attribute `data-bs-auto-close: outside` to dropdown elements in the editor. **Note** Some code defining the behaviour of the "more" dropdown is already present in [1] and it is still necessary for the functioning of the dropdown. The newly introduced interaction only fixes a specific case: when new elements are added to the navbar and the "more" dropdown has just been created. In this specific case, the code in [1] does not work properly because the code is executed too soon and the class `editor_enable` is still missing from the body. At the same time, when the editor is opened and the "more" button is already present on the navbar, the interaction fails to set the proper behaviour because the code in [1] replaces the dropdown menu. In this case, anyway, the code in [1] works properly and the dropdown takes the correct behaviour. Probably [1] needs a refactoring, maybe it should be written as an interaction. [1] odoo/addons/website/static/src/js/content/auto_hide_menu.js task-4367641
Payment logs now include both field names and their corresponding values for Stripe payment data, instead of listing only the field names. This improves troubleshooting and support visibility while preserving the existing handling of sensitive data.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Log Stripe payment values. Issue ----- Only the keys get logged. Cause ----- Commit 1a2573881281 fixed the logging of secret keys, but in doing so, only logs keys and no values. Solution -------- Use a dict comprehension to create a full dict to log. opw-4818301 Forward-Port-Of: odoo/odoo#216457 Forward-Port-Of: odoo/odoo#216303
The task header in shared projects now uses the available width correctly, preventing the task status from appearing out of alignment when other fields are hidden. This improves the visual consistency of task forms for portal users accessing project-related sales orders.
Original PR description
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the…
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the state misalignment ___ ### Issue: The task header section (.oe_title) was restricted by a max-width: 75% styling. When the priority field was removed, the remaining fields in the header, particularly the state field, appeared misaligned due to this layout constraint. ___ ### Root Cause: The .oe_title class imposes a max-width that limits the available horizontal space for inline fields in the header. This fixed constraint does not adapt when fields like priority are removed, resulting in layout misalignment. ___ ### Fix: To resolve this, the class mw-100 was added to the `<div class="oe_title"> `element. This overrides the default max-width behavior, allowing the container to use full width when needed. ___ ### Technical Details: This approach keeps layout logic within the view. It also preserves layout flexibility for different screen sizes and future field additions or removals. task-4813557 Forward-Port-Of: odoo/odoo#213085
This change prevents the website donation block from making duplicate background requests when more than one donation section appears on the same page. It improves reliability and avoids unnecessary server calls without changing the visitor experience.
Original PR description
The previous code had a small potential issue: if two instances of the s_donation snippets were present on a page (not sure it happens in practice), then the two interactions would be created, then…
The previous code had a small potential issue: if two instances of the s_donation snippets were present on a page (not sure it happens in practice), then the two interactions would be created, then willStarted. The first one would initiate the rpc, then the second one would do the same, since the cached value was not assigned yet, and only when the first of these 2 rpcs would resolve, then the cached value will be assigned. A possible solution would be to cache the promise instead, but we need to be careful, the waitFor operator will leave a promise pending if the interaction has been destroyed in the time it takes for it to resolve. So, putting in cache a pending forever promise can cause issues. A simple way to solve the issue is to simply remove the waitFor call in willStart, it does not do anything anyway. Another solution is to use the new cached feature from the rpc system. 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 prevents a point of sale loyalty test from running when a related payment-settlement feature is not installed. It avoids false test failures in automated validation, helping keep release checks reliable without affecting customer-facing functionality.
Original PR description
**Problem:** The test was run even when pos_settle_due was not installed, which resulted in an error during the tour, as it looked for a component that did not exist. We now skip the test if pos_settle_due is not installed. runbot-227672 Forward-Port-Of: odoo/odoo#216540
Hungarian electronic credit notes sent to NAV now show the supplier and customer bank accounts correctly instead of duplicating the customer account. This helps businesses avoid incorrect reporting details and improves confidence in Hungarian e-invoicing documents.
Original PR description
### Steps to reproduce: - Install l10n_hu_edi and switch to a Hungarian company - In the settings set the NAV mode to "demo" - Create an invoice to a Hungarian contact with an account number - Send it to NAV - Create the credit note for this invoice - Send it to NAV and download the XML in the page "NAV 3.0" - The account number in `supplierBankAccountNumber` and `customerBankAccountNumber` are the same ### Cause: The code was doing: `'supplierBankAccountNumber': format_bank_account_number(self.partner_bank_id or supplier.bank_ids[:1]),` But for credit notes `self.partner_bank_id` is the bank account of the customer not the supplier. ### Solution: Only use `supplier.bank_ids[:1]`. As the bank account were never tested in l10n_hu_edi, this commit adds it in the setup and changed the XMLs to always test it. opw-4845026 Forward-Port-Of: odoo/odoo#214714
Website visitors no longer see a confusing error caused by certain browser extensions when Odoo's push-to-talk extension is not installed. This improves the browsing experience by safely handling the missing extension case instead of showing an unnecessary traceback.
Original PR description
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefined). So when metamask (or another extension that cause window.chrome.runtime to be defined) is installed, we get an error shown because the promise rejection is not handled. Fix: handle the unhandled promise error. opw-4874027 Forward-Port-Of: odoo/odoo#216258 Forward-Port-Of: odoo/odoo#216132
This update fixes a failing web test that occurred when demo data was present. It makes the test use its own prepared record, improving reliability for development and quality checks without changing user-facing behavior.
Original PR description
Before this commit, the test TestLoadBreadcrumbs was failing with demo data. After this commit, the test uses a record created during the setUpClass, thus resolving the issue introduced in #212950 .
This fixes an issue in the email testing area where counters could be incorrect during nightly checks. The change helps keep automated quality checks reliable, reducing false failures and improving confidence in releases.
Original PR description
runbot-226551
Middle-clicking a link or action now opens it without triggering cleanup on the page the user is currently viewing. This prevents unsaved work or leave checks from being disrupted when the user is simply opening something in another tab or window.
Original PR description
Before this commit, when middle clicking the clearUncommittedChanges (and subsequently the beforeLeave) were executed on the current controller. This is an issue, as we are not leaving the current controller. Now, the clearUncommittedChanges is not called when middle clicking. Note that, this is already the behaviour if the target is "new". Forward-Port-Of: odoo/odoo#216549
Error dialogs no longer show an unrelated internal request ID in tracebacks. This prevents confusion when users or support teams investigate server action errors, making the reported context more accurate.
Original PR description
Steps: - Enable debug mode - Go to server actions - Create a server action that crashes with `Execute code` - Example -> "a" (will crash because `a` is undefined) - Traceback will contains an invalid ID `Occured on odoo180 on model ir.actions.server and id 19 on 2025-06-30 09:20:48 GMT` This was an error and this ID is not linked with the model, it is the rpc id, so it should not be on the traceback. This commit remove this id to have something like this `Occured on odoo180 on model ir.actions.server on 2025-06-30 09:20:48 GMT` opw-4816514 Forward-Port-Of: odoo/odoo#216553
Invoice forms no longer show an empty line or extra spacing beside invoice amounts when the invoice is not posted or has no outstanding debits or credits. This makes the invoice screen cleaner and avoids visual confusion for users reviewing accounting documents.
Original PR description
Repro steps: Navigate to the form view of an invoice that is either 1. not posted 2. does not have outstanding debits/credits Problem spotted: next to the invoice amounts, a weird line and margin to the right can be seen Cause: The field invoice_outstanding_credits_debits_widget of an invoice may be invisible with this condition invisible="state != 'posted' or not invoice_has_outstanding" and in that case, it's containing group would still be visible (showing the aforementioned margin). Fix: This commit fixes this issue by moving the invisible condition to the group containing the field invoice_outstanding_credits_debits_widget instead of the condition being on the field itself. task-4882509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215119
Fixed an issue where searching security groups using a forward slash could trigger an error instead of returning results. This improves reliability for administrators managing user groups in Settings.
Original PR description
Currently, an error is produced on searching in a security group with a forward slash ('/').
**Steps to reproduce:**
- Navigate to `Settings > Users & Companies > Groups`.
- Type '/' in the search bar and hit Enter.
**Error:**
`IndexError - pop from empty list`
**Cause:**
When the group name contains only slashes, splitting it by '/' at [1] results in an empty list. After computation, it attempts to pop from the empty list, resulting in an error.
[1] - https://github.com/odoo/odoo/blob/a301f8ae6aad59efd073a34c6f9ec323191d211b/odoo/addons/base/models/res_users.py#L234-L235
This commit ensures the group name is only assigned when values have content, preventing the error.
Sentry - 6685124199
Forward-Port-Of: odoo/odoo#216555
Forward-Port-Of: odoo/odoo#214557Urban Piper receipts now show the delivery identifier clearly in the receipt header. This prevents staff and customers from missing or misreading the delivery reference on printed receipts.
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88763 Forward-Port-Of: odoo/enterprise#88113
This update adds test coverage to ensure new employee records are created using the correct company setting. This helps prevent payroll-related validation issues in multi-company environments, particularly for US payroll data.
Original PR description
This commit contains the test for commit f36104c17e0ac3cde788d195aab9394a35545d43 The test is in l10n_us_hr_payroll and not in hr as we need the ssnid constraint task-4897733
This update corrects demo payroll data so Belgian employee records use a Belgium-specific time off type. It prevents access errors when opening affected employee information in the Belgian payroll accounting test environment.
Original PR description
This commit fixes an issue in the demo data. A time off allocation was done using a time off type that is not in Belgium. This caused access error when trying to access the employee. This commit fixes the issue by changing the time off type to a belgian one. task-4896664 Forward-Port-Of: odoo/enterprise#88604
Payslips now print with the correct formatting when a salary rule line is marked as a title. This improves the readability and professionalism of payroll documents shared with employees.
Original PR description
### Steps to reproduce: - Generate and print a payslip after marking a salary rule line as a title. ### Fix: - Added conditional styles and classes to fix the issue. task-4780481 Forward-Port-Of: odoo/enterprise#85607
The Indian payroll demo payslip dates were updated so they fit within the employee contract period. This prevents errors during demo data installation, making setup and evaluation smoother for users.
Original PR description
Issue: The demo payslip for employee had dates before the contract start date, leading to errors during demo data installation. Fix: Adjusted the payslip dates to be 3 months before the current date, ensuring they fall within the employee's contract period and allowing successful demo installation. Forward-Port-Of: odoo/enterprise#86794
The payroll payslip line editing wizard now includes the needed link to its parent wizard when creating new lines. This prevents an error that could interrupt payroll staff while editing payslip details.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88923 Forward-Port-Of: odoo/enterprise#88033
The Journal Report now displays the account name in the Account column, making entries easier to identify and review. This fixes a visibility issue so finance users can understand report lines without needing extra lookup steps.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276 Forward-Port-Of: odoo/enterprise#86113
The Website Help menu now shows only the helpdesk teams linked to the website a visitor is using. This prevents teams from other websites appearing in the wrong place, reducing confusion for customers and staff.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939 Forward-Port-Of: odoo/enterprise#88169
Removing a parent emission source in the ESG app no longer triggers an error. This keeps emission source records editable and helps users maintain ESG data without interruptions.
Original PR description
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new…
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new emission source with a parent emission source. - Remove the parent emission source. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=3>,).activity_flow_direct_indirect` This error occurs when the parent emission source is removed, causing the scope to become False in _compute_scope[1]. Subsequently, in _compute_activity_flow[2], none of the cases match, which results in a failure to assign the activity flow and raises an error. [1] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L75 [2] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L77-L78 This commit ensures that if the parent emission source is removed, the activity flow is properly maintained. sentry-6690968543 Forward-Port-Of: odoo/enterprise#88158