Daily updates from Odoo
Saturday, April 25, 2026
28 changes · saas-19.2
Resolved issues and error corrections
This update resolves a crash in the POS order details dialog that occurred when the database language was not English. The fix ensures the system correctly compares field labels to their translated versions, preventing errors and improving usability for users in different languages. This enhances the overall user experience for international Odoo users.
Original PR description
**Before this commit** When attempting to open up the "Details" of a POS order, when the database is not in English, we would crash here because there wouldn't be any fields that match the string "Served By" exactly. For example, in Spanish, this field is labeled "Atendido por". **After this commit** Compare the field labels to the database's language-translated string, "Served By". opw-6145087
This update ensures that product prices in the Point of Sale (POS) system accurately reflect currency conversions when using pricelists with different currencies. Previously, discounts and surcharges were incorrectly applied without considering the currency difference. This fix corrects a calculation error, ensuring accurate pricing for international POS operations.
Original PR description
Steps to reproduce: ------------------- 1. Set up a POS with a currency different from the company currency (e.g. company in USD, POS in SSP). 2. Create a USD pricelist with a surcharge rule (e.g.…
Steps to reproduce: ------------------- 1. Set up a POS with a currency different from the company currency (e.g. company in USD, POS in SSP). 2. Create a USD pricelist with a surcharge rule (e.g. +10 USD on list_price). 3. Create an SSP pricelist that references the USD pricelist as its base (base = "pricelist"), with an additional discount rule. 4. Assign the SSP pricelist to the POS and add a product. -> The displayed price ignores the currency conversion between the two pricelists: surcharges/discounts are applied as if both pricelists share the same currency. What's happening: ----------------- The POS pre-converts product prices from company currency to POS currency in `_load_pos_data_read`. However, `getPrice` in JS never converts between the POS currency and the pricelist's own currency before applying the rule's formula (surcharge, discount, etc.). The fix: -------- In `getPrice`, convert the price from POS currency to pricelist currency before applying the rule, then convert back afterward. Note that we have changed the loading order of the models for `pos_self_order`, such as 'res.currency' records are loaded after 'product.pricelist' ones, because now the loaded currencies depend on the loaded pricelists. opw-6013513 Forward-Port-Of: odoo/odoo#260195 Forward-Port-Of: odoo/odoo#255357
This update fixes a missing field in the contact form for Czech companies (l10n_cz). The 'City' field was absent, which is a required data point for Czech tax reporting. This change ensures accurate data collection and compliance with local regulations.
Original PR description
Steps to reproduce: 1- Install Contacts and l10n_cz 2- Switch to CZ company 3- Open any contact Issue: `City` field is missing in address section Expected behavior: Should have the `City` field opw-6123084
This update significantly reduces the time it takes to load timesheets, particularly in systems with many projects. The change optimizes the search process to avoid unnecessary database queries, resulting in a faster and more responsive user experience. This improves efficiency for users managing their timesheets.
Original PR description
The loading time of timesheets was extremely high (around 4 seconds) for databases with many projects and tasks. This commit aims to resolve the time required to load by setting `count_limit` on the search for project suggestions to avoid calling `search_count` as it is uneccesary. task-6128133
This update ensures service order line display names accurately show the price unit when requested, regardless of context. Previously, the display name was incorrectly formatted, leading to inconsistent information. This fix corrects a bug related to how the price unit is displayed for service products.
Original PR description
Before this commit, when `formatted_display_name` is true in the context, the display name of `sale.order.line` records will always show the partner and the price unit if it contains a service product. The problem is `with_price_unit` is no longer checked in the context to really know if we want to display or not the price unit in the formatted display name. This commit checks `with_price_unit` in the context to display the price unit in the formatted display name if it is truly in the context. Forward-Port-Of: odoo/odoo#259080
This update resolves an issue where the minimum IS (Insurance Savings) amount was incorrectly calculated in the Swiss payroll module. The fix ensures accurate IS calculations, aligning with Swiss tax regulations and improving payroll accuracy for Swiss businesses using Odoo Enterprise. This update impacts the l10n_ch_hr_payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update resolves a crash issue affecting the Self-Ordering and Mobile Menu (QR ordering) interfaces in Odoo Enterprise SaaS-19.2. The problem stemmed from an outdated field name within the POS data loading process, which has now been corrected to ensure these key features function correctly.
Original PR description
## Overview Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS…
## Overview Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow. ## Steps to Reproduce 1. Install `pos_blackbox_be` 2. Open POS 3. Access the Mobile Menu (QR code) or Self-Ordering page ## Current Behavior - A traceback is raised - The interface does not load ## Root Cause The method `_load_pos_self_data_fields` returns the field: iface_fiscal_data_module However, from SaaS-19.1 this field was renamed to: iot_fdm_be_id This mismatch causes the POS self-ordering data loading to fail. ## Fix Updated the returned field to match the new field name. # Before return fields + ['iface_fiscal_data_module'] # After return fields + ['iot_fdm_be_id'] ## Impact - Restores proper loading of Mobile Menu (QR ordering) - Fixes Self-Ordering interface crash opw-6044883 ## Reproduction Video https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing Forward-Port-Of: odoo/enterprise#114357
This update fixes a test failure caused by a delay in processing the final click on a discard button during an Odoo tour. The fix ensures all tour popups are fully closed before the tour concludes, preventing data inconsistencies and improving test reliability. This resolves a potential issue that could impact the stability of the MRP Workorder module.
Original PR description
**Issue** Currently, there is an async issue with the test `test_shop_floor_disable_serial_create`that may fail with the following error: "Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies." **Cause** Although the tour explicitly closes all popups, the last click on the discard button may not be processed before the tour ends: https://github.com/odoo/enterprise/blob/859e65e8c267701bb19dbff9d24a8c80774dbaa6/mrp_workorder/static/tests/tours/tour_shopfloor.js#L332-L333 runbot-242504 Forward-Port-Of: odoo/enterprise#114367
This update optimizes how Odoo handles price list calculations, addressing a potential performance bottleneck. By using a more efficient graph-based approach, the system now processes large price list datasets much faster and avoids timeouts. This results in quicker calculations and a smoother user experience.
Original PR description
The _check_pricelist_recursion constraint could cause performance issues when iterating over full recordsets or repeatedly querying large datasets.
Refactor the recursion logic to traverse pricelists as a graph (DFS on pricelist pairs) and replace item-level iteration with a targeted _read_group query to fetch only relevant pricelist-based rules:
- pricelist_id
- base = 'pricelist'
Avoid redundant path evaluations by tracking visited pricelist pairs.
This ensures that only necessary records are fetched and processed, significantly reducing memory usage and avoiding timeout issues on large datasets.
opw-6099182
Forward-Port-Of: odoo/odoo#259310This update corrects a misleading issue in the Z report generated from date ranges. Previously, the report header incorrectly displayed information from a single session even when multiple sessions with completed orders were included. This change ensures the report header accurately reflects the sessions contributing to the report data, providing a more reliable view of sales performance.
Original PR description
Before this commit: - When generating a Z report via date range (config_ids, no session_ids), the header's session name was derived from the closed-session if there was exactly one, which excludes open sessions (stop_at IS NULL). - If an open session had completed orders (state='done') within the date range, those orders were included in the report body while the session itself was absent from the sessions list. - This caused the header to display the closed session's name and title the report as a single-session Z report, even though it contained data from multiple sessions. opw-6123054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259900
This update fixes an issue where combo product pricing was incorrectly calculated when customers purchased more than one unit. The previous system misapplied discounts and prices, leading to inaccurate totals. This change ensures accurate pricing and calculations for combo products, regardless of quantity purchased.
Original PR description
When buying more than one unit of a combo product, the free-item quota (qty_free) was not scaled by the parent quantity, causing child lines with qty > 1 to be partially mis-classified as extra. This meant the same line was processed by both the free and extra loops, with the extra loop overwriting the correct price. Additionally, the proportional price_unit for free child lines used the unscaled original_total (which already includes the parent qty factor) against a per-unit parent_lst_price, resulting in a price that was too low by exactly the parent qty factor. opw-6045562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261222 Forward-Port-Of: odoo/odoo#258753
This update fixes an issue where employees weren't automatically added to channels when their department was set to 'Administration'. Now, the system correctly subscribes users to the channel once the department update is saved, ensuring consistent channel membership based on employee roles.
Original PR description
**Steps to reproduce:** navigate to 'Discuss' > 'Channels' create a new channel and set 'Auto Subscribe Departments' to 'Administration' create a new user and a corresponding employee record go to 'Employees' > locate the employee set the employee's department to 'Administration' **Current behavior before PR:** The user is not automatically added to the channel. This occurs because the auto-subscription logic is triggered before the department change is committed to the database. **Desired behavior after PR is merged:** The user is correctly auto-subscribed to the channel once the department update is saved. task-5448649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261268 Forward-Port-Of: odoo/odoo#241617
This update resolves an issue where deleting a project stage incorrectly navigated users to a different view and displayed archived tasks. The fix ensures the original view remains active, the stage is properly deleted, and the user's intended task list is displayed without unexpected filters.
Original PR description
# Steps to reproduce 1. Create a project 2. Create a stage 4. Remove the stage # Current behavior Instead of remaining in the project tasks view, it switches to the tasks view filtered with the current project. Additionally, it displays archived tasks because no filter is selected, thereby discarding original ones. This also applies to stage deletion in other views (e.g., My Tasks), where the search filters are completely discarded. # Expected behavior The dialog should be closed, the stage should be deleted, and the original view should remain active. This is done through a soft-reload of the page, ensuring the original view is kept, together with original breadcrumbs, and the stage is visually disappearing. task-5498274 Forward-Port-Of: odoo/odoo#260213 Forward-Port-Of: odoo/odoo#246935
This update resolves an issue where product category images weren't showing on website B when configured with a different domain. The fix ensures category images use absolute URLs, bypassing domain-based access restrictions and ensuring consistent display across all websites.
Original PR description
Scenario: - set two website A and B with different domain - create an eCommerce category Y - create and publish a product with category Y, website B - drop category list widget in a page in website B - set in /odoo/system-parameters web.base.url to domain of website A - open the page in website B while being logged out of website A Result: the category Y image is dead. Cause: category images are using domain of "web.base.url", so if that corresponds to a website where the category is not shown (because of the access rule "Hide empty eCommerce categories to public/portal users") then the image will not be shown (unless we are a logged in internal user on the domain of "web.base.url"). Fix: use absolute URL without domain for category image, the same way it is done for other dynamic snippets (eg. Products). opw-6118004 Forward-Port-Of: odoo/odoo#260124
This update ensures that the default website correctly updates when the sequence order is changed, particularly in incognito browsing sessions. Previously, changes to website sequence didn't reliably update the default website selection. This fix corrects a caching issue to guarantee the lowest sequence website is always served as the default.
Original PR description
**Problem:** Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match). **Steps to reproduce:** 1. Create two…
**Problem:** Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match). **Steps to reproduce:** 1. Create two websites with no domain set 2. Change their sequence order via the handle widget in the backend 3. Open an incognito window 4. The default website shown is still the old one **Current behavior:** The default website does not change after reordering. **Expected behavior:** The website with the lowest sequence should be served as the default. **Cause of the issue:** Commit d6f4af2790a0 replaced `models.Model` with `models.CachedModel` and removed the blanket `self.env.registry.clear_cache()` from the top of `write()`. CachedModel only auto-clears caches for fields listed in `_cached_data_fields`, but `sequence` is not in that list. As a result, `_get_current_website_id` (decorated with `@tools.ormcache`) keeps returning the stale cached website ID after a sequence change. https://github.com/odoo/odoo/commit/d6f4af2790a0abacba6e616b00d999eddc30edc9#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2L339-L341 **Fix:** Restoring `clear_cache()` scoped to the existing sequence/company_id check ensures the ormcache is invalidated only when relevant fields change, rather than on every write as before. opw-6102426 Forward-Port-Of: odoo/odoo#257913
This update resolves a crash that occurred when assigning recruiters in the Odoo recruitment Kanban view. The issue stemmed from an unnecessary cache parameter in avatar image URLs, which caused errors due to missing data. Removing this parameter ensures the Kanban view functions correctly without crashes.
Original PR description
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The…
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The ?unique= cache related parameter was added to the avatar image URL in the autoCompleteItem slot of KanbanMany2OneAvatarEmployeeField. This parameter relies on write_date being available on the autocomplete suggestion record. However, web_name_search only returns id and display_name, so write_date is undefined on autocomplete suggestion records, causing a crash when accessing autoCompleteItemScope.record.data.write_date.ts. **Bug Solution:** Remove the ?unique= parameter from the avatar image URL in the autoCompleteItem slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction. **Task:** 6092768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261040
This update resolves an issue where creating a filter with invalid data in the system would cause a crash. Now, the system gracefully handles these errors, preventing the application from stopping. While the filter isn't active, the system no longer crashes, improving stability.
Original PR description
On some view, create and edit a filter, but put something unparseable by JS in the `context` field eg: `{123}`.
Go back to the view.
Before this commit there was a crash, because the python parser in JS crashed.
After this commit, there is no crash, the filter is visible but not activable.
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#260999
Forward-Port-Of: odoo/odoo#260612This update resolves an issue where the website's video placeholder would crash when a video URL wasn't provided. The code has been updated to gracefully handle missing URLs, preventing errors and ensuring video placeholders function correctly across all saved website pages. This improves the user experience and prevents website disruptions.
Original PR description
Commit[^1] reworked the `s_video` snippet placeholder into a plain SVG, dropping the inner `<iframe>` and the `data-oe-expression` attribute that carried the video URL. The `.media_iframe_video` class was kept, so the `MediaVideo` interaction still binds to the placeholder and calls `generateVideoIframe`, which then reads `dataset.oeExpression || dataset.src` (undefined) and crashes on `.match()`. The same crash hits the `DOMContentLoaded` fallback on the frontend for any saved page that ends up with a `src-less` placeholder. To prevent the issue, we exit the interaction early if no `src` is saved and leave the existing children in place. Nothing changes if the video has a valid URL already. [^1]: https://github.com/odoo/odoo/commit/db91ddd861b13694fe0e0b8d9cce23e02f487a6a task-6158263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261184
This update resolves a technical issue that was limiting the efficiency of WhatsApp marketing automation. Previously, the system wasn't processing all relevant messages at once, leading to slower performance. This fix ensures that WhatsApp automation runs more effectively, improving the speed and reliability of marketing campaigns.
Original PR description
Forward-Port-Of: odoo/enterprise#114570
This update resolves an issue where opening a restaurant order with an active Fiskaly transaction on a second device would cause duplicate transaction attempts and errors. The fix ensures that transaction state information is properly persisted, preventing these errors and improving the reliability of the POS system when syncing with Fiskaly.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#115170 Forward-Port-Of: odoo/enterprise#114599
This update fixes an issue where deferred invoice moves weren't consistently linked to the correct customer partner. The change ensures that the `partner_id` is taken directly from the original invoice line, maintaining data accuracy and preventing discrepancies in financial reporting. This improves the reliability of deferred accounting processes.
Original PR description
When creating deferred move lines, the `partner_id` could be incorrectly influenced by the `default_partner_id` context key (e.g., when generating an invoice from a Sales Order). This led to inconsistencies where the deferred move lines did not match the partner on the original invoice line. This commit ensures the `partner_id` is explicitly taken from the source invoice line, guaranteeing data integrity across all deferred move lines. Steps: - Create a sale order for partner X, receive and confirm it - Create the invoice from the SO - Change partner to Y but keep X as delivery partner (not essential to reproduce bthough) - Set a deferred start date and a deferred end date on the invoice line, covering two full months - Confirm the invoice and open deferred moves via the smart button -> Note that one deferred move's lines get the partner id from the SO instead of the invoice opw-6095711 Forward-Port-Of: odoo/enterprise#115026 Forward-Port-Of: odoo/enterprise#114439
This update ensures the AI chat window opens in full-screen mode when initiated from the system tray or command palette. Previously, the chat opened in the background, creating a less efficient user experience. This change improves usability and allows users to fully utilize the AI chat functionality.
Original PR description
Prior to this commit, when opening the chat with an agent from the systray button, the chat window was opened in the background. This commit fixes the issue by adding a call to `channel.open` which opens the chat when in full-screen mode. This commit also fixes an issue where the chat window wasn't properly opened when done from the command palette. task-5172978 Forward-Port-Of: odoo/enterprise#114840 Forward-Port-Of: odoo/enterprise#114598
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity calculations during internal transfer processes, preventing discrepancies in inventory reporting. This improves the reliability of stock management operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#114998
Forward-Port-Of: odoo/enterprise#110241This update corrects a bug where Purchase Orders and Manufacturing Orders were incorrectly linked to each other, even when unrelated to a Sales Order. The fix ensures that POs only link to Sales Orders, and MOs only link to Sales Orders, preventing confusion and streamlining the procurement process. This improves data accuracy and simplifies workflows.
Original PR description
**Steps to reproduce:** * Install modules: *mrp*, *purchase*, *sale_management*. * Go to *Settings* and enable: * *Multi-Step Routes* * *Replenish on Order (MTO)* * *Dropshipping* * Create a…
**Steps to reproduce:**
* Install modules: *mrp*, *purchase*, *sale_management*.
* Go to *Settings* and enable:
* *Multi-Step Routes*
* *Replenish on Order (MTO)*
* *Dropshipping*
* Create a *Dropship* product:
* Set route to *Dropship*.
* Add a vendor under the *Purchase* tab.
* Create an *MTO* product:
* Set route to *Replenish on Order (MTO)*.
* Configure a *Bill of Materials (BoM)*.
* Create a *Sales Order*:
* Add both products.
* Confirm the order.
* Open the Sales Order:
* Observe smart buttons for *Delivery*, *Purchase*, and *Manufacturing*.
* Open the linked *Purchase Order* and *Manufacturing Order*.
**Observed behavior:**
* The *Purchase Order* shows a smart button linking to a *Manufacturing Order*.
* The *Manufacturing Order* shows a smart button linking to a *Purchase Order*, even when unrelated.
**Expected behavior:**
* The *Purchase Order* should only show a smart button linking to the *Sales Order*.
* The *Manufacturing Order* should only show a smart button linking to the *Sales Order*.
* No cross-link between unrelated PO and MO should be displayed.
**Cause:**
* The SO pushes the `stock.reference` into procurement values: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/sale_stock/models/sale_order_line.py#L289
* The same reference is propagated to:
* Purchase Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_stock/models/stock_rule.py#L355
* Manufacturing Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/mrp/models/stock_rule.py#L184
* Opening the *Purchase Order* form triggers `_compute_mrp_production_count`.
* This compute calls `_get_mrp_productions()`: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_mrp/models/purchase.py#L21
* That method returns `self.reference_ids.production_ids`.
* Since the MO shares the same sale reference, the PO incorrectly fetches that MO and shows the *Manufacturing* smart button.
* Similarly, opening the *Manufacturing Order* form triggers `_compute_purchase_order_count`.
* This compute calls `_get_purchase_orders()`, which returns `self.reference_ids.purchase_ids`.
* Since the dropship PO shares the same sale reference, the MO incorrectly fetches that PO and shows the *Purchase* smart button.
**Fix:**
* Stop relying on shared `reference_ids` to compute links.
* Instead, follow the actual stock and procurement chain:
* For *MO → PO*:
* Use raw material moves to find related purchase lines: `self.move_raw_ids.created_purchase_line_ids.order_id | self.move_raw_ids.purchase_line_id.order_id`
* For *PO → MO*:
* Use stock move destinations to identify consuming productions.
* This ensures:
* MOs link only to POs supplying their raw materials.
* POs link only to MOs they actually replenish.
* Unrelated documents sharing the same sale reference remain isolated.
---
opw-6008943
---
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#254292This update resolves an issue where a duplicate close button was appearing in the Odoo Discussions interface. The fix restricts the button's visibility to the meeting view, ensuring a cleaner and more consistent user experience. This improves usability and prevents confusion for users.
Original PR description
ActionPanel components (e.g. invitation panel, delete thread dialog) displayed an extra close (X) button in Discuss. The close button was shown when not in a chat window, causing duplication with the existing close button. This commit restricts the button visibility to the meeting view only, preventing the extra close button. Task-[6054963](https://www.odoo.com/odoo/project/1519/tasks/6054963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the data sent to the self-order POS frontend by removing unnecessary fields. This optimization reduces data transfer, potentially improving performance and responsiveness for users. The change was a small fix to enhance the user experience.
Original PR description
Fix _generate_return_values to remove some fields that are not needed on the frontend Forward-Port-Of: odoo/odoo#260016 Forward-Port-Of: odoo/odoo#259915
This update fixes an issue where upgrade scripts within Odoo modules weren't properly organized, leading to potential logging and warning problems. Now, these scripts are correctly associated with the core upgrade package, ensuring better stability and error handling during updates. This improves the reliability of Odoo updates.
Original PR description
The resulting modules should be bound to the `odoo.upgrade` package. Side effects: - the loggers created inside the upgrade scripts are now in the `odoo.upgrade` namespace. - warnings raised by bad usages in upgrade scripts are now correctly filtered. Forward-Port-Of: odoo/odoo#261050 Forward-Port-Of: odoo/odoo#258025
This update fixes a critical issue where the DIAN web service was incorrectly overwriting customer email addresses, leading to lost data and incorrect invoice delivery. The change now preserves the customer's commercial email and creates a separate invoicing contact if the DIAN email differs, preventing sales disruptions and ensuring accurate invoice sending.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#115018 Forward-Port-Of: odoo/enterprise#114017