Friday, July 3, 2026
34 changes · saas-19.3
New functionality added to Odoo
This update adds missing translations for various messages within the Point of Sale (POS) modules. This ensures that the POS system is accessible and understandable for users in different languages, improving the overall user experience and supporting global operations. The changes include translations for dialogs, errors, and UI messages across multiple POS-related applications.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/enterprise/pull/102094 Forward-Port-Of: odoo/odoo#273265 Forward-Port-Of: odoo/odoo#239972
This update adds missing translations for various user-visible messages within the Odoo POS modules. This ensures that the POS system is correctly localized for users in different languages, improving the overall user experience and supporting international expansion. It addresses inconsistencies in translated text across multiple POS applications.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#122403 Forward-Port-Of: odoo/enterprise#102094
Enhancements to existing features
This update streamlines logging within the IoT drivers by removing unnecessary stack traces, reducing log clutter when checking ports other than FDM. The change also refines error handling for improved efficiency and stability. This improves the overall reliability of the IoT integration.
Original PR description
We remove the stack trace from the exception reading FDM response to avoid polluting the logs when probing non FDM ports. We also now catch a more precise `IndexError` instead of `Exception` as it wasn't necessary to catch this wide. We also caught the opportunity to ruff the file. Forward-Port-Of: odoo/odoo#272078
Resolved issues and error corrections
This update resolves an error that occurred when previewing canceled subscription orders. The fix ensures that canceled orders use the standard sale order preview instead of attempting to render the subscription-specific portal view, preventing a technical error. This improves the user experience for canceled subscriptions.
Original PR description
Currently, an error occurs when a user previews a canceled subscription order. **Steps to Reproduce:** - Install `sale_subscription` module. - Go to `Subscriptions` and create a `subscription order`…
Currently, an error occurs when a user previews a canceled subscription order.
**Steps to Reproduce:**
- Install `sale_subscription` module.
- Go to `Subscriptions` and create a `subscription order` with:
- a `subscription product`,
- a `recurring plan`,
- an `Until` (end date) value.
- `Cancel` the subscription order.
- Click `Preview`.
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`
When previewing a subscription order, the portal view is rendered. During rendering, the
subscription portal template is used, which computes tax values and requires calculating the
next invoice date based on the recurring plan's billing period. However, for canceled
subscription orders, next_invoice_date is False because it is only set when the order is in
the sale state. As a result, an error is raised [2].
This commit ensures that only subscription orders in the sale state use the subscription
portal template. Canceled subscription orders use the default sale order preview, similar
to orders in the draft and sent states. This is appropriate because canceled subscriptions
are not correctly displayed in the subscription portal, and they should not attempt to
render the subscription-specific portal view.
[1]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/controllers/portal.py#L686-L687
[2]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/models/sale_order.py#L2172-L2175
sentry-7579114635Features or functions removed from Odoo
This update removes a self-invoicing QR code from gift receipts. Gift receipts are designed to conceal product prices from the recipient. Removing this QR code ensures the intended privacy and prevents unintended price disclosure.
Original PR description
Gift receipts are intended to be given to the gift recipient and are designed to hide product prices. The self-service invoicing QR code could expose pricing information through the generated invoice, defeating the purpose of the gift receipt. Therefore, remove the self-invoicing QR code from gift receipts. task-6299597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269812
This update ensures that the font used for general customer notes in the Point of Sale system now matches the font used for line customer notes. This improves the visual consistency and overall presentation of customer information within the POS interface.
Original PR description
We updated the general customer note font to match the line customer note's one. task-6294200 Forward-Port-Of: odoo/odoo#270060
This update refines how employees' favorite projects are automatically selected on timesheets. Previously, a project was selected with fewer than 3 linked timesheets. Now, a project is only chosen if at least 3 of the employee's 5 most recent timesheets are associated with it, ensuring more accurate project association.
Original PR description
A favorite project is now selected only when at least 3 of the employee's 5 most recent timesheets are linked to it. task-6290859 Forward-Port-Of: odoo/odoo#273259
This update corrects a bug in the self-ordering POS feature. Previously, when a self-order was created, the link to the original table QR code was lost, causing issues with order validation and payment. The fix ensures that the table reference is maintained correctly, allowing users to seamlessly validate and pay their self-ordered items.
Original PR description
Steps to reproduce: --------------- - Enable QR Menu & Ordering in POS - Enable Service at Table - Create a self-order from a table QR - Validate/pay the order from the POS Cause: ----------- The write override unconditionally `table_id` to `self_ordering_table_id`, even when `table_id` was falsy, clearing the original self-order table link. Fix: ---------- Only update `self_ordering_table_id` when `table_id` is explicitly set and truthy. Task-6272642 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268459
This update fixes an issue where customer form view titles and breadcrumbs displayed excessively long addresses. Now, only the customer's name is shown, creating a cleaner and more readable navigation experience. This change aligns with existing behavior in other Odoo fields.
Original PR description
- Create a new Invoice; - Assign a Customer with a multiline address; - Click on the internal link (arrow icon) of the Customer field. Before this commit, the form view title and the breadcrumb would contain not only the customer's name but also their full address. This resulted in an excessively large and unreadable breadcrumb. Now, only the name is retained. This commit applies the same behavior already used in many2one fields: the display name is split by line breaks, and only the first line is kept for the title and breadcrumb. task-id 6329662 Forward-Port-Of: odoo/odoo#272550 Forward-Port-Of: odoo/odoo#272059
This update resolves an issue where the webhook URL field in the Odoo form view would overflow, preventing users from clicking the renew button. The fix ensures the URL is properly truncated, maintaining the button's accessibility and functionality. This improves the user experience for renewing subscriptions.
Original PR description
Before this commit, the webhook URL field could overflow in the form view, causing the adjacent renew button to become partially or fully unclickable. This commit fixes the issue by allowing the copy clipboard URL field container to shrink properly within layout, so the URL is truncated as intended and the renew button remains accessible. task:6317827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue with the website event quiz where users weren't receiving a clear success message after completing a quiz. The change ensures a positive and informative message is displayed, enhancing the user experience. This improves the overall usability of the event tracking feature.
Original PR description
opw-6332274 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#272593 Forward-Port-Of: odoo/odoo#272371
This update resolves an issue where the preview of webhook sample payloads would fail when certain fields returned complex data structures (specifically `frozendict` objects). The fix ensures that the payload is correctly formatted for JSON serialization, preventing the preview from crashing and allowing users to properly configure webhook notifications.
Original PR description
**Steps to Reproduce:** - Create a Server Action of type 'Webhook Notification'. - Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` →…
**Steps to Reproduce:** - Create a Server Action of type 'Webhook Notification'. - Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`). - Add the field to the webhook fields. - Open the webhook sample payload preview. **Issue:** - During sample payload generation: - The selected fields are read from a sample record. - A selected field returns a structure containing `frozendict` objects. - The payload is serialized using `json.dumps()`. - JSON serialization fails with: ```text TypeError: keys must be str, int, float, bool or None, not frozendict ``` - The webhook sample payload computation crashes and the preview cannot be displayed. **Root Cause:** - The webhook sample payload may contain `frozendict` objects returned by selected fields. - The serializer used for payload generation does not handle such mapping-like objects, causing `json.dumps()` to fail. **Solution:** - Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload. **OPW-6295777** 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#272324 Forward-Port-Of: odoo/odoo#271864
This update allows users to define default values for specific fields within Odoo, but only for fields they are authorized to access. This ensures data consistency and simplifies workflows by allowing users to pre-populate fields with their appropriate settings. It addresses a previous limitation where default values were not always correctly applied based on user permissions.
Original PR description
Users should be able to set default values only for fields they have access to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273619 Forward-Port-Of: odoo/odoo#273089
This update fixes an issue where incoterm information was missing from purchase quotation reports. After a recent code update, the report now correctly displays the incoterm, providing clearer visibility for sales and procurement teams. This ensures accurate reporting and better decision-making regarding international shipments.
Original PR description
After a refactor the incoterm and location didn't show on the purchase quotation Task-id: 6206523 Forward-Port-Of: odoo/odoo#270991
This update resolves a sporadic issue where the 'Turn camera on' button wasn't appearing correctly during video calls. The fix ensures the meeting view is fully initialized before the user navigates away, preventing delays in the call setup process. This improves the reliability of the camera functionality within meetings.
Original PR description
The test starts a meeting, then switches to another channel to join its call, expecting the camera button to read "Turn camera on". Starting a meeting runs startMeeting(), which fires enterFullscreen() as a fire-and-forget tail once the meeting call is joined. The test only waited for the meeting's "Stop camera" button (set mid-join, before that tail) before navigating, so enterFullscreen could still be pending during the channel switch. When it ran late it pointed the fullscreen channel at the newly joined channel and turned isFullscreen on. That channel's in-call view is gated on showCallView (!isFullscreen), so it was torn down and the "Turn camera on" button never rendered within the 3s timeout. Wait for the meeting view to be fully active before navigating away, so the whole startMeeting chain (enterFullscreen included) has settled first. https://runbot.odoo.com/odoo/error/939805 Forward-Port-Of: odoo/odoo#273650
This update resolves a technical issue that could cause server errors when handling WebSockets. The fix focuses on how the system manages database connections, ensuring resources are properly cleaned up even in error situations. This improves the overall reliability and stability of the Odoo SaaS platform.
Original PR description
Currently, when a `PoolError` from `psycopg2.pool` is raised (code ref [1]) during the execution of `retrying()` inside `acquire_cursor()`, Python's contextlib generates the following server error: ``` RuntimeError: generator didn't stop after throw() ``` This occurs because the exception is suppressed within the generator-based context manager, causing the generator to continue execution after throw(). This commit fixes the issue by limiting the `suppression/retry` logic to the cursor acquisition step. It also uses `ExitStack()` to ensure proper management of the exit callback stack across the `yield`, guaranteeing that resources are cleaned up correctly even if an exception is raised after the cursor is yielded. [1]: https://github.com/odoo/odoo/blob/1956c5e3e14086f699e4582a7332577bc2fbf557/odoo/sql_db.py#L648 Sentry-7567409750,7401155298
This update corrects a bug where users would continue to be suggested as recipients after unfollowing a record. The fix ensures that the user is completely removed from the suggested recipient list, preventing them from being re-added unless they re-follow the record. This improves the user experience by streamlining the follow/unfollow process.
Original PR description
### Steps to reproduce: - Open any mail thread in chatter - Click the "Send To" button once - Click "Unfollow" - You will be a suggested recipient ### Cause of Issue: The suggested recipient generation did not filter out the current user. When the user unfollows, `_message_get_suggested_recipients` is called when storing the thread, and since the user is no longer on the followers list, they get added back as a suggested recipient. https://github.com/odoo/odoo/blob/b4c7247ff218fb850fd91af3e2baa726a82d439c/addons/mail/models/models.py#L467-L468 ### Fix: Since followers are excluded from suggested recipient candidates in the mail thread, and the current user should be excluded when they unfollow, the current user is excluded altogether. This means the current user will not be suggested as a recipient again unless they re-follow the record. opw-6122351 Forward-Port-Of: odoo/odoo#269611
This update fixes an issue where the bill name in the Intrastat report was being cut off, preventing full visibility. The fix adjusts a regular expression to allow hyphens in bill names, ensuring all information is displayed correctly. This improves the accuracy of Intrastat reporting.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] * Intrastat Country: [any] * Intrastat Transport Mode: [any] - Confirm the bill - Make sure that the bill name contains a hyphen character (i.e. "-") For example, "BILL/2026-06/0001". Use the "Resequence" action from the bills list view if needed. - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Expand the line to display the bill name **Issue:** The bill name is not fully displayed. It is cropped right before the hyphen character (i.e. BILL/2026). **Cause:** A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character. **Solution:** Just allow "-" character in addition. No other character is allowed to limit the risk of matching something that should not. opw-6299854 Forward-Port-Of: odoo/enterprise#120979
This update corrects a labeling issue with the French e-invoicing disconnect button. The button was previously confusingly referencing PEPPOL and has now been renamed to 'Disconnect French electronic invoicing' for clarity. This ensures users can easily manage their e-invoicing connections.
Original PR description
The name of the disconnect button for the France e-invoicing was incorrect as it referenced peppol and was fixed in this pr to be called Disconnect French electronic invoicing task-6266337 Forward-Port-Of: odoo/odoo#273092 Forward-Port-Of: odoo/odoo#268536
This update corrects a technical issue preventing users from applying multiple pension fund taxes to a single invoice line in the Italian accounting module. The fix addresses an incorrect limit within the system, aligning with Italian electronic invoicing regulations. This ensures accurate tax calculations and compliance for IT companies using the l10n_it_edi add-on.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_it_edi_withholding 2. Switch to IT company 3. Create 2 taxes with a Pension fund type set (in Advanced Options) 4. Create an invoice…
### Steps to reproduce the issue: 1. Download Accounting and l10n_it_edi_withholding 2. Switch to IT company 3. Create 2 taxes with a Pension fund type set (in Advanced Options) 4. Create an invoice and set on the same line the 2 taxes created 5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true) ### Cause of the issue: The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273 ### Reference documentation: 1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf) 2. Following image: <img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" /> opw-6264685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273040 Forward-Port-Of: odoo/odoo#269456
This update corrects a technical issue that prevented proper logging functionality in the SaaS version of Odoo, specifically impacting versions 19.0 and later. The fix ensures that logging records are correctly generated, maintaining data integrity and operational stability.
Original PR description
During the forwardport, it was missed that get_log_metadata needs an argument starting from 19.0. Forward-Port-Of: odoo/odoo#273694
This update removes the ability to quickly create new journals from the POS payment method form. The accounting team requested this change to ensure users only create journals within the dedicated accounting application, improving data integrity and workflow. This fix applies locally and can be implemented across relevant areas.
Original PR description
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos…
Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'. Steps to reproduce: ------------------- * Open any pos payment method * Select the journal field * Select "Search more" > See two creation buttons Why the fix: ------------ One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ... The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible. Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app. This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed. Before the fix: ------------------- <img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" /> <img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" /> After the fix: ---------------- <img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" /> <img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" /> opw-6131231 Forward-Port-Of: odoo/enterprise#120379
This update resolves an issue where the "Ask AI" button would fail when multiple default prompts were configured for an AI agent. The fix ensures that only one prompt is selected, preventing errors and improving the reliability of the AI functionality. This change ensures a smoother user experience when interacting with the AI features.
Original PR description
## Problem When multiple Default Prompts are configured for the same AI Agent and interface key, clicking the "Ask AI" button raises a ValueError. ## Cause The `_get_composer_from_key_and_model`…
## Problem When multiple Default Prompts are configured for the same AI Agent and interface key, clicking the "Ask AI" button raises a ValueError. ## Cause The `_get_composer_from_key_and_model` method searches for composers matching an interface_key and model, but doesn't limit the results. When multiple Default Prompts exist for the same agent, the search returns multiple records, causing a singleton error when accessing `ai_agent_id`. ## Steps to Reproduce [[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)] 1. Go to AI > Configuration > Default Prompts 2. Create a new Default Prompt with Odoo Agent 3. Click the Ask AI button in the top-right corner 4. Error: ValueError: Expected singleton: ai.agent(2, 1) ## Fix Replace the two-step search with a single search using an `OR` domain: - Search both model-specific and generic Default Prompts in one query. - Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones. - Return only one record using `limit=1`. This preserves the previous behavior while preventing singleton errors. --- opw-6323764
This update resolves an issue preventing the successful display of a Peppol activation notification after registering as a Peppol participant. The fix corrects a validation error caused by passing 'null' as the notification title, ensuring the notification now appears correctly.
Original PR description
**Steps to reproduce:** * Install the **account_peppol** and **l10n_be** module. * Switch to BE Company. * Create and confirm a BE customer invoice. * Open the "Send & Print" dialog. * Activate…
**Steps to reproduce:**
* Install the **account_peppol** and **l10n_be** module.
* Switch to BE Company.
* Create and confirm a BE customer invoice.
* Open the "Send & Print" dialog.
* Activate Peppol (register as a Peppol participant) in developer mode and demo mode by clicking on `Why should you use it ?` on the banner in wizard.
**Observed behavior:**
* An Uncaught Promise OwlError trace is thrown on the screen: `TypeError: Cannot use 'in' operator to search for 'toString' in null`.
* The success notification indicating that Peppol was activated fails to appear.
**Cause:**
* Upon successful registration, the `peppol.registration` wizard triggers a client action to display a success notification via `display_notification`.
* The backend Python code explicitly passed `title=None` in the notification parameters, which is serialized to `null` in the JavaScript frontend.
* In previous versions (like 19.2), the `Notification` component's `title` prop validation was defined loosely as `{ type: [String, Boolean, { toString: Function }] }`. OWL did not strictly validate this shape, allowing `null` to pass through without error.
* In 19.3, the prop validation was updated to strictly enforce the object shape: `{ type: [String, Boolean, { type: Object, shape: { toString: Function } }] }`. Because JavaScript evaluates `typeof null` as `"object"`, the OWL validation schema now attempts to verify the shape by evaluating `'toString' in null`. Using the `in` operator on `null` is illegal in JavaScript and immediately crashes the application.
**Fix:**
* Replace `title=None` with `title=False` in the `_action_send_notification` method.
* This translates to `false` in the JavaScript frontend, which seamlessly satisfies the `Boolean` prop type validation for the OWL component and allows the notification to render safely without errors.
opw-6333224This update resolves an issue where the order of attribute values on the shop page wasn't consistently maintained after rearranging them in the product settings. The fix ensures that the user-defined sequence for attribute values is respected, providing a more reliable and intuitive experience for customers browsing products.
Original PR description
In saas-19.3, the shop controller was refactored to fetch attribute values using `ProductAttributeValue._read_group()` with `aggregates=["id:recordset"]`. This aggregate internally uses `ARRAY_AGG(id ORDER BY id)`, which orders values strictly by database ID, ignoring the `sequence` field defined in `product.attribute.value._order = 'attribute_id, sequence, id'`. Steps to reproduce: 1. Go to ecommerce attributes. 2. Add an attribute value to any attribute. 3. Make sure the attribute is used by a product. 4. Rearrange the order of the attribute value. 5. Go to the shop page, and try to access the attribute value by clicking on the proper attribute. 6. We see that the order isn't maintained. Fix by calling `.sorted()` on each value recordset after the aggregate, so the user-defined sequence is respected before storing into `pavs_per_attribute`. opw-6325814
This change reduces the amount of log data generated by the IoT boxes, specifically by lowering the log level. This helps manage the volume of data sent to our monitoring system (Sentry), preventing potential subscription limits and improving overall system performance. This is a proactive step to optimize our monitoring infrastructure.
Original PR description
Each time IoT box sends its logs to the server (route `/iot/log`), we then print them with the same log level. However, IoT box logs can be quite noisy (for instance when there are some connection issues), which affects the logs. Sentry side, it also implies a huge wave of useless events that reach the limits of our subscription. The logs management have been improved on next versions. In the meantime, we should at least decrease the logger level so we can keep working on Sentry
This update fixes a minor issue where call activity notifications weren't being properly updated after a call was marked as complete. The change ensures that mail messages are correctly associated with completed calls, improving the reliability of notification delivery. This ensures users receive timely updates regarding their calls.
Original PR description
In [1], we removed `action_call_done` for call activity, and to use `action_feedback` to mark a call activity done like other activities. However, we forgot to assign `activity_mail_message_id` for later mail message update. Add this in `action_feedback`. [1]: 70ba1812812596e00509415cedcc8f4bdf6c6e37 COMPR: https://github.com/odoo/odoo/pull/267663 Forward-Port-Of: odoo/enterprise#118396
This update resolves a technical issue that caused build failures in certain testing modes. The team moved assertions to the correct location, ensuring the Odoo Enterprise system builds correctly regardless of whether all apps are running simultaneously. This improves the stability and reliability of the live chat functionality.
Original PR description
Oversight of: https://github.com/odoo/enterprise/pull/98569 Some assertions were put in the wrong module, making the builds work in "all apps" mode but fail in "single app" mode. This commit moves assertions where they belong. Task-6353709 Forward-Port-Of: odoo/enterprise#122486
This update resolves a bug that prevented barcode scanning of packages containing extra products when specific warehouse settings were enabled. The fix removes an unnecessary check in the barcode scanning process, allowing packages to be correctly identified as result packages. This ensures accurate inventory tracking during barcode operations.
Original PR description
### Steps to reproduce: - In the settings Enable: Multi-steps Routes, Packages - Put your warehouse in delivery in 2-steps - On the Pick operation type in the barcode tab disable: "Allow extra…
### Steps to reproduce: - In the settings Enable: Multi-steps Routes, Packages - Put your warehouse in delivery in 2-steps - On the Pick operation type in the barcode tab disable: "Allow extra products" - Create two storable products P1 and P2 - On P2 > On hand > Update Quantity > New - Create a new line in WH/Output with a package POOK for 1 unit - Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output - Set the quantity of the move to 1 unit and go to the barcode app - Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK #### > An error is raised: This package contains extra products and extra products are not allowed on this operation. #### Expected behavior: The package should be set as result package. ### Cause of the issue: In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed: https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035 Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway. opw-6303969 Forward-Port-Of: odoo/enterprise#121789
This update restores a set of tests related to the Point of Sale (POS) flow within the l10n_fr_pdp module. These tests were temporarily removed during a recent integration of e-reporting and e-invoicing features. Restoring these tests ensures continued quality and reliability of the POS functionality.
Original PR description
During the merge of l10n_fr_pdp e-reporting and e-invoicing, some tests had to be removed. Task-6296356 Forward-Port-Of: odoo/odoo#273329 Forward-Port-Of: odoo/odoo#271294
A recent update to the SEPA XML processing for Sweden (l10n_se_bban) caused a test failure when combined with the account_iso20022 module. This commit resolves the test issue by temporarily skipping the failing test and adding a new test to ensure proper functionality.
Original PR description
Here https://github.com/odoo/enterprise/pull/114662 we changed the way the CdtrAgt node is used in the SEPA XML file for Sweden. But this change broke a test when both account_iso20022 & l10n_se_bban are installed, leading to a Non-expected child error. This commit skip the failling test if l10n_se_bban is installed, and add a new one to replace it. runbot-938366 runbot-938367 Forward-Port-Of: odoo/enterprise#122599 Forward-Port-Of: odoo/enterprise#121485
This update fixes an issue where attachments with unusual Content-Type headers were being corrupted, leading to data loss. The change ensures attachments are stored correctly by handling diverse Content-Type formats, aligning with industry standards and preventing data corruption. No new functionality was added.
Original PR description
[[REF] mail: consolidate attachment Content-Type normalization](https://github.com/odoo/odoo/pull/273097/changes/ad4e34c5c79450b1e976d9ba7047487218690585) Two separate spots handled malformed…
[[REF] mail: consolidate attachment Content-Type normalization](https://github.com/odoo/odoo/pull/273097/changes/ad4e34c5c79450b1e976d9ba7047487218690585)
Two separate spots handled malformed Content-Type headers. Merge them
into one block, read the raw header once with partition(';') to have
both the type and its parameters available without re-fetching the
header for each case.
No behavior change.
[[FIX] mail: handle attachment Content-Type with no subtype](https://github.com/odoo/odoo/pull/273097/changes/7b410fbe606b7e476f0005485e42783834983b75)
Some mailers send attachments with a bare token as Content-Type instead
of a valid 'type/subtype' pair, e.g.:
Content-Type: base64; name="foo.pdf"
Content-Transfer-Encoding: base64
Python's email library normalises any MIME type without a '/' to
'text/plain'. get_content() then decodes the base64 payload as UTF-8
text, replacing invalid byte sequences with U+FFFD. The subsequent
encode('utf-8') bakes those replacements in, permanently corrupting
the stored file.
Per Postel's law [RFC 761], be liberal in what we accept: detect these
non-standard types via `not all(mimetype.partition('/'))` and fall back
to application/octet-stream, keeping the original parameters (filename,
charset, etc.) so the attachment is stored intact.
opw-6227526
Forward-Port-Of: odoo/odoo#273097This update fixes an issue where the 'Apply To' option in pricelist rules wasn't being saved correctly, defaulting to 'Product' instead of 'Category'. The fix ensures that the selected 'Apply To' option is preserved when the pricelist rule is reopened, maintaining accurate product categorization.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install Rental(sale_renting) module and activate Pricelist. 2. Go to Rental > Products > Pricelists. 3. Open an existing pricelist or…
Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
- Apply To: Category
- Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.
Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.
Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.
This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.
Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.
opw-6346422This update resolves a technical issue preventing AI Studio fields from functioning correctly in employee appraisal forms. The problem stemmed from the AI system incorrectly storing field data, leading to a type error. This fix ensures the AI system receives the expected list format for field data, resolving the error and restoring functionality.
Original PR description
**STEPS TO REPRODUCE** 1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other) 2. Add `employee_feedback` to the prompt using '/' 3. Click the AI button to populate the field 4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'` **CAUSE** In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations. opw-5954203 Forward-Port-Of: odoo/enterprise#120799