Thursday, April 9, 2026
29 changes · saas-19.1
Resolved issues and error corrections
This update fixes a display issue where rental products would show an 'out of stock' ribbon even when their quantity was zero. The change ensures that rental products don't incorrectly show this ribbon, aligning with their time-based stock availability. This improves the customer experience for rental orders.
Original PR description
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock…
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock Management` module. - Create a rental product and set Quantity On Hand to 1. - Under the Sales tab, disable `Sell when Out of Stock`. - Under the Rental Prices tab, add pricing. - Go to `website > ecommerce > products > product ribbons`. - Open `out of stock` ribbon > set assign as `when out of stock`. - Create and Confirm a rental order for that product and validate the pickup. - The product's Quantity On Hand drops to 0. - Opening the product on the website Observation: --- - The product shows the out-of-stock ribbon. Cause: --- - At [1], the or condition evaluates to True because the ribbon is configured as `when out of stock`, `Sell when Out of Stock` is disabled under the Sales tab, and `_is_sold_out` also returns True since the quantity dropped to 0 after the pickup was validated. As all conditions are met, the ribbon is returned and displayed without ever checking whether the product is a rental. Skip the out-of-stock ribbon assignment for rental products, since their stock availability is time-based. [1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28 opw-6081483 --- Forward-Port-Of: odoo/enterprise#112660
This update fixes an issue preventing users from manually digitizing vendor invoices when the Bill Date is initially missing. A previous change required a Bill Date to trigger digitization, which was inconvenient. Now, users can manually initiate digitization without a Bill Date, while still ensuring data consistency through a validation step afterward.
Original PR description
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ###…
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ### Cause: This PR: https://github.com/odoo/odoo/pull/238911 introduced a required field to prevent an error modal from appearing While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically ### Fix: A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date The validation modal is still enforced afterward to ensure data consistency in case of manual edits ### Steps to reproduce: - Install `account` - In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only` - Create and print an invoice (any data) or use an existing one - Import it into Vendor Bills - Click Digitize Document ### Before the fix: A missing required fields notification is raised, preventing digitization opw-5886012 Forward-Port-Of: odoo/enterprise#112585
This update corrects a stability issue within the Odoo Enterprise's expense tracking system. By switching to a 'TransientModel' for the wizard, the system is now more reliable and efficient. This change ensures smoother operation for users managing expense reports.
Original PR description
`HrExpenseStripeTestPurchaseWizard` is currently using a normal `Model`, but it's a wizard, so use a `TransientModel`. Forward-Port-Of: odoo/enterprise#113313
This update fixes a problem where users weren't receiving clear error messages when the delivery service failed. A helpful hint has been added to the system, guiding users to resolve the issue and ensuring smoother delivery processes. This change improves user experience and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This update fixes a technical issue where sending snailmail letters with more than 8 pages would result in a generic error. The change provides a more specific error message to users, making it easier to diagnose and resolve sending failures. This improves the user experience and reduces support requests related to this limitation.
Original PR description
When a user attempted to send a letter with snailmail that had more than 8 pages, sending would fail, and a generic error message is logged on the letter. This commit makes the error message generated in that flow more specific to help users better understand the root cause of sending failure. task-5883011 Forward-Port-Of: odoo/odoo#257867
This update fixes an issue where navigating with arrow keys around code blocks within the HTML editor was unreliable, leading to caret positions being incorrect. The changes ensure that arrow navigation now correctly moves between code blocks and paragraphs, providing a smoother and more intuitive editing experience. This improves the overall usability of the HTML editor for users.
Original PR description
### Description of the issue/feature this PR addresses: - When navigating with ArrowUp/ArrowDown around a code block, the caret could end up in an unexpected position. - Arrow navigation from start or end of a paragraph did not correctly enter the adjacent code block. - Arrow navigation from the start or end of a code block did not correctly move the caret to the previous or next sibling block. ### Desired behavior after PR is merged: - Paragraph start + ArrowUp moves to the end of the previous code block. - Paragraph end + ArrowDown moves to the start of the next code block. - Code block start + ArrowUp moves to the end of the previous paragraph. - Code block end + ArrowDown moves to the start of the next paragraph. task-5384549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241798
This update resolves a problem where the website's footer copyright information would break when editing the footer layout, particularly with the mega footer option. The fix ensures the copyright displays correctly by adjusting how Odoo handles template updates and prioritizing the footer template execution.
Original PR description
Steps to reproduce: =================== 1. Go to website and switch footer to mega footer 2. Add a language & edit copyright text 3. Save & change the language => breaks Cause: ====== Editing…
Steps to reproduce: =================== 1. Go to website and switch footer to mega footer 2. Add a language & edit copyright text 3. Save & change the language => breaks Cause: ====== Editing triggers Odoo's Copy-On-Write (COW) mechanism, creating a customized template with a higher database ID. This causes it to execute after the mega footer templates, which expect col-sm classes that were already changed to col-md. The xpaths fail and the footer breaks. The existing patch in html_editor/models/ir_ui_view.py (from [1]) that re-adds col-md when saving one of the affected views was not working in this case because the write was done with delayed_translations=True in context, causing the ancestor patch to be skipped. Solution: ========= - Add `delayed_translations=False` to the ancestor write in `ir_ui_view.py` so the patch is applied immediately when editing the footer. This prevents the issue without requiring a module update. - Add priority="15" to `footer_copyright_company_name` so that even for already-broken databases (where COW was created before this fix), the template runs before mega footer templates after a module update. The priority is inherited by COW-generated views. [1]: https://github.com/odoo/odoo/commit/2d6699b4c460084110ccada0392845156af4a135 opw-5485986 Forward-Port-Of: odoo/odoo#248833
This update resolves a technical issue that prevented the requirements-check script from correctly parsing version numbers containing letters and suffixes (like 'post1'). This ensures accurate dependency checks and prevents potential errors when specifying software requirements, improving stability.
Original PR description
This commit fixes a crash in the parse_version() function where it doesn't support non-integer castable version parts (i.e. 5.4.2.post1). Forward-Port-Of: odoo/odoo#257946
This update fixes an issue where invoicing a Point of Sale order multiple times would create unnecessary stock pickings. This change ensures that only one picking is generated when an order is invoiced, regardless of how many times the 'Invoice' button is clicked. This improves efficiency and avoids potential stock discrepancies, particularly in configurations that automatically update stock levels at closing.
Original PR description
Calling `action_pos_order_invoice` on an already-invoiced POS order (e.g. a backend user clicking "Invoice" more than once) would unconditionally invoke `_create_order_picking`, producing one extra `stock.picking` per click under anglo-saxon + update_stock_at_closing configurations. opw-6092999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257509
This update resolves an issue causing inconsistent styling in the point-of-sale category selector. By ensuring the `category-list` class is always applied, the selector now renders consistently across different devices and environments. This improves the overall user experience for sales staff.
Original PR description
Before this commit: ==================== Previously, the `category-list` class was conditionally applied based on `show_category_images`, which caused inconsistent styling and layout issues. After this commit: ======================= This commit ensures that both `product-list` and `category-list` classes are always present, providing consistent rendering of the category selector. Task-6092404 Forward-Port-Of: odoo/odoo#257988 Forward-Port-Of: odoo/odoo#257251
This update ensures that tax report lines in the Dutch (nl) version of Odoo consistently display negative signs, aligning with existing supply reporting practices. Previously, the sign was missing, causing inconsistencies and potential confusion for users configuring taxes. This change maintains a standard reporting format.
Original PR description
It is be better to change the sign, because it is under supplies and the other report lines in that section also have a negative sign. In other words, anyone who would have configured the tax, would have used the negative tag to configure it right before. Now that the sign on the tags is gone, we need to put it correctly on the report line. opw-5874677 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#255039
This update corrects a minor typo within the Odoo test code. The issue was partially addressed previously but lost during a conflict resolution. This change is being reintroduced in the 19.1 SaaS version and is not relevant for older versions.
Original PR description
This was partially fixed in another [pr](https://github.com/odoo/odoo/pull/228977) but the fix was lost while solving conflicts. Reintroducing the fix starting from 19.0 since we don't really care about this specific test in eol saas-18.x versions Forward-Port-Of: odoo/odoo#258278
This update fixes an issue where subtasks created from project templates didn't correctly inherit the sale line ID from their parent task. Previously, logging hours on subtasks resulted in an empty timesheet line. The fix ensures that all tasks, including subtasks, accurately reflect the associated sales order, improving data consistency and reporting.
Original PR description
When creating tasks from a project template via a Sales Order, the main task is created with its sale_line_id set correctly, but subtasks from the template do not inherit the sale_line_id from their…
When creating tasks from a project template via a Sales Order, the main task is created with its sale_line_id set correctly, but subtasks from the template do not inherit the sale_line_id from their parent. Steps to reproduce: 1. Create a project template with a parent task and subtasks 2. Create a service product that uses this project template 3. Create and confirm a Sales Order with this product 4. Check the created tasks: main task has sale_line_id, subtasks don't 5. Log hours on a subtask: the timesheet's so_line remains empty Root cause: When copying a project template, the copy_data() method for subtasks was resetting the default dict to only contain 'parent_id': False. This meant that whitelisted fields like sale_line_id from the parent task were not propagated to the subtasks during the copy operation. Solution: When copying from a template (copy_from_template context), preserve whitelisted fields (including sale_line_id) in the default dict before copying subtasks. This allows subtasks to naturally inherit sale_line_id from their parent during creation, so the compute method works correctly. opw-5185519 Forward-Port-Of: odoo/odoo#236342
This update prevents unnecessary camera permission requests when hiding the call invitation's camera preview. Previously, users were repeatedly prompted for permissions, even when the camera was not visible. This change improves the user experience and resolves a related issue impacting a local test tour.
Original PR description
Before this commit, hiding the camera preview in the call invitation would prompt the user for device permissions again. This is unnecessary since we are hiding the camera preview. This commit fixes the issue by aksing for device permissions only when showing the camera preview. This commit also indirectly fixes the `discuss_call_invitation_tour` failing locally. task-6095245
This update resolves an issue where custom snippets that were hidden on desktop or conditionally visible appeared as blank in the website builder's preview dialog. The changes ensure that all snippets, regardless of their visibility settings, are accurately displayed, improving the user experience when creating and previewing website content. An icon has also been added to identify invisible snippets.
Original PR description
The (saved custom) snippets which were invisible on desktop or conditionally invisible, appeared as empty in the dialog to preview snippet. This commit changes the css rules so that - conditionally visible elements are always visible in preview - snippet that are device invisible are show with the overlay (and inner elements that are device invisible are not shown) Steps to reproduce: - Open website builder - Drop a section - Change the "Visibility" to hide on desktop - Click on the eye to show it - Save the snippet as a custom snippet - Open the dialog to add a snippet - Bug: the newly saved snippet is shown as empty Same for "Visibility" to "Conditionally". And Same for "Visibility" to hide on mobile, if the window size is reduced when showing the dialog. task-5149984 Forward-Port-Of: odoo/odoo#250395
This update resolves an issue where the department dropdown was empty in the demo activity plan configuration. The fix corrects a misconfiguration in the demo data that was preventing departments from appearing. This ensures users can correctly assign departments to onboarding and offboarding plans.
Original PR description
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The…
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The dropdown is empty even if department exists. This can be check by creating a new plan and trying to assign departments to it. # Cause The demo data for thoses two plan explicitely sets the company_id to false : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L21 https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L48 But the department_id has check_company set to true : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/models/mail_activity_plan.py#L12 # Proposed solution Backport of this commit : https://github.com/odoo/odoo/pull/240167 opw-6058697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255842
This update addresses a technical error that occurred when generating QR codes for UPI payments within the In-POS module. The fix ensures that the payment process continues smoothly, preventing errors and improving the user experience. This change focuses on maintaining the integrity of the system's error handling.
Original PR description
With the 'upi' qr method, we get a `NotImplementedError` raised by `ResPartnerBank._get_qr_code_generation_params` when trying to open the payment register wizard from a vendor bill. With this commit, we override the method to return None for the 'upi' method case, that way we keep the correct way of using `NotImplementedError` which expects us to always implement `_get_qr_code_generation_params` when we add `_get_available_qr_methods`, to make it explicit that there is nothing to do and that we didn't forget to implement. opw-5978048
This update resolves an issue where button styling was inconsistently applied in the website editor. The fix ensures that buttons with size or shape classes are correctly identified as 'custom', aligning with recent changes to Odoo's styling options. This improves the visual consistency and functionality of buttons within the website editor.
Original PR description
Before this commit: Since the removal of button style options for the preset primary and secondary styling, the type of a primary/secondary button with size or shape defined in the class should be "custom". The fix is made to saas-18.4 cause the custom button option is removed in saas-18.3 and reintroduced only from saas-18.4. The button option removal commit: https://github.com/odoo/odoo/commit/a7b71d700e4997e4a2f646e2ae12f58f20058dc4 The button custom option reintroduction: https://github.com/odoo/odoo/commit/ea22b28bbae009c9eab4ff397affa9a3cb71037a After this commit: when the button has size or shape classes, we consider it as "custom" button. task-6061443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257156 Forward-Port-Of: odoo/odoo#256015
This update resolves an issue where the HTML editor would unexpectedly scroll to the top when the command palette was closed. The fix ensures the editor's selection is maintained, preventing this disruptive behavior. This improvement enhances the user experience within the HTML editor.
Original PR description
Before this commit: the editable area scrolls to the top when the command palette is closed by clicking the gray zone After this commit: we override the focus function of the editable and use focusEditable instead, which keeps the selection. Note it's a succession fix of https://github.com/odoo/odoo/pull/250624 and both of them are a workaround without touching the ui_service and command palette. Also added super.destroy() in the previous fix till 18.4. task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256695 Forward-Port-Of: odoo/odoo#253638
This update fixes a display issue in the Delivery Slip report where backorder lines were missing their unit of measure. The fix removes a technical restriction that was previously hiding this information, ensuring all delivery line details are consistently shown. This improves clarity and accuracy for users reviewing delivery reports.
Original PR description
**Steps to reproduce:** * Install the **Stock** module with demo data. * Create a delivery with quantity **N** and click **Mark as To Do**. * Set the delivered quantity to less than the demanded…
**Steps to reproduce:**
* Install the **Stock** module with demo data.
* Create a delivery with quantity **N** and click **Mark as To Do**.
* Set the delivered quantity to less than the demanded quantity .
* Validate the delivery, with the creation of a **backorder**.
* Print the **Delivery Slip** report.
**Observed behavior:**
* Backorder lines appear **without units of measure**, while
other lines correctly display their units.
**Cause:**
* The backorder line includes a **group restriction** that hides
the unit unless the *Unit of Measure* setting is enabled.
**Fix:**
* Remove the group restriction so units of measure are
always visible on backorder lines same as others.
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/5f21139a-a4ab-4c39-8b16-3c68c94a163e" />
After:
<img src="https://github.com/user-attachments/assets/dd4de18b-dc2e-4686-8435-30864fe40aa4" />
</details>
---
> NOTE - This fix done after receiving confirmation from PO(dala)
---
opw-5265051
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258235
Forward-Port-Of: odoo/odoo#238470This update clarifies the instructions for setting up printers in the Point of Sale system. The previous help message was inaccurate, leading to confusion. This change ensures users correctly connect IoT printers using the appropriate settings, improving the overall user experience.
Original PR description
The "help" message displayed on the Printers settings was misleading: "connect devices without IoT Box", even though the IoT printer has to be connected using the same field.
This update ensures that refused time off requests are now clearly marked on the calendar view within the Overview menu. Previously, these requests weren't visually distinguished. This change improves clarity and accuracy for managers reviewing employee time off requests.
Original PR description
Before this commit, the calendar view in Overview menu does not strike the time off refused. The reason is because `is_strike` field is not fetched inside that view. This commit adds the field in the view to make sure the time off refused are striked as it is the case in the other menus. Closes #248868 Forward-Port-Of: odoo/odoo#256723 Forward-Port-Of: odoo/odoo#256579
This update fixes a visual issue in the mass mailing editor where setting button sizes (Large, Small) or styles (Outlined) didn't actually change the button's appearance. The update now correctly applies the selected size and style, providing a more consistent and customizable user experience for creating marketing emails.
Original PR description
Currently, setting a button as Large, Small, or Outlined has no impact on the appearance of the button, as it instead remains dependent on mailing-wide set button dimensions and colors. Steps to reproduce: - Create a new mailing - Type /button in the editor to insert a button - Select the button and set its size as Large/Small or its nature as Outlined - The button's appearance does not change This commit allows Large, Small and Outlined button attributes to have an effect on button appearance. Sizes will scale linearly with mailing-wide button dimensions. task-5910193 Forward-Port-Of: odoo/odoo#252033
This update resolves a problem causing inconsistent test results in the HTML editor. The fix ensures tests wait for the system to fully initialize before running, preventing failures due to timing issues. This improves the reliability of the HTML editor's testing process.
Original PR description
See individual commits. Forward-Port-Of: odoo/odoo#258148 Forward-Port-Of: odoo/odoo#257620
This update fixes an issue where project template tasks were incorrectly displayed in standard task views. Now, template tasks are hidden by default, but can be easily viewed when the 'Template Tasks' filter is selected. This ensures a cleaner and more intuitive task management experience.
Original PR description
## Current behavior before PR: - When a user viewed All Tasks or My Tasks, tasks related to project templates were visible. - When a user specifically selected the Template Tasks filter, tasks associated with template projects were not visible. ## Desired behavior after PR is merged: - When a user views My Tasks or All Tasks, tasks related to template projects are hidden. - When a user selects the Template Tasks filter, both template tasks and tasks associated with template projects are shown. ## Additional note A modification to `project_report.py` was required because it inherits from the project task view and overrides the view’s reference model. Task-[5485658](https://www.odoo.com/odoo/project/4105/tasks/5485658) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245920
This update ensures that new purchase orders, repairs, and stock picking batches display translated names instead of the default 'New' in English. This change aligns with existing Odoo logic and provides a more consistent and user-friendly experience, especially for international users.
Original PR description
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258156
This update fixes an issue where event descriptions in Outlook Calendar downloads were displayed as raw code instead of properly formatted HTML. The fix converts HTML content to text specifically for Outlook compatibility, ensuring event details are displayed correctly when users download and view their events.
Original PR description
### Steps to reproduce: - Download Events app. - Pick an event and click "Go to website". - Download the Outlook Calendar. ### Issue: - The HTML content within the event description is displayed as raw code and not converted properly - This happens because outlook takes the description as text and displays it in the ics file without conversion ### Solution: - Since we're working with *Outlook Calendar*, X Alt formatting was added to format HTML to text opw-5237027 Forward-Port-Of: odoo/odoo#257978 Forward-Port-Of: odoo/odoo#246603
This update ensures that the milestone list view, accessed through both the Kanban and top bar actions, displays all relevant sales-related information. Previously, the top bar action didn't include these key metrics, leading to an incomplete view of project milestones. This change standardizes the view for improved reporting and analysis.
Original PR description
Steps to reproduce: - 1. Install the sale_project module. 2. Open a project and ensure it is billable. 3. Compare the view opened from the "Milestones" link in the Kanban view with the view opened from the "Milestones" top bar action. Issue: - The milestone list view opened from the top bar action does not display sales-related fields (e.g., "Quantity (%)"). Cause: - The Kanban view calls the `action_get_list_view` python method, which is overridden in sale_project to add a custom list view including sales-related fields. The top bar action was using a static XML action, bypassing this python logic. Fix: - Update the Milestones embedded actions to call the `action_get_list_view` python method instead of using a static XML action, ensuring top bar uses the same view as others. task-5993183 Forward-Port-Of: odoo/odoo#258149 Forward-Port-Of: odoo/odoo#254102
This update resolves an issue where the AutoComplete dropdown would unexpectedly close when its value changed without user input. Specifically, this prevented the dropdown from staying open while the system updated the category selection in the Expenses module. This ensures a smoother user experience when selecting categories.
Original PR description
Before this commit, when the props of the AutoComplete were updated such that the value changed while the dropdown was opened, but the user didn't type anything yet, the dropdown was closed. This could be reproduced in Expenses: - click "New" to create a new expense - set a description - blur the description field by clicking on the category many2one => the autocomplete dropdown briefly opened and closed itself again while the onchange returned, as it set the value of category_id. This commit fixes the issue by never closing the dropdown when the value is changed. Issue reported in the rd-framework-js channel Part of task 5491410 Forward-Port-Of: odoo/odoo#258070