Friday, March 27, 2026
45 changes · 19.0
Resolved issues and error corrections
Custom website snippets based on product categories now display their dynamic category content correctly in the preview dialog. This helps website editors recognize and reuse saved category snippets with confidence before adding them to a page.
Original PR description
Commit 00cf9375b356b2316e24d97234474685e3fb7f94 added the new dynamic snippet for category of product, with a specific interaction. Commit 534a42029d757935788220549aabb8914302a4f3 shows dynamic content of dynamic snippet in snippets preview dialog, but `DynamicSnippetCategory` was missed (in forward port). This commit includes the interaction to load the dynamic content of "Category" dynamic snippet in the snippets preview dialog. Steps to reproduce: - Open website builder - Add a dynamic snippet `s_dynamic_snippet_category_list` - Save the snippet as a custom snippet - Click on "Custom" snippet category - Bug: The preview for the custom snippet does not have the dynamic part task-5427353
This fixes locked Knowledge content so links respect the open-in-new-tab choice set during editing. Users will get the expected navigation behavior instead of links unexpectedly opening in a new tab.
Original PR description
Problem: Links configured to open in the current tab still open in a new tab when content is locked in Knowledge. Cause: When rendering content in `HtmlViewer`, we always force the link `target` to `_blank` and `rel` to `noreferrer`, even if different values were configured during editing. Solution: Preserve the values configured during editing instead of overriding them. Steps to reproduce: - Knowledge. - Add a link. - Disable the option to open the link in a new tab. - Lock the content. - Click on the link. - The link still opens in a new tab even though the option is disabled. opw-5991647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice PDFs now align information for sections whose composition is hidden with the rest of the invoice lines. This makes generated invoices look cleaner and more professional for customers.
Original PR description
Issue: Information displayed about sections with hidden composition are not align with the other lines. Steps to reproduce: - Create an invoice - Add a product - Add a section with any product. - Hide the composition of the section (with the 3 dots on the right) - Download the invoice PDF Current behavior: - Information on the hidden section compo are not align with other lines opw-6017276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice PDFs now keep subtotal values under the right columns when section details are hidden. This prevents confusing layouts where quantities or amounts appear shifted, making printed invoices easier for customers and staff to read.
Original PR description
**Problem:** In invoice PDF reports, when a section has Hide Composition enabled having a product inside, the description cell reserves too many columns (that are not available like quantity, unit…
**Problem:** In invoice PDF reports, when a section has Hide Composition enabled having a product inside, the description cell reserves too many columns (that are not available like quantity, unit price) while the quantity is still rendered as (1.00 Units), and unit price/discount/tax cells are conditionally omitted for section/subsection display types. This adds the extra table cells (quantity "1.00 units", total amount) after the first few reserved columns, this shifts the quantity/amount column a few positions to the right resulting in inconsistency mapping between the values and the name of the column. Before: <img width="1622" height="867" alt="2026-03-25_10-56" src="https://github.com/user-attachments/assets/57d6857a-7763-48d3-8131-fdc4e37a6704" /> After: <img width="1628" height="771" alt="2026-03-25_13-55" src="https://github.com/user-attachments/assets/d9df6cbe-3c23-4874-b50f-6797ef644c03" /> **Steps to reproduce:** 1- Create a customer invoice 2- Add a section. 3- Add products under the section with quantity and price 4- Enable hide composition on the section 5- Confirm and print the invoice PDF 6- Observe the section subtotal rows shifted by one column **Cause:** In grouped rendering, line_colspan for non-product rows still reserves Quantity,Unit Price columns, while hide_details also renders a dedicated quantity cell (1.00 Units). This makes the row consume extra columns and breaks alignment. **Solution:** For grouped rows in hide_details mode, We need to render the description cell with a minimal colspan (1) and explicitly keep the remaining column slots stable: keep Quantity cell (1.00 units), Unit Price, Discount, taxes as an empty placeholder cells if not available. --- opw-6030372
The forecast report now identifies the Manufacturing Order as the source of availability when products are made to order from a Sales Order. This gives users clearer traceability and avoids confusion caused by showing the Sales Order instead of the production document.
Original PR description
Issue: ------------------------------------------------ When a Manufacturing Order is created via an MTO flow from a Sales Order, the Forecast Report was displaying the Sales Order in the "Available"…
Issue: ------------------------------------------------ When a Manufacturing Order is created via an MTO flow from a Sales Order, the Forecast Report was displaying the Sales Order in the "Available" section instead of the Manufacturing Order. Steps to Reproduce: ------------------------------------------------ 1. Install `sale_mrp` and `sale_management`. 2. Create a storable product with BOM and MTO route 3. Confirm a Sales Order for the product 4. Open the Forecast Report 5. Observe incorrect reference in "Available" section Cause: ------------------------------------------------ Before v19.0, finished moves of an MO created via MTO did not carry a `sale_line_id`, but now it will propagate to the MO finished moves. Because `_get_source_document()` is overridden in multiple modules, the `sale_stock` implementation now matches first and returns the Sales Order, preventing the MRP logic from returning the Manufacturing Order. With this commit: ------------------------------------------------ This fix ensures that the Manufacturing Order is shown as the source document providing correct traceability and aligning the behaviour with the purchase MTO flows. task-5941986
Fixed an issue where multi-line product short descriptions could appear in the wrong order in the website shopping cart. This improves the clarity of cart information for customers, though some extra details like rental dates or variant notes may not always be shown first.
Original PR description
Issue: --- Due to this issue, the description following lines are inversed. Steps to reproduce: --- 1- In product page in backend, add a multiline "Short Description" to a product. 2- Navigate to website and add the product to the cart. 3- Open the cart. Outcome: The description after lines are shown inversed. Cause: --- This is introduced by https://github.com/odoo/odoo/pull/223433. It was done to ensure some information such as rental date and variant description are shown at the beginning. However, it didn't consider that the product description itself might have multilines. Fix: --- There is no clean way to reliably extract structured information from the computed name. To avoid reversing the product description lines, we no longer reverse the description. As a limitation, variant descriptions and rental dates may no longer always appear first. opw-5976614
The update prevents the system from crashing when an installed module does not include a manifest file. This makes optional asset preparation more resilient and helps keep the application running smoothly even when some modules have incomplete metadata.
Original PR description
This commit avoids a crash when a module doesn't provide a manifest (cf. Industry). Pregenerating lazy loaded bundles is a "best effort" detection and should be resilient so, not a big deal if some aren't properly found.
Changing a partner’s country now automatically keeps their identification type aligned with that country. This prevents invalid country and ID type combinations, helping maintain cleaner localization data for Latin American contacts.
Original PR description
**PROBLEM** PR: https://github.com/odoo/odoo/pull/179078 Removed _onchange_country_id() which was used to set the identification type according to the country of the partner. This PR reintroduce it, so id type and country remains consistent. **STEP TO REPRODUCE** 1. install l10n_ar and l10n_co. 2. create a new partner. 3. set its country to Argentina, and select an argentinian id type. 4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible. opw-5801824 Forward-Port-Of: odoo/odoo#248585
Invoice PDFs using the folder document layout now show page numbers correctly on a single line, such as "Page 1/1". This prevents confusing or unprofessional page numbering when Montserrat is selected as the document font.
Original PR description
Steps:
- Install accountant
- Configure Document layout
- Set folder layout
- Set Montserrat text font
- Try to print an invoice pdf it displays
```
Page 1/
1
```
This commit use text-nowrap to displays page numbers in one line to have
```
Page 1/1
```
opw-6006148A test in the Sales Timesheet area was adjusted so it no longer fails when the Invoicing module is not automatically installed. This helps keep quality checks stable across different installation setups without changing user-facing behavior.
Original PR description
__ ## Error description When the test runs following a specific configuration, the field `invoicing_switch_threshold` isn't found. However, we have to keep this field in the test because we can't replicate the issue the test checks without it. ## Origin of the issue This field belongs to the `account_accountant` (Invoicing) module. However, `sale_timesheet` doesn't have a dependency on this module: there's only an auto install for `account_accountant` when installing the module from the front-end. Therefore, if we launch the test without the `account_accountant` auto install, it will fail. __ original commit: https://github.com/odoo/odoo/pull/250946/changes/52a9841c754466c2df65c75d13c9ed2ae86a51ce Forward-Port-Of: odoo/odoo#254506 Forward-Port-Of: odoo/odoo#252772
Sales teams can now adjust taxes on loyalty reward lines after a sales order is confirmed. This fixes a restriction that blocked valid tax corrections once the order was no longer in draft, reducing manual workarounds and improving invoice accuracy.
Original PR description
Issue: --- Due to this issue, the tax on reward SOL cannot be edited. Cause: --- This is introduced in #172110 to prevent users from editing taxes on reward lines because confirming the order would recompute the tax. We can make it editable on confirmed SO as the tax wouldn't recomputed on reward lines later. opw-5918435 Forward-Port-Of: odoo/odoo#255644 Forward-Port-Of: odoo/odoo#255102
Automated tests now prepare a key messaging-related asset in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary processing and helps keep test execution more efficient without changing user-facing behavior.
Original PR description
This commit sets the `bus.websocket_worker_assets` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +900 times with a db "all"). Forward-Port-Of: odoo/odoo#255843
The shop page now respects the setting to hide product filters when viewed on mobile. This prevents customers from seeing filter options that site managers intentionally disabled, keeping the mobile shopping experience consistent with the configured storefront.
Original PR description
Steps to reproduce: 1) Go to the shop page 2) Open the editor and select the 'hide' option for filters 3) Switch to mobile view and click on the 'Filters' button Issue: - Filters are still displayed in mobile view even when the 'hide' option is selected in the editor. Cause: - The attribute filters template is always rendered in mobile view without checking the selected visibility option. Fix: - Add a condition to the `t-call` of the filters template so it is only rendered when an option other than 'hide' is selected. opw-5982147 Forward-Port-Of: odoo/odoo#255997
Users can now replace an uploaded file in the link popover without first clearing the existing link. This removes an unnecessary extra step and makes editing file links smoother and less confusing.
Original PR description
Specification: - When a user uploads a file in the link popover, user can not re-upload another file without manually removing previous URL. <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/9e67535a-22a1-4d41-808d-a91d07593251" /> <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/92a33d8c-a325-4979-9956-42e81b369bd7" /> After this commit: - This commit allows user to re-upload a file without removing previously generated URL first. - TL;DR : upload button won't disappear. task-5470111 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247552
This fixes an issue where automated browser tests could fail if older Chrome versions did not create a debug log file. The change makes the test infrastructure more tolerant of that missing file, improving reliability without affecting normal user workflows.
Original PR description
Follow up to #255054 [Apparently][] on old versions of chrome `chrome_debug.log` may not exist if the verbosity is not at least 1 (or chrome otherwise has had things to write to the log). Thus handle the possibility of the file being missing instead of assuming it's present just because we've told chrome to generate one. [Apparently]: https://github.com/odoo/odoo/pull/255054#pullrequestreview-4001460518 Forward-Port-Of: odoo/odoo#255846 Forward-Port-Of: odoo/odoo#255736
The overtime ruleset form now displays its title with the correct background and width. This keeps the page visually consistent with other Odoo forms in both light and dark modes.
Original PR description
**Before this commit** The title of an overtime ruleset record was shown with the incorrect background color and width. This is because the field was mistakenly wrapped in a `<header>` element. This…
**Before this commit** The title of an overtime ruleset record was shown with the incorrect background color and width. This is because the field was mistakenly wrapped in a `<header>` element. This makes the overtime ruleset titles look inconsistent compared to other forms in Odoo. Light mode <img width="1573" height="1027" alt="Screenshot 2026-03-25 at 12 48 14 PM" src="https://github.com/user-attachments/assets/602ae625-d80d-45c3-bc01-f928ab179b7a" /> Dark mode <img width="1570" height="1025" alt="Screenshot 2026-03-25 at 12 49 03 PM" src="https://github.com/user-attachments/assets/14b3a1ee-33c0-4c3e-b66f-79d450baa6ac" /> **After this commit** We remove the `<header>` element that wraps the title so that its background and width match the expected styling for forms in Odoo. Light mode <img width="1575" height="1027" alt="Screenshot 2026-03-25 at 2 19 35 PM" src="https://github.com/user-attachments/assets/ee2dd6bd-3ab2-487c-8826-c2334f5e1258" /> Dark mode <img width="1573" height="1024" alt="Screenshot 2026-03-25 at 2 19 09 PM" src="https://github.com/user-attachments/assets/cb59bdeb-f599-4553-acc1-991bf923756d" /> opw-6069360
The customer rating form in Project now shows the comment information only once. This avoids confusion for users reviewing customer feedback and makes the rating record cleaner to read.
Original PR description
**Steps to reproduce:** - Enable the customer rating from project's setting. - Go to project > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in project's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/odoo#237687
A sales test was moved to the correct Sales Management area because it depended on a field not available in the base Sales app. This prevents automated validation failures and helps keep releases stable without changing customer-facing behavior.
Original PR description
Issue: --- `is_optional` does not exist in `sale` module, leading to runbot issue. The test needs to be moved to `sale_management`. runbot-242127
This update gives Point of Sale test processes more time to finish saving data before a page refresh. It helps reduce false test failures and improves confidence in automated quality checks, with no expected impact on day-to-day users.
Original PR description
In some tests, we use refresh which will refresh the page after letting the indexedDB finish its transactions. In some cases, the transactions take more time than expected. In this commit, we increase this timeout to avoid failures that could be caused by not letting the time to the db to finish its transactions. runbot-errors: 240911, 240912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253095
Invoice PDFs now keep section details aligned when a section's product composition is hidden. This improves the readability and professional appearance of customer invoices without changing invoice content or workflow.
Original PR description
Two fixes were r+ at the same time to correct the alignment Issue: Information displayed about sections with hidden composition are not align with the other lines. Steps to reproduce: - Create an invoice - Add a product - Add a section with any product. - Hide the composition of the section (with the 3 dots on the right) - Download the invoice PDF Current behavior: - Information on the hidden section compo are not align with other lines opw-6017276 opw-6030372 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices sent through Peppol will no longer create duplicate document records for the same PDF and XML attachments. The attachments are now synced only once at the intended step, keeping document lists cleaner and reducing confusion for users.
Original PR description
When sending an invoice via Peppol, the PDF and XML attachments are logged in the chatter. This automatically triggers a synchronization with the Documents app. However, the Peppol sending flow also includes a dedicated document linking step later in the process. This caused the same attachments to be registered as documents twice. This commit skips the document synchronization during the initial chatter logging step. The attachments will now only be synchronized once during the dedicated linking phase. Note: ec6e559 prevented duplicate attachments in the chatter with some cleanup code, but this cleanup code runs after the document has already been created and does not remove the document, resulting in duplicate documents, which this commit fixes. Task-6030468 Forward-Port-Of: odoo/odoo#256212 Forward-Port-Of: odoo/odoo#254893
Imported customer invoices will no longer reuse the original XML file when they are exported again. This ensures any later invoice changes are reflected in the generated electronic document, while supplier-side imports keep the existing behavior.
Original PR description
Problem --------- Currently, when importing a move, `ubl_cii_xml_file` gets set with said XML. This XML is then re-used during the export rather that regenerate a new XML each time. This is fine for customer bills as those are not meant to be modified. This is not the case of customer invoices. Client may import an invoice XML and later update that invoice. In such a case, we want to regenerate the XML and not reuse the imported version. Solution --------- Only set `ubl_cii_xml_file` for purchase move during the import. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256052
Users can now save a report after clearing its XML source without triggering a system error. The editor now skips XML processing when there is no source content, making report editing in Studio more reliable.
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#255930 Forward-Port-Of: odoo/odoo#255316
This fixes a UAE localization upgrade issue that could occur if the United Arab Emirates country name had been customized. The module now uses a stable country reference, so upgrades remain reliable regardless of name changes or translations.
Original PR description
### Steps to reproduce ------------------ - Install `l10n_ae` module. - Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE"). - Upgrade the `l10n_ae`…
### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.
### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:
```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```
### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.
### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.
Using XMLIDs ensures consistent resolution regardless of name changes or translations.
opw-6015302
upg-3950261
tbg-2492
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#255993The live chat test environment now prepares an external asset package in advance instead of rebuilding it repeatedly during test runs. This reduces unnecessary processing during internal testing and helps keep development validation faster and more reliable, with no direct change for end users.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#256149 Forward-Port-Of: odoo/odoo#255847
Validating a delivery linked to a confirmed sales order with no order lines no longer causes an error. The system now uses a safe default ordering value when it needs to add a sales line, helping users complete inventory deliveries without interruption.
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#254578 Forward-Port-Of: odoo/odoo#239030
This update fixes a minor issue where the SEPA payment file version was incorrectly displayed as empty in the Odoo interface. The fix ensures the correct 'PAIN 09' version is generated, aligning with data stored in the database. This improves the accuracy of payment file generation.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update resolves an error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all_time' when no interval is specified, preventing a KeyError and maintaining smooth expense card functionality. This improves the user experience and prevents data inconsistencies.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287
This update resolves an issue in the Odoo payroll testing process where records weren't consistently available, leading to test failures. The fix ensures the test uses defined analytic accounts and plans directly, improving the reliability and stability of the payroll testing environment. This enhances the accuracy of payroll calculations.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151
This update fixes a problem where users with limited accounting access would encounter errors when validating invoices due to restricted access to audit reports. The change ensures bill validation functions correctly without requiring additional user permissions, improving usability for standard users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259
This update resolves a potential error where the 'signRequestToken' value wasn't consistently being sent to the signing process. The change ensures that the correct token is always transmitted, improving the reliability of the digital signature functionality. This prevents potential issues with users initiating or completing the signing process.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181This update resolves an issue caused by changes in how Wise's API returns Swift code information. The system now consistently handles both 'swift_code' and 'SwiftCode' formats, preventing errors and ensuring accurate direct deposit processing. This improves stability and reliability of the direct deposit feature.
Original PR description
Internally, Wise has changed their return value of their API to sometimes return `swift_code` and other times return `SwiftCode` depending on the create time of the recipient account. If the account is older than a few months it will use `SwiftCode` as the return value of GET /v2/accounts when they are created with type `swift_code` in the POST. As such, to be defensive this code handles both cases to not make any assumptions in case users have old or new accounts. This stops a traceback where the system doesn't think it's a swift account and tries to access abartn even though it doesn't exists. task-6070033
This update corrects a problem with the demo data used for the l10n_ch_hr_payroll module. Specifically, an incorrect reference was removed, ensuring the demo data accurately reflects the insurance group setup. This ensures consistent and reliable demo data for testing and training.
Original PR description
This commit removes an unnecessary record and fix wrong reference to the insurance line of the insurance group in the demo data of the l10n_ch_hr_payroll module. task-6070942
This update resolves an issue preventing superuser administrators from deleting obsolete work entry types within the Odoo payroll module. This change improves administrative efficiency by allowing for cleaner management of payroll configurations. It ensures that payroll data remains accurate and up-to-date.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document management system related to how attachments were handled. This ensures documents can be reliably opened and used after being renamed, improving user workflow.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110001 Forward-Port-Of: odoo/enterprise#105602
This update fixes a problem where the helpdesk tour would sometimes fail to correctly create new tickets. The fix ensures the tour waits for the kanban view to fully load before attempting to click the 'New' button, preventing errors and improving tour reliability. This ensures a smoother experience for users creating tickets through the tour.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update fixes a display issue in the external value pop-up, ensuring it uses the correct decimal separator based on the user's language settings. Previously, the pop-up always displayed numbers with a dot, regardless of the user's locale. This change ensures a more accurate and user-friendly experience for international users.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#111997 Forward-Port-Of: odoo/enterprise#109948
This update corrects a technical issue where the system incorrectly handled VAT numbers for certain countries like Switzerland. The change ensures that VAT numbers, which can be longer than 18 characters, are properly transmitted to FedEx, preventing delivery errors. This ensures accurate data submission and avoids potential shipping delays.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#111864 Forward-Port-Of: odoo/enterprise#109999
This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency and simplifies product management.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#111340
This update fixes an issue where long product names in the Master Production Schedule would cause other schedule columns to disappear. The fix wraps long product names within the display to ensure all schedule elements are visible, regardless of product name length. This improves usability and prevents data loss.
Original PR description
Problem: In the master production schedule, if a product on the schedule has a name that would extend to the right edge of the screen, all of the other colums for the schedule will be completely hidden. Solution: We will wrap the text in the <a> tag containing the product name. Steps to Replicate (Runbot v19): 1. Open the Master Production Schedule 2. Click the pencil on one of the products 3. Click into the product and change its name to be something very, very long 4. Navigate back to the MPS and notice that you cannot see the actual schedule elements, even if you scroll to the end. opw-6066088
This update resolves an issue where discounts weren't correctly applied in the self-order point-of-sale flow. The fix ensures that discount information is properly passed through the system, preventing errors and guaranteeing accurate discount calculations during self-order transactions. This improves the reliability of the POS system.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update resolves an issue where the Customer Ratings reporting form in Helpdesk displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving the user experience. This ensures consistent and accurate reporting on customer feedback.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update corrects a technical error related to international payment processing (ISO 20022). Specifically, it ensures QR-IBANs are correctly formatted within creditor accounts, aligning with industry standards and preventing potential payment rejections. This improves the reliability of international transactions.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank). Forward-Port-Of: odoo/enterprise#112301
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format in web_studio. The fix prevents the system from trying to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
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#112053 Forward-Port-Of: odoo/enterprise#88613
This update resolves a problem where Web Studio exports were incorrectly formatting property data. The fix ensures that property data is now exported in the correct XML format, improving the reliability and accuracy of exported configurations. This prevents potential errors when importing these configurations back into Odoo.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336