Friday, July 25, 2025
22 changes · saas-18.2
Resolved issues and error corrections
This fixes e-invoice generation so product identification details are only included when a product barcode is actually available. It helps avoid producing unnecessary or invalid invoice XML data in the UBL/BIS3 electronic invoicing flow.
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) Forward-Port-Of: odoo/odoo#219896
This fix makes an automated check for sales order lines in project sales wait for the screen to finish updating before continuing. It helps prevent random test failures, improving release stability without changing day-to-day user behavior.
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 Forward-Port-Of: odoo/odoo#220179
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
Fixes an invalid ending command in ZPL label templates used for stock labels. This helps ensure barcode or shipping labels print correctly on compatible label printers, avoiding failed or malformed labels.
Original PR description
In the ZPL, the `^XZ` command indicates the end of a label. For an unknown reason (a typo ?), the PR [1] replaces some of them by `^XZj` which is not a valid ZPL command. [1]: https://github.com/odoo/odoo/pull/187225
This fix ensures post-upgrade tests still run when custom modules are present after an upgrade. It prevents an internal module list from becoming empty, reducing the risk of missed validation after upgrades.
Original PR description
Since e4ca53b0a3780c298c280988997321c2be8e7d3f we compute `updated_modules` from information in the DB. This leads to an empty `module_names` list if there are custom modules after an upgrade. Since the `to upgrade` modules is non-empty, `module_names` gets the list of `registry.updated_modules` which is empty when we are just running post upgrade tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an automated live chat navigation check more reliable by opening the session list directly instead of relying on a menu shortcut that could fail intermittently. It helps reduce false test failures and keeps delivery validation stable without changing user-facing live chat behavior.
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 Forward-Port-Of: odoo/odoo#220345
This fixes a visual issue where dragged items could appear at the wrong size when certain page styling was applied. Users get a more consistent drag-and-drop experience, especially in automation rule kanban views.
Original PR description
This commit fixes an issue in draggable_hook_builder where elements with !important percentage-based width or height styles would be incorrectly sized when dragged. The sizing would be computed relative to the document rather than the style computed by the hook. To address this, the hook now applies max-width and max-height styles explicitly. This helps enforce correct sizing and prevents !important rules from interfering with the visual consistency of dragged elements. The issue was first spotted in the actions kanban view present in the automation rules form view. task-4891808
Gradient-colored text in the website editor now correctly displays underline and strikethrough formatting. This prevents styled website content from appearing incomplete or inconsistent when users combine gradients with text decorations.
Original PR description
Problem: Using `-webkit-text-fill-color: transparent;` in `.text-gradient` is required for gradient text, but it also causes underline (`<u>`) and strikethrough (`<s>`) styles to become invisible, since those decorations rely on the text fill color. This results in the lines under `u` and `s` elements not being rendered when gradient text is applied. Solution: Render the underline and strikethrough manually using a `background-image` (gradient) applied to `s` and `u` tags. This simulates the missing lines while keeping the gradient text style. Steps to reproduce: 1. Add a text block in the website editor. 2. Apply a text color gradient. 3. Apply underline or strikethrough. → The underline/strikethrough is not visible. opw-4797201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210390
Uploading a non-PDF document for a product no longer immediately causes an error when setting it to appear inside a quote PDF. The system now avoids trying to read non-PDF files as PDFs, preserving the existing validation that prevents saving unsupported files.
Original PR description
Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the…
Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the `Documents` smart button. - Click new and upload any non-pdf file. - On the field `Sale : Visible at`, select the value `inside quote pdf` and you will get the error. Error: `PdfReadError: EOF marker not found` The error occurs because at the line [1] the code requires a pdf file, and as we have passed a non-pdf file the error occurs. [1] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/sale_pdf_form_field.py#L206 There is already a constraint made for this particular thing [2], but the problem is that the error is due the compute [3] (Because constraints are checked at the time of form saving, and compute runs when a field is changed so even before the constraint is checked the error will be triggered). [2] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L44-L45 [3] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L59-L61 This commit resolves this issue by skipping the pdf extraction if the file is not a pdf type, because we already have a constraint [2] that will trigger at save. sentry-6161120972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215844
Fixed an issue where receiving a file through WhatsApp could trigger an error when request debugging was enabled. The system now logs file responses safely by recording their size instead of trying to store raw file content, improving reliability for teams using WhatsApp messaging.
Original PR description
When Debug requests is enable on the whatsapp business account and user replies with the file, a traceback will appear. Steps to reproduce the error: - Install ``whatsapp`` and ``contacts`` - Create…
When Debug requests is enable on the whatsapp business account and user replies with the file, a traceback will appear. Steps to reproduce the error: - Install ``whatsapp`` and ``contacts`` - Create a whatsapp business account > Enable Debug requests - Create a contact > Add a phone number > send whatsapp message with any whatsapp template - Now reply with the file(ex. pdf or image) in message from the contact's whatsapp. - Traceback in terminal Traceback: ``ValueError: A string literal cannot contain NUL (0x00) characters.`` https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166 Here, ``message`` contains NUL (0x00) characters because user replies with the file, value for the ``message`` comes from the below response. response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57 Here, ``res.text`` contains NUL (0x00) characters. So, it will lead to the above traceback. sentry-6314521165
This update keeps several Odoo Enterprise areas working reliably with newer platform versions, including Python 3.13 and Debian Trixie. It adjusts automated checks around appointments, documents, planning, projects, expenses, signing, and WhatsApp so upgrades are less likely to be blocked by environment-related test failures.
Original PR description
Forward-Port-Of: odoo/enterprise#90447 Forward-Port-Of: odoo/enterprise#90352
This update adjusts CRM Enterprise automated checks to match a change where activity actions load in two steps. It helps ensure CRM activity views continue to behave correctly, including showing both active and archived records where expected.
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#90824 Forward-Port-Of: odoo/enterprise#90762
This fixes the website Helpdesk contact form so the description field is hidden when it is the only field and shown only when other fields are present. When displayed, the field label now uses the visitor's selected language, improving clarity for multilingual support teams and customers.
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 Forward-Port-Of: odoo/enterprise#88913
Users can now clear the end date on an existing commission plan without triggering an error. This prevents a save failure in the Sales Commission app and keeps commission plan maintenance smooth.
Original PR description
Currently, an error occurs when clear the date_to field from an already created record. Steps to Reproduce: - Install the `sale_commission` module. - Go to `Commission Plans` and create a record. - Now, clear the `date_from` field and save. `TypeError: '>' not supported between instances of 'bool' and 'datetime.date'` This error occurs when we clear the date_to field from an already created record. The error started occurring after https://github.com/odoo/enterprise/commit/926c8f041b51a04f0153be27cfcc8658a07be5b0 this commit that introduced the daterange widget for the date_from field. And when we clear the date_to field and try to save, it triggers the constraint [1] and raises the error. [1] https://github.com/odoo/enterprise/blob/377321fd7e7b1b2026734b75c79c74c8947e2e6c/sale_commission/model/commission_plan.py#L64 This commit ensures that the record is saved only if the date_to field is also present in the record. sentry-6710699656
Belgian Intrastat XML exports now respect the option to hide zero-value lines. This prevents transactions with no cost from being included in exported reports, keeping submitted files consistent with what users see on screen.
Original PR description
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide…
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide lines at 0'. Doing this will prevent 0 cost transactions from appearing in the report. However, when exporting to XML, such transactions are still displayed. Note: this is related to Belgian companies only. ## Reproduction Steps 1. Go to settings and make sure the company you're operating with is Belgian. Then, in accounting, under the Custmer Invoices section, check the 'Intrastat' option. 2. Go to products and create a new product of type 'Goods'. Then, in the 'Accounting' tab, click on a random commodity code. Set the country of origin as a country belonging to the European Union (for example, Austria). Click on save. You should see a field named 'Intrastat Supplementary Unit Amount' appear. 3. Go to accounting. Click on the 'Vendors' tab and 'Bills'. Click on New. Select a random vendor, and add a line containing the product you just created. Add the column 'Intrastat' and set the corresponding field at '11 outright...'. Then, set a price. In the 'Other Info' tab, set the field 'Intrastat Country' as a random country in the European Union (for example, Australia). Set the fiscal position at 'Import/Export' and set the 'Intrastat Transport Mode' field at '1. Sea transport'. Finally, click on confirm. 4. Duplicate the vendor bill you just created. On this new vendor bill, set the Intrastat at '12 Direct trade...'. Display the column 'Disc.%' and set the field at 100. Then click confirm. 5. Click on the 'Reporting' tab, and under 'Audit Reports', click on 'Intrastat Report'. Set the month to the current month, then click on 'Report: Intrastat(Services....)' and select 'Intrastat (Goods)'. You should be able to see the 2 vendor bills you just created. Click on 'Options' then 'Hide lines at 0': you should see the bill having a 0 cost disappear. Finally, click on the cog on the top left next to 'Intrastat Report' and click on 'XML'. 6. Once the XML file has finished downloading, open it. ### Expected behavior The transaction having a 0 cost shouldn't appear. ### Unexpected behavior The transaction having a 0 cost appears. ## Origin of the issue In the code responsible for the display of the XML report, there isn't any condition responsible for checking if the transaction should be displayed or not. _________________________________________ opw-4464123 --- Forward-Port-Of: odoo/enterprise#90193 Forward-Port-Of: odoo/enterprise#89285
This fix makes automated checks for the Web Studio report editor more stable by waiting more reliably for scrolling actions to finish. It reduces intermittent test failures, helping releases move through validation with fewer false alarms.
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 Forward-Port-Of: odoo/enterprise#90806
The Sign app now handles reloaded or duplicated signing request pages more safely. This prevents users from seeing an error screen when returning to or copying an active signing workflow, improving reliability for document signing.
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 Forward-Port-Of: odoo/enterprise#90601
This change reverts a previous adjustment to an error message in the Belgian point-of-sale blackbox module. It helps keep the message behavior aligned with the expected wording for Belgian POS compliance flows.
Original PR description
This partially reverts commit 6bfc6dd766daa5653fccf95bb60cec0c99507107
Features or functions removed from Odoo
An unused internal mail function was removed after the related WhatsApp channel flow was discontinued. This cleanup reduces maintenance overhead without changing the experience for users.
Original PR description
Since odoo/enterprise#69648 the usage of the `openWhatsAppChannel()` has been removed. This method was the only one that used `pin()` method of thread model. This change removes `pin()` method as it's now dead code. Related to: odoo/enterprise#90999
Miscellaneous changes
An unused WhatsApp-related function was removed after it was no longer needed by the system. This is an internal cleanup that reduces maintenance overhead without changing the user experience.
Original PR description
Since odoo/enterprise#69648 the usage of the `openWhatsAppChannel()` has been removed. This change removes this method as it's a dead code. Related to: odoo/odoo#220525