Thursday, April 2, 2026
39 changes · saas-19.2
New functionality added to Odoo
This update adds tests to the Timesheet Dashboard feature, ensuring that the correct data is consistently loaded each time a user accesses the sheet. These tests enhance reliability and data accuracy for sales teams using the dashboard.
Original PR description
add tests for the timesheet dashboard sheet selection to ensure that the right sheet is loaded each time --- task-5956339
Resolved issues and error corrections
This update resolves an issue where line breaks added to quotation template section titles were being removed. The fix ensures section titles display correctly as intended, preventing users from needing to create new sections for multi-line titles. This improves the user experience when creating and managing quotation templates.
Original PR description
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with…
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with line breaks using `Shift + Enter`. - Go to sale orders > Create new SO > Set quotation template created above. Issue: --- - Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one. Root cause: --- - At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2]. Solution: --- - Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered. [1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96 [2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86 opw-6034255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256058
Features or functions removed from Odoo
This update removes restrictions on which country codes can be used when registering PEPPOL accounts within Odoo. Previously, registration was limited to numbers on a specific list. Now, businesses can register PEPPOL accounts from a wider range of countries, increasing flexibility and access to the PEPPOL network.
Original PR description
Before this commit, only numbers on the peppol list were able to be registered. Now is possible to add numbers from other countries. Task-6033336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254373
Documentation and clarification updates
This pull request updates the contributor list in the Optesis documentation to reflect the correct name, Ibrahima NIASSE EXT, for a key contributor. This ensures accurate records and proper recognition of individuals involved in the project. The change was made to align with the latest contributor details.
Original PR description
Replaced Mame Abdoul Aziz SY with Ibrahima NIASSE EXT in the contributors list. 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#256563
This update corrects a visual issue in the mass mailing builder where text styling (specifically using the 'text-muted' class) was inconsistently applied based on background colors. The fix ensures that the muted text style is always applied correctly, regardless of the background color used within the builder, resulting in a more polished and predictable user experience.
Original PR description
This commit fixes an issue with the `text-muted` class that gives a specific color to the text based on a background-color. Since the mass_mailing builder is a special case for background colors. The class now gives a specific color no matter what the background color is set when used inside the mass_mailing builder. task-5993139 Forward-Port-Of: odoo/odoo#252419
This update resolves an issue where link colors reverted to the default after using the website editor. The fix ensures that link colors remain as intended, regardless of whether the editor is open or closed, providing a consistent user experience for website content. This improves the visual quality and usability of our website.
Original PR description
Problem: Colored links revert to the default link color after saving and closing the website editor. Cause: The rule forcing links to inherit color from their parent `<font>` element is defined in the `html_editor` module, whose stylesheet is unloaded when the editor is closed, so the rule no longer applies on the frontend. Solution: Add the rule to `website_common.scss` so it applies on the frontend regardless of whether the editor is loaded. Steps to reproduce: 1. Open the website editor. 2. Apply Color to selection. 3. Apply link to the subset of the selection. 4. Save and close the editor. 5. Observe the link reverts to its default color. task-5980854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256630 Forward-Port-Of: odoo/odoo#253301
This update corrects a visual issue where the table row menu was misaligned in websites using right-to-left (RTL) languages like Arabic. The fix ensures the menu's position is correctly calculated during editor initialization, resolving a display problem for users viewing the system in RTL layouts. This improves the overall user experience for international users.
Original PR description
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the…
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the editor initialization. Solution: Ensure the `direction` parameter is properly passed during editor initialization so the `inlineStartOffset` is computed correctly in RTL layouts. Before: <img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" /> After: <img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" /> Steps to reproduce: - Change website language to Arabic. - Add a text block and insert a table inside. - Hover over the first table row. - Observe the row menu is misplaced. opw-6049260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256045
This update resolves a minor issue with the HTML editor's color selector, ensuring more consistent test results. Because the toolbar is a popover, it was susceptible to unpredictable behavior. This fix improves the reliability of the HTML editor's testing process.
Original PR description
The toolbar is a popover and is therefore affected by [1]. runbot-242071 [1] 54da715 Forward-Port-Of: odoo/odoo#256783
This update resolves an issue where searching for inactive accounts by their code didn't return results. The fix adjusts the search criteria to correctly include inactive accounts, ensuring accurate search functionality within the chart of account. This improves data accessibility and reporting.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256939
Forward-Port-Of: odoo/odoo#256060This update fixes a crash that occurred when settling subscription orders through the Point of Sale (PoS) system. The issue stemmed from incorrectly processing discount lines, leading to a template error. The fix now correctly handles these discount lines as notes, ensuring smooth PoS transactions.
Original PR description
**Steps to reproduce:** - Make a subscription product - Make a quotation with it, confirm it, then invoice it - Go back to the sale order and upsell it - Add another product - Go to the PoS to settle the order - A traceback appears **Why the fix:** Why tried to treat the informative line that says that this is a discount as a normal pos order line. We then tried to access the line's template, which caused a crash as the line's template was undefined. We now treat the line as we do a note, meaning to add it to the previous line in the order. We create a function to check if the line is a note and we override it in the **pos_sale_subscription** module. Enterprise PR: https://github.com/odoo/enterprise/pull/107002 opw-5582448 Forward-Port-Of: odoo/odoo#256378 Forward-Port-Of: odoo/odoo#247846
This update corrects a technical issue that prevented snailmail reports from being sent correctly when users lacked sufficient access to company data. The fix now grants elevated access (sudo) to the IAP account, ensuring reports can be processed without errors. This improves the reliability of the snailmail feature.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to read from res.company model Fix: Access the IAP account as sudo opw-6050041 Forward-Port-Of: odoo/odoo#255959 Forward-Port-Of: odoo/odoo#255431
This update corrects a minor issue in how Odoo identifies PDF files. Previously, the system was overly restrictive in recognizing PDF mimetypes, potentially causing problems with certain files. This change restores the ability to handle PDF mimetypes with optional parameters, ensuring broader compatibility and accurate file processing.
Original PR description
The structure of a MIME type commonly consists of just two parts: a type and a subtype, separated by a slash (`/`), but optionally it can also contains parameters to provide additional details (`type/subtype;parameter=value`). This commit restores this nuance in the PDF mimetype check that was made stricter in the commit odoo/odoo@b048078971f4f12307740a8b382b762a35983059. Reference: - https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types runbot-241165 Forward-Port-Of: odoo/odoo#256804
This update fixes a labeling issue with the 0% VAT rate for sales outside the EU in Sweden. The tax name has been corrected to '0% EX RS' and linked to the appropriate grid, ensuring accurate reporting and compliance with Swedish tax regulations. This change improves the accuracy of financial data.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256659 Forward-Port-Of: odoo/odoo#251750
This update resolves an issue where users would encounter access errors when creating private tasks. The fix ensures that a user is automatically added as a task follower upon creation, granting them necessary access rights regardless of the task's project association. This improves the usability of private task creation.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257050 Forward-Port-Of: odoo/odoo#242216
This update resolves a technical issue causing errors in the 'Actual Margins' report, specifically when generating reports for billable projects. The fix corrects a misconfiguration in the report's data access, ensuring the report functions reliably across both Enterprise and Community editions. This improves data accuracy and prevents disruptions for users generating these reports.
Original PR description
Steps to reproduce: - Bug 1: 1. Create a billable project linked to a Sales Order. 2. Invoice the Sales Order. 3. Open the "Actual Margins" report from the project. 4. Click a value in "Revenues (Fixed Price)". 5. Open a record from the list. - A traceback occurs with KeyError on account.analytic.line. Bug 2: 1. Open the "Actual Margins" report in Odoo Community edition. - It throws a traceback: "View type grid not found in act_window action". Cause: - Bug 1: In `action_open_account_analytic_line_origine`, the `res_model` in the action dict is set to a recordset instead of a model name string. Bug 2: The `grid` view type (Enterprise only) was incorrectly included in the `view_mode` field of the Community action. Fix: - Bug 1: Use `._name` to pass the model name instead of the recordset. Bug 2: Remove `grid` from `view_mode` as the Enterprise module already adds it via an `ir.actions.act_window.view` record. task-6085406
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The change utilizes modern URL handling techniques for accurate URL representation, ensuring correct links are displayed to users. This improves the reliability of email communications.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#256850 Forward-Port-Of: odoo/odoo#254383
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data corruption.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 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#256009 Forward-Port-Of: odoo/odoo#255316
This update resolves an issue where users couldn't close popups using the Escape key. The fix ensures the correct Bootstrap event handler is triggered, regardless of whether the popup contains interactive elements. This improves the user experience by providing a reliable way to close popups.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#254284
Forward-Port-Of: odoo/odoo#250050This update fixes an issue where URLs resembling phone numbers were incorrectly interpreted as phone links. The change strengthens the regex used to identify phone URLs, preventing unintended 'tel:' protocol additions. This ensures URLs are correctly linked to pages, improving user experience.
Original PR description
# How to reproduce - Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number) - Go to another page in edit mode…
# How to reproduce
- Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number)
- Go to another page in edit mode
- Select a button
- In the "Enter URL, /page, or #anchor" input, write the url to your page (/3-14)
- Click on Apply
# The problem
Instead of a link to our page, the button has a link with a tel: protocol.
# Cause
When clicking on the Apply button, the `applyDeducedUrl()` function will be run.
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/link_popover.js#L294
That function will change the selected url with the URL deduced from `deduceURLfromText()` if any is found. In our case "/3-14" matches the `PHONE_REGEX` pattern so the url is prefixed with the tel: protocol.
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L71
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L34
That regex is a bit too permissive and allows our "/3-14" to be matched even though it starts with "/".
Side note : cases like "( )", "...", "--)" are also a match, which is not really an issue because they do not really represent anyting but it shows that the regex is not strict enough.
# Proposed solutin
We edit the regex to make it so it only matches strings that have atleast a digit and where the first character (after "+") is a digit or "("
opw-6047571
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255877This update resolves an issue where project users with limited access couldn't add customers to tasks, resulting in an access error. The fix involved a secure update to customer records and restricted editing permissions, ensuring all project users can now correctly associate customers with tasks.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#256921 Forward-Port-Of: odoo/odoo#252406
This update resolves an issue that occurred when users attempted to validate delivery records created with a sale order that lacked any order lines. The fix ensures a default sequence value of zero is used, preventing a 'max() arg is an empty sequence' error and allowing deliveries to be successfully validated. This improves the reliability of the sales order fulfillment process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254803 Forward-Port-Of: odoo/odoo#239030
This update corrects a bug that prevented the correct display of amounts in words for Czech users. A temporary workaround was implemented, but will be removed automatically when Odoo uses a newer version of the `num2words` library with the necessary Czech language support. This ensures accurate financial reporting in Czech.
Original PR description
The `num2words` library has a bug in the language code they used for Czech (`cz` instead of `cs`). This commit adds a monkey patch to map the correct language code to the existing converter class, allowing the amount in words to work in Czech. The issue was fixed in version 0.5.14 of the library, so this patch can be removed once we use Ubuntu >= 25.10 (Python >= 3.13), that contains the fixed version of the library. [opw-6088697](https://www.odoo.com/odoo/project.task/6088697) Forward-Port-Of: odoo/odoo#257232 Forward-Port-Of: odoo/odoo#257031
This update resolves an issue where background images in mass email templates were not rendering correctly due to how Odoo handled HTML attribute quoting. The fix ensures background image URLs are properly converted to absolute paths, guaranteeing images display as intended across email clients. This improves the visual quality of mass email campaigns.
Original PR description
Problem: Background images in mass mailings were sent with relative URLs, resulting in broken images in email clients. Cause: When serializing, lxml will use single quotes for attribute values that contain double quotes, and double quotes for attribute values that contain single quotes or no quotes. It automatically picks the attribute delimiter to produce valid HTML, which explains why `style="..."..."`` becomes `style='..."..."'` after `tostring()`. Solution: Update the regex in `mail_render_mixin.py` to support both `"` and `'` delimited `style` attributes, ensuring background-image URLs are properly converted to absolute paths. Steps to reproduce: - Add any masonry snippet (with background image). - Send the email. - Observe the received email uses a relative image URL. opw-5974203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254652
This update resolves an issue where virtual keyboards unexpectedly appeared on touch devices when opening dialogs. The change ensures that focus is correctly placed within the dialog, preventing the keyboard from triggering while maintaining the expected functionality.
Original PR description
Commit 1 addressed an issue where the virtual keyboard would pop up unexpectedly when navigating on touch devices. However, due to commit 2, opening a dialog traps the focus in the dialog and automatically focuses on the first element. On touch screens, this behavior triggers the virtual keyboard. This commit changes the behavior so that, on touch devices, the focus is on the main part of the dialog instead of the first input field. This prevents the virtual keyboard from opening while ensuring the focus trap remains active. opw-5970020 1: https://github.com/odoo/odoo/commit/9d8f9d90743490c37a89fa71be087d38924164e7 2: https://github.com/odoo/odoo/commit/cd624c891f356c0527f5bb75cdfe1e05b7b79a21 Forward-Port-Of: odoo/odoo#257120 Forward-Port-Of: odoo/odoo#256880
This update resolves a technical issue causing excessive memory usage in the account reports module. The fix ensures that report preloading stops when the component is destroyed, preventing a memory buildup that could impact performance. This improves the stability and responsiveness of the account reporting feature.
Original PR description
The preloading of sections would never stop, this is an issue since this would prevent the garbage collector from collecting this big class and all it's objects. We fix this by making sure to stop the reploading when the component is destroyed. It's important to do it this way rather than clearing the timeout as the destruction could happened when the report is loading so the timeout would be unset and a new one would be started. Forward-Port-Of: odoo/enterprise#112810 Forward-Port-Of: odoo/enterprise#112628
This update resolves a technical issue that was causing platform order flow tests to fail due to a missing POS printer in the test environment. The fix ensures that tests can complete successfully without crashing, improving the reliability of our automated testing process.
Original PR description
When running platform order flow tests, calling `mark_platform_prep_order_as_printed` raises a ValueError because the test environment lacks active POS printers (they are unlinked during setup). This commit patches the method to catch the ValueError and return False, allowing the POS tours to complete successfully without crashing. build_error-241260 Forward-Port-Of: odoo/enterprise#111076
This update fixes a display issue where subscription product billing periods weren't shown in product snippets on the website. The fix ensures that all subscription products, regardless of where they're displayed (shop page or snippet), accurately show their billing periods. This improves the clarity and accuracy of product information for customers.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943 Forward-Port-Of: odoo/enterprise#112787 Forward-Port-Of: odoo/enterprise#112171
This update resolves a test failure caused by demo data incorrectly influencing article sequence numbers. The test now dynamically calculates the expected sequence number, ensuring consistent results regardless of whether demo data is enabled. This improves test reliability and stability.
Original PR description
In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant. When…
In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant. When no sequence number is provided, the system automatically assigns one by taking the highest existing sequence among articles with the same parent and incrementing it by 1. When demo data is enabled, additional users are created along with their corresponding onboarding articles. As the onboarding articles does not have any parent, the onboarding article are included in the computation of the sequence number of the new article we create in the test. These extra articles impacts the sequence number of the new article, causing the test assertion to fail. To resolve this, the test computes the expected sequence number dynamically based on the current state of the data. This ensures consistent behavior regardless of whether demo data is present. runbot-error-id~231695 Forward-Port-Of: odoo/enterprise#106326
This update resolves an issue where users were incorrectly added as followers of chatter threads, leading to unwanted notifications. The fix ensures the correct user ID is used, preventing this unintended behavior. Additionally, a cron job issue was addressed to ensure all records are processed correctly.
Original PR description
The method call that is supposed to subscribe the current user to the closing entry when posting XBLR used the User id as a Contact id. This caused random contacts to be added as followers of the chatter thread and as a result receiving notifications for it. The fix is simply using the id of the User's Contact instead. Also, as discussed with prro on Discord, fixed the cron clearing its dictionary each loop. opw-5886621 Forward-Port-Of: odoo/enterprise#112709 Forward-Port-Of: odoo/enterprise#107843
This update resolves an issue where subscription discounts weren't being correctly processed during sales order imports. The change modifies how the system handles subscription discounts, ensuring they are accurately reflected in sales data. This improves the reliability of subscription-based sales reporting.
Original PR description
This is a test for the related community fix and an override of the **isSaleOrderLineNote** method to add the subscription specific **subscription_discount** lines to be treated as a note when importing it from the Sales module. https://github.com/odoo/odoo/pull/247846 opw-5582448 Forward-Port-Of: odoo/enterprise#112326 Forward-Port-Of: odoo/enterprise#107002
This update resolves a problem where the 'Reconcile' button was incorrectly displayed on mobile devices after a bank statement line was fully reconciled, causing errors. The fix ensures that the button is hidden when a line is reconciled, and displays the correct reconciliation information, improving the mobile user experience.
Original PR description
Currently, when a line is fully reconciled, we display all the moves, name of the reconciliation, and we hide the `Reconcile`, `Set Partner`, ... buttons, has the line is reconciled, we don't need the buttons. But in mobile, we still display the buttons (like `Reconcile`), leading to a traceback when clicking on it. Furthermore, instead of showing the moves name, we show a `[object Object]`. This bug was probably introduced here: https://github.com/odoo/enterprise/pull/101692 task-6058911 Forward-Port-Of: odoo/enterprise#111605
This update resolves an issue where tests for Italian tax reports were failing due to missing data required for XML validation. The changes ensure the tests now properly populate the necessary 'codice fiscale' field, allowing the validation process to complete successfully. This improves the reliability of the tax report generation process.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544 Forward-Port-Of: odoo/enterprise#112629
This update resolves an issue where planning users couldn't update customer phone numbers within planning slots. The fix involved implementing security controls – specifically, restricting access and using secure update methods – to prevent errors and ensure data integrity. This ensures planning users can correctly manage customer information.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Planning > User" access. 2. Create a new planning slot. 3. Add a customer on the slot whose partner is linked to a res.users account. 4. Access error is raised. Issue: - - Planning users could not update the partner phone on a slot. - An access error appeared when updating the phone number. Cause:- - - When a customer was added to the slot, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/enterprise#112650 Forward-Port-Of: odoo/enterprise#93969
This update clarifies the description of the `esg.activity.type` model to explicitly state its use within the ESG reporting framework. Previously, the description was identical to the general `activity.type` model, which could cause confusion. This change ensures clarity and proper tracking of ESG-related activities.
Original PR description
Before this commit, the description of `esg.activity.type` model is the same than the `activity.type` one defined model which could be confusing. This commit updates the description of `esg.activity.type` model to set Activity Type ESG to explicitly mention that model is used in ESG. Forward-Port-Of: odoo/enterprise#112680
A validation error during offer generation was caused by a recent requirement for a 'version_id' field. This update ensures the system correctly processes offer generation by automatically providing the necessary 'version_id' information. This resolves a potential issue preventing successful offer creation.
Original PR description
-**ISSUE**: Since the "version_id" field in hr.payslip.worked.days model became a required field, the validation error exists. -**FIX**: "version_id" is passed inside the salary simulation payslip.
This update corrects a duplicate shortcut issue within the Assets view in the Odoo Enterprise software. The ALT + P shortcut, previously causing a conflict, has been resolved. This ensures users can consistently utilize the intended functionality for managing assets.
Original PR description
This PR (https://github.com/odoo/enterprise/pull/109022) fixed the duplicate ALT + P shortcut in the Assets view. A new one was added in 19.2. opw-5948523
This update resolves an issue where saving a report with an empty XML format in Web Studio would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience. This improves report creation stability.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#112111 Forward-Port-Of: odoo/enterprise#88613
A recent update caused partner names in the approval request report to overflow, making the report visually unclear. This fix addresses this issue by limiting the field width for partner names in the report, ensuring all data is displayed correctly. This improves the report's readability and accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update resolves an issue where removing an EPD line in the bank rec widget incorrectly removed associated invoice lines with tax. Now, only the EPD line and its corresponding tax line are properly removed, ensuring accurate bank reconciliation reporting. This improves data integrity and reduces potential reporting errors.
Original PR description
When removing an EPD line in the bank rec widget, if the invoice line added to the statement line contained a tax, the invoice line was removed aswell. Now, only the EPD line and its tax line are removed. no-task Forward-Port-Of: odoo/enterprise#110669 Forward-Port-Of: odoo/enterprise#110514