Monday, February 24, 2025
22 changes · 18.0
Resolved issues and error corrections
A notice was added for combo products on the website when prices are configured to include VAT. This helps shoppers understand that taxes may not be shown on combo product prices upfront, but they will still be calculated correctly during checkout.
Original PR description
**Issue:** When the website is configured to display prices VAT included, combo products incorrectly show their prices VAT excluded. **Steps to Reproduce:** - in website setting check tax included of `Display Product Prices` - Sales > Products > Products - Create a new product of type "Combo" and set a price - click on go to website The price displayed on the website is VAT excluded, even though VAT inclusion is configured. To address this issue, a disclaimer has been added to inform users that while taxes are not displayed for combo products, they will be properly calculated during checkout. opw-4454112
This fixes a crash in the HTML editor that could happen when attempting to delete embedded component data that was not actually present. The editor now safely ignores this no-op situation, improving stability for users editing embedded content.
Original PR description
Issue: Deleting a non-existing property in the embeddedState of an EmbeddedComponent would produce a traceback. Expected: If no embeddedState snapshot was done (previousEmbeddedState is null), it means that no effective change was performed, and in that case `changeState` should return early to prevent the traceback. task-4600079
This fixes how tax subtotals are calculated on accounting documents. Subtotals now build from the untaxed amount plus earlier taxes, making displayed totals more consistent and easier to understand.
Original PR description
The first subtotal is always the untaxed amount of the document. All following subtotals are just the previous one plus the previous taxes. So the subtotal no longer depend of the taxes under it. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes intermittent failures in the two-factor authentication test flow. The change helps keep automated checks stable so releases are less likely to be delayed by false errors.
Original PR description
Following https://github.com/odoo/odoo/pull/196980 There is still a few non-deterministic errors in auth_totp modules We will assume that the issue cause is the same thus solving them in the same way. Note: None of them were able to be reproduced more easily by toggling the browser CPU rb-135125,135120,135113
The sample payload shown for webhook server actions has been corrected to match the actual data sent when the action runs. This helps users configure and test webhook integrations with more accurate example information.
Original PR description
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PayPal payments no longer fail when started by guests or PoS sessions that use the public user. The payment request now avoids sending missing customer email data and uses the company country code when needed, preventing malformed PayPal payloads.
Original PR description
When making a payment from the PoS, the user would always be the Public User. This would cause the payload sent to paypal to be incorrect and the payment to fail. This happens because we are trying…
When making a payment from the PoS, the user would always be the Public User. This would cause the payload sent to paypal to be incorrect and the payment to fail. This happens because we are trying to make a payment without any user, so this can be reproduced in other workflows. Like making a donation Steps to reproduce: ------------------- * Setup paypal payment provider * Create a PoS payment method with the paypal provider * Create a PoS order and pay with the paypal payment method > Observation: You get an error saying that something is malformed Alternative steps to reproduce: -------------------------------- * Make sure you are not connected on Odoo * Go to the `donation/pay` url * Fill out the form and make the payment via paypal > Observation: You get an error saying that something is malformed Why the fix: ------------ When using the public user, we cannot provide an email address or a country code. To fix this we make sure to not send the email address at all when there is none available. And we send the country code of the company instead of none. opw-4446219
Point of Sale product searches now find items when staff enter only part of an internal reference, rather than requiring the full exact code. This makes checkout product lookup faster and reduces missed search results when users know only part of a reference.
Original PR description
Currently searching with the reference requires to enter the full reference to find the product Steps to reproduce: ------------------- * Modify the Acoustic bloc screen product with an internal reference as TEST_01 * Open pos session * Search TEST > Observation: The Acoustic bloc screen is not in the result Why the fix: ------------ We don't require the `default_code` to be an exactMatch anymore, we make it an inclusion matching. opw-4587548
This fixes an intermittent issue where guest users could sometimes see a blank or missing Discuss conversation if the page loaded slowly. The change makes the public Discuss page wait and update correctly, improving reliability for users accessing shared conversations.
Original PR description
Before this PR, the `discuss_channel_as_guest_tour` would sometimes fail. Discuss is displayed once the thread is restored. However, one patch removes the `useState` from the store of the component, which leads to the `hasRestoredThread` flag not being observed. If `restoreDiscussThread` is too slow to execute, no render occur, no thread is displayed. This PR fixes the issue. runbot-106455 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 fixes an eCommerce product page issue where customers could see both “Add to cart” and “Contact Us” after selecting a product option that makes a zero-priced product sellable. The page now shows the appropriate purchase option, reducing customer confusion and improving the shopping flow.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Prevent Sale of Zero Priced Product; 2. have a product with attributes; 3. set its list price to 0; 4. add a price extra to one of its attributes; 5. go to its eCommerce page; 6. select the price extra attribute. Issue ----- Both the "Add to cart" and "Contact Us" buttons are shown. Cause ----- - Commit 8f4c8ada7e9fe refactored the `website_sale.product` template, moving the "Contact Us" button outside of the `div.js_product` element. - This element gets passed as `$parent` to the `_onChangeCombination` method, which ought to handle these changes. - Because the `#contact_us_wrapper` is no longer in `$parent`, it fails to find it and change its classes accordingly. Solution -------- Instead of querying for the `#contact_us_wrapper` element directly in `$parent`, look for the `#product_details` element first, then query it. opw-4423323
The online store add-to-cart snippets now correctly read true/false settings instead of treating every value as enabled. This ensures quantity options appear only when intended, including outside standard product pages, reducing customer confusion during shopping.
Original PR description
We forgot to parse a boolean which was stored as a string so it was always considered true (both the strings `'true'` and `'false'` evaluate to `true` in a boolean context. This change also fixes the `showQuantity` computation in the product and combo configurators (the computation assumed the user was on the product page, which isn't necessarily the case for "add to cart" snippets).
This fixes a test issue around recalculating allocated hours on project tasks when timesheet-related behavior is overridden. It helps ensure the timesheet and project task logic is validated correctly, reducing the risk of incorrect hour allocation handling.
Original PR description
In this PR https://github.com/odoo/enterprise/pull/78465 the test is failing because it is not taking the override into account as it is not a post_install. opw-4192775
Images in the HTML editor now keep their resized dimensions after using the transform option. This prevents images from jumping back to their original size or shifting position when rotated, making content editing more reliable.
Original PR description
### Steps to Reproduce: - Open the To-Do App. - Upload an image (e.g., `/image`). - Resize the image to 25%, 50%, or 100%. - Click the `Transform` button in the toolbar. ### Approach: - Initially,…
### Steps to Reproduce: - Open the To-Do App. - Upload an image (e.g., `/image`). - Resize the image to 25%, 50%, or 100%. - Click the `Transform` button in the toolbar. ### Approach: - Initially, `this.transfo.settings.style = this.image.style` created a shared reference to the same `CSSStyleDeclaration` object, meaning changes to one were reflected in both. - Later, when `this.image.style = settings.style` was executed, the inline styles were lost because it reassigned the same reference instead of copying the styles individually, resulting in properties like `width` being reset. ### Description of the issue/feature this PR addresses: - Resizing an image (e.g., 25%, 50%, or 100%) would revert it to its original size after clicking the `Transform` button. - Rotating the image would cause it to be misplaced. ### Desired behavior after PR is merged: - The image retains its resized dimensions after transformation. - The image remains correctly positioned during rotation. task-4251410
Recruitment users can now update interviewers for multiple applications at the same time without triggering an error. This makes bulk editing in the Applications list more reliable and avoids interruptions for HR teams managing candidate records.
Original PR description
Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view. Step to produce: - Install the `hr_recruitment` module. - Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them. `ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)` The error occurs because the system attempts to access a single value from multiple records at [1]. Link [1]: https://github.com/odoo/odoo/blob/f1637a10db2f34ca3a272792079115e0192489f8/addons/hr_recruitment/models/hr_applicant.py#L384-L385 To resolve this issue, Use an iteration(for loop) to process each record one by one. Sentry-6229305438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the internal test setup for Odoo Discuss display properly when simulating multiple browser tabs. It helps developers verify cross-tab behavior more reliably, reducing the chance of issues reaching users.
Original PR description
Discuss test helpers provide an `asTab` parameter to mount two main clients, simulating odoo being opened in two different tabs and a dropdown is available to switch from one view to the other. However, height is not propagated to the parent div. As a result, discuss components are invisible, as height is not working properly. This PR ensures the parent div is properly configured, allowing to see discuss UI. 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 editor toolbar now appears in the correct place when users select all content in right-to-left text. This improves editing reliability for languages that read right to left and avoids a confusing misplaced toolbar.
Original PR description
**Problem**: When selecting all content with `Ctrl+A`, the main `o_editable` element is selected, which has an `ltr` direction by default. If we switch the direction while having a single `rtl`…
**Problem**: When selecting all content with `Ctrl+A`, the main `o_editable` element is selected, which has an `ltr` direction by default. If we switch the direction while having a single `rtl` paragraph, the toolbar appears on the left instead of above the text. **Solution**: When `Ctrl+A` is used (selection is on `o_editable`), use deep position on the container edges. This simulates the browser’s default `Ctrl+A` behavior. **Example**: content: `<div contenteditable=true><p>tex[]t</p></div>` Existing Ctrl+A: `<div contenteditable=true>[<p>text</p>]</div>` New Ctrl+A: `<div contenteditable=true><p>[text]</p></div>` Default Ctrl+A (done by browser): `<div contenteditable=true><p>[text]</p></div>` **Steps to reproduce**: 1. Add some text. 2. Switch the text direction to `rtl`. 3. Press `Ctrl+A`. 4. The toolbar appears on the left instead of above the text. opw-4557762 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where installing the Chilean localization caused the Document Number field to appear on invoices for other Latin American localizations, such as Uruguay. After the change, the field remains visible where needed for Chilean invoices without affecting Uruguayan electronic invoices.
Original PR description
Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl…
Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl is modifying the visibility of the field "Document number" to appear when necessary directly on latam_invoice_document view. This make that the field visibility is being changed on other localizations as well when you have both installed. Current behavior before PR: The "Document Number" field below "Document Type" should is present on uruguayan electronic invoices (where it should not be). Desired behavior after PR is merged: The "Document Number" field is present on chilean invoices as expected and not in uruguayan electronic invoices. Steps to reproduce the error: - Install l10n_uy - On the UY company, go to Customer/Invoices section, create one, select a customer and check that you have an electronic journal selected. The field "Document Number" should not be present. - Install l10n_cl - Go to the previously created invoice and check that the field "Document Number" now appears. Ticket ADHOC side: 86491 Ticket Odoo side: 4505977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Message notification icons in the Mail app now look more subtle and respond visually when users hover over them, making it clearer that they can be clicked. Notifications with labels also have improved sizing and weight, so they read more consistently as buttons while failed notifications stand out better.
Original PR description
Before this commit, style of message notification icon (e.g. envelope) was not subtle enough. Intent was to use `text-600`, but due to typo this was not actually used (was `NaN` so does nothing). Also this wasn't clear this button is clickable, due to lack of moouse hover feedback. This commit fixes the issue by having an opacity change on mouse hover. When there's a failure, the static opacity is lower so that failed notifications are a bit more noticeable. Also message notification with label had slightly improper style that make them less look like a button: buttons should have a bit of font weight, and also the label was too big compared to icon. This commit also fixes that issue. Before  After 
This update improves and repairs internal automated tests for several Odoo Enterprise areas, including appointments, timesheets, and the mobile/web interface. It helps ensure future changes can be validated more reliably while keeping the impact limited to testing infrastructure rather than day-to-day user features.
Original PR description
## Pull Request HOOT (PRHOOT) 28 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/189710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how UPS delivery log messages are displayed by removing unsupported formatting inside translated text. It helps ensure users see clear, readable messages instead of broken or confusing HTML-style text.
Original PR description
HTML code in log messages does not work this way: `In Odoo 18, the _() function is used for translating strings and supports placeholders for variables. However, it does not support HTML tags such as <br/> or <b>.` 
Fixed an issue that prevented sales users from opening the commission pivot view. The commission achievement rate can now be aggregated correctly, avoiding the error and restoring access to reporting.
Original PR description
**Problem:** The problematic PR is this one : https://github.com/odoo/enterprise/pull/78537 This fix caused the pivot view to be inaccessible, creating a traceback, because the field 'achieved_rate' needs to be able to be aggregated. The line that removed the aggregator that was added was the new problem. https://github.com/odoo/enterprise/blob/137b233d4990ea9f48c8aa5b6a3990dc4170356b/sale_commission/report/commission_report.py#L19 **Steps to reproduce:** - Go to commissions in the sales app - Click on the pivot view - The traceback will appear **Fix:** Change the aggregator from None to the default one. opw-4512739
The sales commissions pivot view now opens without an error. Commission achievement rates are averaged when results are grouped, giving users a meaningful aggregated view of performance.
Original PR description
**Problem:** This is a reverse and improvement of a previous fix. The first PR is this one : https://github.com/odoo/enterprise/pull/78537 This fix caused the pivot view to be inaccessible, creating a traceback, because the field 'achieved_rate' needs to be able to be aggregated. The line that removed the aggregator that was added was the new problem. https://github.com/odoo/enterprise/blob/137b233d4990ea9f48c8aa5b6a3990dc4170356b/sale_commission/report/commission_report.py#L19 **Steps to reproduce:** - Go to commissions in the sales app - Click on the pivot view - The traceback will appear **Fix:** Change the aggregator from None to 'avg' to pick the average of the achieved_rate in case of a group by. opw-4512739
This fix prevents upgrade processes from creating duplicate demo document access records in the Documents and Project integration. It avoids setup or upgrade errors while keeping normal demo data loading behavior unchanged.
Original PR description
The upgrade script might create document access records that match the demo loaded from the data file, triggering a unique constraint record. Marking them as not forcecreate solves the issue and doesn't affect the normal behaviour of loading demo data. See: https://runbot.odoo.com/runbot/build/71461439