Daily updates from Odoo
Thursday, July 24, 2025
49 changes
19 changes
Resolved issues and error corrections
This change updates an internal purchase inventory test so it has the right access to product unit information. It prevents avoidable test failures and helps keep future purchase and replenishment updates reliable.
Original PR description
The `product_uom_id` field was causing test failures in `test_reordering_rule.py` because it was not present in the `product.supplierinfo` form view . This commit adds the group permission `uom.group_uom` to the user who is running the test, to ensure that the `product_uom_id` field is available and preventing the test failure. build_error-111983 Forward-Port-Of: odoo/odoo#218830 Forward-Port-Of: odoo/odoo#206688
Electronic invoice exports now include product barcode information in the standard item identification field, matching what the system already reads during imports. This helps trading partners and integrations receive more complete product data and reduces mismatches between imported and exported e-invoices.
Original PR description
[FIX] account_edi_ubl_cii: export product barcode too Currently we use the `Item/StandardItemIdentification` as the barcode when importing a product. But we do not export the same information. In 18.0+ the `Item/StandardItemIdentification` was added to the UBL XML (for exporting) in commit 72e312815f372de88388c47c612bb5f44b4d8b4e. But there it is only used in `l10n_co_dian`. After this commit we export and fill the tag "by default". task-4941855 Forward-Port-Of: odoo/odoo#219391 Forward-Port-Of: odoo/odoo#218779
This fix stops content history records from being written to directly and avoids copying history data during duplication. This helps prevent errors when records are copied and keeps editor history managed only through the intended process.
Original PR description
This commit prevent direct write to history, also, removes it from copy_data as it would fail anyway when trying to write the history Forward-Port-Of: odoo/odoo#219182 Forward-Port-Of: odoo/odoo#217167
The IoT Box homepage now points to the correct settings page for configuring remote debugging. This restores the ability to set up ngrok-based remote access from the homepage, avoiding a broken setup path for support and troubleshooting.
Original PR description
During the forward port, the URLs for ngrok in the homepage were not changed from `hw_posbox_homepage` to `iot_drivers`, meaning remote debug could not be configured from the IoT box homepage. This commit fixes the URLs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where Cloudflare Turnstile verification data could be saved into sales order notes when customers completed the optional extra checkout step. The checkout experience remains the same, but internal order notes stay clean and free of unnecessary captcha data.
Original PR description
Scenario:
- enable extra step in website ecommerce
- enable turnstile
- do the checkout process until after "extra step" step
- go check the sale order
Result: there is a big "turnstile_captcha: {1000 character hash}" that is
logged each time the customer filled the "extra step" step.
Cause:
turnstile if enabled is activated for all website_form and will add a
turnstile_captcha parameter.
For other website.form, the captcha is removed from the params when
calling:
request.env['ir.http']._verify_request_recaptcha_token('website_form')
but the custom route /website/form/shop.sale.order doesn't do that so
the captcha is logged in note.
Fix:
Recaptcha is already disabled on the extra_step with the class:
s_website_form_no_recaptcha, so it makes sense to just have the
same behavior for turnstile.
opw-4934132
Forward-Port-Of: odoo/odoo#219558
Forward-Port-Of: odoo/odoo#219269This update fixes inconsistencies in how Spanish taxes are linked to fiscal positions. It helps ensure the correct tax behavior is applied for Spanish localization scenarios, reducing accounting configuration errors.
Original PR description
In this [commit](https://github.com/odoo/odoo/commit/8b539c1f303f1b49916c29190c11dcf2cab57d2c) taxes were mapped with fiscal positions but some taxes had inconsistencies. This PR aims to fix that mapping inconsistencies for ES. TaskID:4951601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219578
The Contacts test setup now assigns a default country so automated nightly checks run reliably when only the Contacts app is installed. This prevents false test failures and helps keep release validation stable.
Original PR description
**PROBLEM** `test_vat_label_string` fail on nightly test **CAUSE** `self.env.user.company_id.country_id` is empty because: - we don't load demo data by default starting from 18.3 - we installed only one app, so the module that sets the default company country (there must be one since runbot non-nightly tests passed) isn't installed. **FIX** set the country to US in the test, so we have a country to work with. see https://runbot.odoo.com/odoo/error/229770 Forward-Port-Of: odoo/odoo#218351
This fixes an issue where Odoo could show an additional error while recording a failed company image download in the mail plugin. The original download may still fail, but the system now logs it properly without causing a traceback.
Original PR description
When logging a failed image download for a new company,
A traceback will appear.
[1]- https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L360
https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L342-L344
here, ``new_company_info`` is dictionary, but at [1] the code incorrectly accesses
``name`` as an attribute.
So, it will lead to the below traceback.
Traceback:
```
File "/home/odoo/src/odoo/addons/mail_plugin/controllers/mail_plugin.py", line 359, in _create_company_from_iap
_logger.warning('Download of image for new company %s failed, error %s', new_company_info.name, e)
AttributeError: 'dict' object has no attribute 'name'
```
sentry-6554480256
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206771This update fixes an internal test issue in the Point of Sale loyalty area so that a promotion tax test can be safely retried without failing for the wrong reason. It helps maintain confidence in automated checks and reduces noise from misleading test failures, with no direct change for end users.
Original PR description
Tests in this file are all sorts of fucked up in ways which break retrying, but this one is problematic because it *also* fails on the reg, with a misleading error as on retrying the `setUp` fails because it tries to update `product_b`, which this test overrode (so the record is rolled back, and trying to update it fails with a `MissingError`). The error is completely unforced as the test just wants to have two products in the DB with different taxes, we don't even need local variables. runbot-226343 Forward-Port-Of: odoo/odoo#220085
Saving a blog post after removing all content now shows a clear validation message instead of triggering a backend error. This helps users understand that the content is empty and prevents noisy system errors during normal editing.
Original PR description
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a…
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a new blog. - Click to open the newly created blog. - Remove any existing content (e.g., placeholder text like 'Start Typing...'). - Type `/column` and click on the 2-column option. - Click on the columns that appear — you’ll see a delete icon. - Delete all the columns, click Save and check the terminal. Error: `ParserError: Document is empty` The error occurs when all content in the blog is deleted, resulting in empty HTML content. During saving, `html.fromstring(lang_value)` [1] is called with `lang_value` being effectively empty, which leads to a `ParserError`. [1] - https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/web_editor/models/ir_ui_view.py#L126 This commit fixes the problem by catching the `ParserError` and raising a `ValidationError` when the HTML content is empty. sentry-5081806749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216790
Vietnam localization can now generate VietQR codes when the city field is empty but a valid state such as Ha Noi or Hai Phong is provided. This prevents unnecessary payment QR errors for businesses using Vietnamese bank details.
Original PR description
* Problem: Using Vietnam localisation, leave city empty and just input state_id as Hà Nội or Hải Phòng, try to use vietqr code -> Raise error missing city * Solution: Just like https://github.com/odoo/odoo/pull/218984 we should check for state too although according to VietQR document, merchant city is not required see (https://vietqr.net/portal-service/download/documents/QR_Format_T&C_v1.0_VN_092021.pdf and search for term 'Merchant City') 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#219873 Forward-Port-Of: odoo/odoo#219566
This fixes missing partner information on journal items created by the withholding tax on payment process. It helps accounting teams keep payment-related tax entries complete and easier to reconcile or audit.
Original PR description
Fixes an issue where the partner is missing from the journal items generated by the withholding tax on payment system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218268
This fixes a display issue where subscription product prices could appear twice on the shop page. Customers now see a cleaner, more accurate product listing, reducing confusion during browsing.
Original PR description
This PR fixes an issue where the product price was displayed twice on the `/shop` page of a product with a subscription type. task-4954676 Issue: <img width="618" height="271" alt="image" src="https://github.com/user-attachments/assets/e00adabf-ecfb-4424-8c2a-3b7413cbeee3" />
Odoo Sign now safely handles signature requests that are not in the shared state by leaving their sharing link empty. This prevents error messages when users inspect request data or when integrations retrieve signature requests.
Original PR description
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests…
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests that are in the 'shared' state. However this compute method fails for requests not in the 'shared' state leading to a traceback error. This commit fixes it by setting the default as False for the sign.request records that do not have state='shared' so the traceback error is handled. This can be reproduced in v17 and above by: 1. Open any sign.request record that isn't in the shared state 2. Enable Developer Mode 3. Using the debug icon, click on view record data The traceback will be visible here which mentions that the compute method failed to assign It can also be re-produced by using an xml-rpc / json-rpc ORM call to search_read the sign.request records that does not have state = 'shared' ### Before https://github.com/user-attachments/assets/24c07f2a-2398-44b4-8969-30abb576876a ### After https://github.com/user-attachments/assets/e92b1212-5405-4b98-ba41-c81b2ac547d7 [opw-4864159](https://www.odoo.com/odoo/project/49/tasks/4864159) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90576
This fix prevents access errors when users open AI-related views that display tools. It matters because non-system users can use the relevant screens without being blocked by unnecessary permission checks.
Original PR description
The changes are proposed because only systems users have read access to the ai.tool model. Runbot error: 182051
This update fixes an automated test for Mexican point-of-sale invoicing so it matches the expected invoice XML structure. It ignores a variable identifier that is not important to the business scenario, helping prevent false build failures.
Original PR description
Fix the test file for pos order then invoice request to match the expected XML structure, by ignoring the `UUID` attribute in the `TimbreFiscalDigital` element because it is not relevant for the test and can cause issues with the test validation. build_error https://runbot.odoo.com/runbot/build/83409879 Forward-Port-Of: odoo/enterprise#88756
Point of Sale users are now prevented from validating a customer deposit with a zero amount. Instead of an error screen, the system displays a clear warning, helping cashiers avoid disruption during checkout.
Original PR description
Steps to reproduce: =================== - From the POS UI, select a customer - Select Deposit Money - Try to deposit `0` amount by clicking Validate button Issue: ====== A traceback is raised when attempting to validate a deposit with zero amount. Cause: ====== The system does not check for zero-amount orders when creating a deposit payment line. Fix: ==== Add a dialog warning when the deposit amount is zero to prevent further processing. Task: 4862811 Forward-Port-Of: odoo/enterprise#90739 Forward-Port-Of: odoo/enterprise#87709
Internal users can now create or update Colombian contacts with a NIT tax ID without seeing an access denied message. The system can perform the required DIAN certificate check in the background, reducing disruption for everyday contact management.
Original PR description
When entering a Colombian Tax ID (NIT), the onchange checks `company.l10n_co_dian_certificate_ids`, which reads `certificate.certificate` records , resulting in an “Access Denied” popup. This changes Wrap the certificate lookup in `company.sudo()` so that the NIT VAT‐onchange can fetch the DIAN certificate records. Steps to Reproduce: 1. Install the l10n_co_dian module and switch to CO company 2. Create a user with only the “Internal User” (base.group_user) group—do not grant Administration/Settings. 3. Log in as that non-admin user. 4. Go to Contacts -> Create. 5. Set Country = Colombia and Identification Type = NIT. 6. Enter any VAT (NIT) number and leave the field. 7. “Access Denied” error for certificate.certificate. opw-4936604 Forward-Port-Of: odoo/enterprise#90176
Sharing a folder shortcut from the breadcrumb menu no longer causes a server error. This keeps document sharing reliable for users working with shortcut folders.
Original PR description
Reproduce: 1/ Create a shortcut of a folder 2/ Select it in the search panel 3/ Opening "Share" via the breadcrumb's cog menu triggers a server error. In d3e6a8df, we incorrectly changed this one2many reference from `[0]` to `.id`. Task-4762955
6 changes
Resolved issues and error corrections
Brazilian point-of-sale orders with a total cost of zero now include the required payment information when sent to Avalara. This prevents invoice submission failures caused by missing payment details, improving reliability for free or fully discounted sales.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094 Forward-Port-Of: odoo/enterprise#90724
This fixes an error that could appear when users or integrations viewed signature requests that were not in the shared state. Those requests now safely show no share link instead of causing a traceback, improving reliability for document-signing workflows and API access.
Original PR description
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests…
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests that are in the 'shared' state. However this compute method fails for requests not in the 'shared' state leading to a traceback error. This commit fixes it by setting the default as False for the sign.request records that do not have state='shared' so the traceback error is handled. This can be reproduced in v17 and above by: 1. Open any sign.request record that isn't in the shared state 2. Enable Developer Mode 3. Using the debug icon, click on view record data The traceback will be visible here which mentions that the compute method failed to assign It can also be re-produced by using an xml-rpc / json-rpc ORM call to search_read the sign.request records that does not have state = 'shared' ### Before https://github.com/user-attachments/assets/24c07f2a-2398-44b4-8969-30abb576876a ### After https://github.com/user-attachments/assets/e92b1212-5405-4b98-ba41-c81b2ac547d7 [opw-4864159](https://www.odoo.com/odoo/project/49/tasks/4864159) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90576
The AI feature now correctly shows the resources banner when no supporting documents are provided. This prevents unnecessary processing and gives users clearer feedback sooner.
Original PR description
Fixed displaying resources banner if no docs provided to stop before running the computation query.
This update moves Point of Sale configuration tests into the Enterprise POS module where the related functionality belongs. It helps keep automated checks aligned with the correct product area, reducing build issues without changing user-facing behavior.
Original PR description
move tests for POS configuration settings from point_of_sale to pos_enterprise refer to this commit :https://github.com/odoo/odoo/pull/215611/commits/0074d743451834424706608fc76f32b0df9c5f1c build_error-227602 Forward-Port-Of: odoo/enterprise#88742
This update fixes an automated test for Mexican point-of-sale invoicing so it no longer fails because of an irrelevant generated identifier. It helps keep validation reliable without changing how users create or process invoices.
Original PR description
Fix the test file for pos order then invoice request to match the expected XML structure, by ignoring the `UUID` attribute in the `TimbreFiscalDigital` element because it is not relevant for the test and can cause issues with the test validation. build_error https://runbot.odoo.com/runbot/build/83409879 Forward-Port-Of: odoo/enterprise#88756
This fix prevents regular internal users from seeing an access denied message when entering a Colombian company tax ID on a contact. It allows the tax ID check to read the needed DIAN certificate information in the background, improving the contact creation flow without changing user permissions.
Original PR description
When entering a Colombian Tax ID (NIT), the onchange checks `company.l10n_co_dian_certificate_ids`, which reads `certificate.certificate` records , resulting in an “Access Denied” popup. This changes Wrap the certificate lookup in `company.sudo()` so that the NIT VAT‐onchange can fetch the DIAN certificate records. Steps to Reproduce: 1. Install the l10n_co_dian module and switch to CO company 2. Create a user with only the “Internal User” (base.group_user) group—do not grant Administration/Settings. 3. Log in as that non-admin user. 4. Go to Contacts -> Create. 5. Set Country = Colombia and Identification Type = NIT. 6. Enter any VAT (NIT) number and leave the field. 7. “Access Denied” error for certificate.certificate. opw-4936604 Forward-Port-Of: odoo/enterprise#90176
4 changes
Resolved issues and error corrections
A small internal fix makes the web editor available consistently across automated tours. This helps reduce test issues and supports more reliable validation of Studio-related behavior without changing day-to-day user workflows.
Original PR description
This commit moves the patch of editor into html_editor to expose the editor instance globally for all the tours. Community PR: https://github.com/odoo/odoo/pull/212032 Forward-Port-Of: odoo/enterprise#90764
The AI assistant no longer sends the latest user question twice when building conversation context. This helps produce cleaner, more accurate AI responses and avoids unnecessary processing.
Original PR description
Prior to this commit, we send messages to the llm like the following:
```
[
{'content': Markup('<p>first question</p>'), 'role': 'user'},
{'content': Markup("<p>Sure, I'm here to help. What's your first question?</p>"), 'role': 'assistant'},
{'content': Markup('<p>second question</p>'), 'role': 'user'},
{'role': 'system', 'content': "You are a RAG assistant.\n\nToday's date to be used: 2025-07-18"},
{'role': 'user', 'content': 'second question'}
]
```
We're actually duplicating the user's prompt and this is because of the retrieval of the chat history. Before calling generate_response, we post the user's message. Therefore, he's message is already recorded in the db. We should then skip the most recent message to assemble the chat history since its just the same to the prompt.
Forward-Port-Of: odoo/enterprise#90665
Forward-Port-Of: odoo/enterprise#90502The automated Field Service stock test was adjusted to match the updated task list behavior. This keeps quality checks aligned with the product and helps prevent false test failures after related platform changes.
Original PR description
This commit adapts the `industry_fsm_stock_test_tour` tour according to the changes made in community. That is, now the main list view of tasks will now be readonly as before instead of editable with a open form view button. Forward-Port-Of: odoo/enterprise#89585
Point of Sale now stops zero-amount customer deposits before they are processed and shows a warning instead. This prevents an unexpected error screen and helps cashiers continue their workflow smoothly.
Original PR description
Steps to reproduce: =================== - From the POS UI, select a customer - Select Deposit Money - Try to deposit `0` amount by clicking Validate button Issue: ====== A traceback is raised when attempting to validate a deposit with zero amount. Cause: ====== The system does not check for zero-amount orders when creating a deposit payment line. Fix: ==== Add a dialog warning when the deposit amount is zero to prevent further processing. Task: 4862811 Forward-Port-Of: odoo/enterprise#90739 Forward-Port-Of: odoo/enterprise#87709
20 changes
Resolved issues and error corrections
The website editor toolbar has been adjusted so it does not leave unwanted blank space below the page footer when hidden. This keeps edited pages visually tidy and prevents confusing extra scrolling or empty space for users.
Original PR description
Description of the issue/feature this PR addresses: - Commit [189a7c96](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e#diff-de0d67e89972b45b101a9c4b04f316824314b0d69aba6208528586f1edb4f01cL25-L40) moved scrollbar from `#wrapwrap` element to `<body>`, caused the space below the footer visible for the floating toolbar. Current behavior before PR: - Space below the footer was always visible, even when the toolbar was hidden. Desired behavior after PR is merged: - `top: 0;` is applied on `.oe-toolbar` to ensure it stays out of the layout flow. - This prevents unnecessary layout space and ensures correct toolbar positioning. task-4652202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable automated test for live chat session navigation by removing an unnecessary step that sometimes failed. The change helps keep quality checks stable without changing how users experience live chat.
Original PR description
The `test_session_history_navigation_back_and_forth` test sometimes fail. The test ensures we can navigate between the session list view and discuss using the browser history. To do so, the tour first accesses the list view using the command palette. However, command palette sometimes doesn't open. The command palette part of the tour is useless as the view can directly be accessed by passing the correct url to the `start_tour` function. This commit removes the command palette part of the tour thus fixing the issue. fixes runbot-108129 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an internal website test more reliable by waiting for an image to finish loading before checking its size. This helps prevent occasional false test failures, supporting smoother maintenance and release validation without changing customer-facing behavior.
Original PR description
The goal of this commit is to avoid potential undeterminism that could occur in the `drop_404_ir_attachment_url` test (introduced by [this commit]). Before this commit, an error was thrown if the image was not loaded at the time the test checks the `naturalWidth` and `naturalHeight` property of the image. This could lead to undeterministic error as nothing ensures that the image is loaded at that time. To solve the problem this commit first waits for the image to be loaded before accessing the `naturalWidth` and `naturalHeight` property of the image. Side note: even if the source of the image is of type `data:` it is not directly loaded. [this commit]: https://github.com/odoo/odoo/commit/fbc6a697c1adf67ee8a90c49b0150d6ca170e081 task-4931144 Forward-Port-Of: odoo/odoo#217968
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
Original PR description
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
This fix prevents electronic invoices from including an item identification field when no product barcode exists. It helps avoid invalid or misleading invoice data and adds test coverage for direct invoice export scenarios.
Original PR description
In the refactored UBL (with `account_edi_ubl_cii.use_new_dict_to_xml_helpers`): Currently we may generate the `StandardItemIdentification` node even in case the `barcode` is not set on the product. The issue was introduced as a FW-port issue in commit f46c10f03e59e8aae98079fc57f5295a376f2761 (18.0). The problem is that the `schemeID` attribute is always set. task-None (original fix is task-4941855)
Companies in Greece and Ireland with valid VAT numbers will now correctly see the Intra-Community Valid checkbox for VIES verification. This fixes a country code mismatch so affected businesses can use VAT validation as expected.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784 Forward-Port-Of: odoo/odoo#201630
This fix ensures the image cropper closes when a user deletes the image being edited, preventing confusing leftover controls in the editor. It also makes the crop option reliably reopen after using or discarding image transformation tools, improving the image editing experience.
Original PR description
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper…
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper still visible. **Issue 2:** - Go to To-Do and insert an image. - Click on Image Transform, then on Image Crop — observe that Image Crop opens correctly. - Click the Discard button in the Image Crop UI. - Again select the image, click Image Transform, then Image Crop. - Notice that Image Crop no longer opens. ### Description of the issue/feature this PR addresses: - Pressing Backspace removes the image from the editor. - However, the cropper remains open, and focus returns to editable area, allowing to type with the cropper still visible. - Clicking Image Crop while Image Transform was active could destroy both due to async loadBundle() timing. On subsequent attempts, ImageCrop was added before ImageTransform was removed, causing Owl to destroy both in the same frame. ### Desired behavior after PR is merged: - When the image is removed, the associated cropper is also closed. - Clicking Image Crop button while Image Transform is active now works. task-4859869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an automated sales project test wait for the expected screen behavior before continuing. It reduces false test failures during installation without changing how business users create or manage sales order lines.
Original PR description
Steps to reproduce the issue: 1- install sale_project without demo data 2- as the test is not deterministic, adding step_delay may help reproducing it The test was failing because the tour was not waiting for the modal to close before trying to click on the created sale order line. so accoding to this line https://github.com/odoo/odoo/blob/18.0/addons/sale_project/models/sale_order_line.py#L63-L63 the New Sale order line have in it a default product which doesnt open a modal build_error-163102
Country names entered during contact imports are now matched even when users type them in all caps or other capitalization styles. This prevents valid country values like "ARMENIA" from being rejected, reducing import errors and manual cleanup.
Original PR description
**Current behavior:** When importing a res.country record, if specifying a `name` then the search performed expects it to exactly match a first-letter-only capitalized pattern. **Expected behavior:** Let arbitrary capitalization be used on the input name string. **Steps to reproduce:** 1. Create a sheet to import to `Contacts` (res.partner) * `name`: anything * `country_id`: "ARMENIA" 2. Load the sheet for import -> test -> can't resolve country name **Cause of the issue:** The `res.country` records' names follow a first-letter-capitalized pattern and we do an exact search on the strings. **Fix:** Take the user input search strings and do additional searches on transformations of them that may match the sought after records. opw-4780334 Forward-Port-Of: odoo/odoo#216870
The shipping weight entered on a stock transfer now remains saved after refreshing or reopening the record. This prevents confusion and helps warehouse teams rely on the displayed shipment weight.
Original PR description
The Shipping Weight field was editable in the transfer, but upon refresh or reopening, it reverted to its previous value. This issue is now resolved by setting the field as store=True. 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
Fixed an issue where a failed company image download could trigger an additional error while being logged. This helps ensure company creation through the mail plugin continues to report the original download problem cleanly instead of producing a confusing traceback.
Original PR description
When logging a failed image download for a new company,
A traceback will appear.
[1]- https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L360
https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L342-L344
here, ``new_company_info`` is dictionary, but at [1] the code incorrectly accesses
``name`` as an attribute.
So, it will lead to the below traceback.
Traceback:
```
File "/home/odoo/src/odoo/addons/mail_plugin/controllers/mail_plugin.py", line 359, in _create_company_from_iap
_logger.warning('Download of image for new company %s failed, error %s', new_company_info.name, e)
AttributeError: 'dict' object has no attribute 'name'
```
sentry-6554480256
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206771Saving a blog post after removing all content now shows a proper validation message instead of causing a system error. This prevents confusing backend errors and gives users clearer feedback when empty HTML content cannot be saved.
Original PR description
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a…
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a new blog. - Click to open the newly created blog. - Remove any existing content (e.g., placeholder text like 'Start Typing...'). - Type `/column` and click on the 2-column option. - Click on the columns that appear — you’ll see a delete icon. - Delete all the columns, click Save and check the terminal. Error: `ParserError: Document is empty` The error occurs when all content in the blog is deleted, resulting in empty HTML content. During saving, `html.fromstring(lang_value)` [1] is called with `lang_value` being effectively empty, which leads to a `ParserError`. [1] - https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/web_editor/models/ir_ui_view.py#L126 This commit fixes the problem by catching the `ParserError` and raising a `ValidationError` when the HTML content is empty. sentry-5081806749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216790
The Indian GST reporting module now creates the GSTR1 report with the required permissions during automated testing. This prevents permission-related failures and helps keep GST report validation reliable.
Original PR description
steps to reproduce: 1. Install l10n_in_reports module. 2. Run the test `TestReports.test_hsn_schema_change_gstr1_json`. this is required to avoid permission issues when creating the GSTR1 report in the test. build_error-223245 Forward-Port-Of: odoo/enterprise#90221 Forward-Port-Of: odoo/enterprise#89116
This fix prevents an error when users refresh or duplicate a browser tab while working with a sent Sign request. It makes the Sign page load more reliably by handling missing page context safely.
Original PR description
**Steps to reproduce:** 1. Install sign 2. Create a sign request and send it to someone 3. Now, either refresh the page or duplicate the page **Issue:** - Traceback Error ```UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onMounted: "Cannot read properties of undefined (reading '4')" ``` **Cause:** - requestItemStates is not defined here, which is passed by context https://github.com/odoo/enterprise/blob/ceebc915607b471ffb8e3bbde055c6816cc06b43/sign/static/src/backend_components/sign_request/sign_request_control_panel.js#L34 **Solution:** - Add a safe fallback if requestItemStates is not present backport a5a6718c3a2fba226ecd7ed3efdb32d06777b6ae opw-4949153
This fixes occasional failures in automated Studio report tests caused by unreliable scrolling checks. The change makes the tests wait more reliably, helping reduce false alarms in quality checks without changing user-facing features.
Original PR description
Linked tests: - `test_add_field_blank_report` - `test_field_placeholder` These tests contained scroll-related indeterminacies that caused them to fail from time to time. This was due to the fact that we were modifying the scroll and we used this code to make sure it was done: ```js await new Promise(requestAnimationFrame); ``` However, sometimes this wasn't enough, so we now use `waitUntil`, which is more robust https://runbot.odoo.com/odoo/runbot.build.error/181989 runbot-181989
Fixed the website helpdesk contact form so the description label is translated correctly when users submit tickets in another language. The description field is also hidden when it is the only field, avoiding duplicate or confusing information on new tickets.
Original PR description
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ##…
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ## Reproduction Steps 1. Go to the general settings. Add a language where the term "description" differs from the english word (for example, Spanish). Do the same for the website settings. 2. Go to the website app. Scroll down and change the language. Then, click on the translated "contact us" tab. Fill the form and send the ticket. 3. Go to the helpdesk app and open the ticket you just created. ### Expected behavior The description field shouldn't show, as it appears in the description page. The field should only show if there are additional fields on the "contact us" page. ### Unexpected behavior The description field shows, untranslated. ## Origin of the issue In the ticket code, the field.name is used, instead of the field .field_description, which is translatable. Moreover, there isn't a condition checking if the field should appear or not. -- opw-4876726
This update adjusts automated checks for CRM activity handling after the activity action began loading in two steps. It also verifies that both active and inactive records are included where needed, helping keep CRM behavior reliable after related changes.
Original PR description
The crm activity action is now loaded in two steps Also check that the domain gets `active in [true, false]` added while we're here See linked community pull request task-4951716 Forward-Port-Of: odoo/enterprise#90762
The Swedish SIE4 import now reads files using UTF-8 so Swedish characters are handled correctly. This helps avoid import errors or incorrect text when customers upload accounting files containing local characters.
Original PR description
The aim of this commit is using UTF8 instead of ISO-8859-1 for the file decoding. We received feedback from customers that the previous decoding wasn't handle correctly swedish characters. The documentation tends to say that we should follow CP437. As UTF8 is a superset of CP437, we are now using it. opw-4868415 Forward-Port-Of: odoo/enterprise#90498
This fix ensures invoice policy calculations only consider consumable products, preventing incorrect results when other product types are present. It helps avoid test failures and supports more reliable sales and invoicing behavior in affected localizations.
Original PR description
steps to reproduce: 1- install l10n_ke_edi_oscu_mrp 2- run test test_discount_and_untaxed_subtotal The compute_invoice_policy method was not correctly filtering products by their type. This fix ensures that only consumable products are considered when computing the invoice policy. build_error-70728 Forward-Port-Of: odoo/enterprise#90252
The Czech VAT Control Statement XML export now uses the official date field name for B2 vendor bill entries. This prevents the Czech tax portal from treating the field as blank, reducing filing errors for affected companies.
Original PR description
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and…
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill. 3. Go to Reporting → Tax Return → VAT Control Statement (CZ). 4. You will see the bill listed under section B2. Now export the XML. 5. In the exported XML, the field `dan_dppd` is present. **Observations**: When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`. According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized. **Issue**: The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section. **Solution**: The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation. opw-4868515 Forward-Port-Of: odoo/enterprise#90394