Daily updates from Odoo
Thursday, November 20, 2025
120 changes
5 changes
Resolved issues and error corrections
This change fixes a website editing issue where shape previews could stay stuck after the mouse moved away. It ensures the image returns to its original look correctly, so hover-based image options like shapes and filters behave as expected.
Original PR description
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop…
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop a text-image snippet onto the page. - Then add a hover effect to the snippet image. - Open the image shape selector and hover over the shapes. => Bug: the preview is broken; when the mouse leaves a shape, the original shape is not reset. Same issue with other options when there is a hover effect on an image (e.g. "image Filter"). Current flow is: We are previewing shape -> img src is changed -> `originalImgSrc` in `ImageShapeHoverEffect` interaction is changed -> we revert preview -> img src is reverted, but MutationObserver doesn't change `originalImgSrc` immediately, and when reverting a step, we stop the interaction -> destroy is called and image source is set to `originalImgSrc`, but it is the old one with a shape. We want to update the `src` only if it is currently the one that we set as hovering. [commit]: https://github.com/odoo/odoo/commit/80b5db99a3c26c3dd4fb5c55e04b8813dddb5b8d task-5207382
This change reverses a recent update to how journal items are shown so that adding new lines to accounting entries works correctly again. It fixes an issue that could prevent debit and credit amounts from being computed properly when users edit entries.
Original PR description
This reverts commit 6ed1e43b3f7d53c6a45fe24a1c68f8386e6adf8e. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. In stable versions, `journal_line_ids` is: * Kept but deprecated. * Made non-exportable. The field will be removed in `master`. task-5241650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the shop floor app from a Manufacturing Order now shows the correct work center for that order, instead of possibly reopening the last work center used by the operator. This prevents users from landing on the wrong screen and makes it easier to see and manage the current order from the smart button.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#99855 Forward-Port-Of: odoo/enterprise#93841
This update prevents an error when a helpdesk ticket is moved to Done or Canceled in a team that has no working hours configured. It ensures the closing process only uses the working-hours logic when that setting is actually present, avoiding an unexpected traceback for users.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
This update prevents an error when opening older Point of Sale refund orders created from multiple original orders. It ensures upgraded databases keep working correctly and avoids interruptions during upgrade checks.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224515 Forward-Port-Of: odoo/odoo#221355
3 changes
Resolved issues and error corrections
This change prevents an error that could appear when a helpdesk team has no working hours set and a ticket is moved to Done or Canceled. It makes ticket closing more reliable by only applying the working-hours logic when a schedule is actually configured.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
Opening the shop floor from a manufacturing order now takes users to the right work center and keeps the manufacturing order in view. This prevents users from landing on the wrong screen and makes it easier to continue production work without confusion.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#99855 Forward-Port-Of: odoo/enterprise#93841
This update prevents a crash when opening older point-of-sale refund orders created before a data model change. It ensures existing refund records are handled safely after upgrades, avoiding errors during normal use and upgrade checks.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224515 Forward-Port-Of: odoo/odoo#221355
2 changes
Resolved issues and error corrections
This change prevents an error that could happen when closing a helpdesk ticket if the team had no working hours configured in its SLA settings. It ensures the closing process only uses the working-hours logic when that setting is actually present, avoiding interruptions for users.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
This change stops the system from creating or updating a purchase request twice when the same approval is opened in multiple tabs or by multiple users. It helps avoid accidental duplicate quantities on purchase requests and keeps purchasing data accurate.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99706
5 changes
Resolved issues and error corrections
This change fixes an issue in the HTML editor where using Select All and Backspace could leave part of a mention behind. It ensures mentions are removed correctly when users clear the entire message, making editing behave as expected.
Original PR description
currently, when selecting all content (ctrl+A) in the html composer and deleting it (Backspace), if there is a mention in the content, only the text part of the selection is deleted, the rest remains. To reproduce: 1. mention a partner in the html composer, type some text after. 2. selecting all content (ctrl+A) and delete it (Backspace). 3. only one character will be deleted, the rest remains. This is the select all selects the deepest text nodes, meaning that the ndoe in the mention link will be selected. However, it is inside a protected node, so will lead to this issue. This commit fixes the issue by overriding the select all behavior when the selection contains protected nodes, to select the whole protected node instead of its content. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mentions placed directly in the message editor are now automatically wrapped correctly, which prevents them from becoming stuck or difficult to edit. This improves the reliability of typing and editing messages, especially when working with mentions.
Original PR description
In some cases, mentions can be inserted directly into the editable area without being wrapped in a base container. This can lead to issues when trying to edit or delete the mention, as the mention is a protected node. This commit updates the MentionPlugin to ensure that any mentions found directly under the editable area are wrapped in a base container. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents conditional display rules from reappearing incorrectly after changing the recipient model and using undo/redo in the mass mailing editor. It keeps the snippet state accurate, avoiding invalid rules that no longer match the selected model.
Original PR description
There is an issue with conditionally visible snippets in `mass_mailing` where a user is able to undo in the editor the reset of a filter caused by a recipient model change. How to reproduce: - Create a mass_mailing and add a conditional display rule on a snippet - Change the recipient model - undo, then redo Issue: - The rule appears again on the element, even though the model still has the new value. The domain is invalid, since it applied only on the previous model Resolution: - Make the `data-filter-domain` a `system_attribute` so it is not registered in the editor history. To inform the view that there was a change, `onChange` is called directly when the attribute value changes. task-5263043
This update reverts a change that was causing journal entry lines to behave incorrectly when users added or edited entries. It restores reliable automatic calculation of debit and credit amounts, which helps prevent posting and entry issues in accounting workflows.
Original PR description
This reverts commit 6ed1e43b3f7d53c6a45fe24a1c68f8386e6adf8e. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. In stable versions, `journal_line_ids` is: * Kept but deprecated. * Made non-exportable. The field will be removed in `master`. task-5241650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236457
This fix prevents Point of Sale refund orders from breaking after an upgrade when they were created with older data patterns. It ensures existing refund records can still be opened and processed normally, reducing upgrade-related errors.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224515 Forward-Port-Of: odoo/odoo#221355
2 changes
Resolved issues and error corrections
This fix stops users from accidentally changing values that should be read-only when they drag and drop items in Gantt planning views. It helps avoid unintended updates to planned work, such as changing the wrong product or work center during scheduling.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#94166
The stock forecast now uses the actual received quantity for completed stock moves instead of the originally planned amount. This fixes incorrect future/past forecast numbers when a receipt is validated for less or more than expected, helping users trust the inventory forecast shown on product pages.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
Resolved issues and error corrections
The German DATEV export now includes bills where the tax total was manually adjusted, so the exported amounts match what users see in Accounting. This prevents incorrect totals in the audit file and keeps the export aligned with the final invoice values.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488
This fix allows users to create a reordering rule for a product in one company even if that product has a kit bill of materials in another company. It prevents an incorrect validation error by only checking kit rules that belong to the same company, so company-specific settings no longer interfere with each other.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491
This change ensures product labels always use the correct currency when calculating prices. It prevents certain label templates from showing incorrect prices due to a parameter mix-up.
Original PR description
Description of the issue/feature this PR addresses: In product label reports, calling _get_product_price with positional arguments may lead to incorrect parameter binding (e.g. currency_id being interpreted as uom). This can cause wrong prices to be displayed in labels in some cases. Current behavior before PR: Some label templates pass currency as a positional argument. This may result in wrong prices being shown depending on argument order. Desired behavior after PR is merged: Label templates always pass currency as a keyword argument, ensuring correct price computation and preventing mismatches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr My CLA signature is being added in this PR: https://github.com/odoo/odoo/pull/236586