Odoo Changelog — 2026-06-14

Sunday, June 14, 2026

18 changes

Branch: saas-19.3

6 changes

Bug Fixes(6)

Resolved issues and error corrections

[PERF] project: optimize portal /my/tasks page load

PR #269642

Coresaas-19.3projectMEDIUM

This update significantly speeds up the /my/tasks portal page, especially when dealing with a large number of tasks. By optimizing database queries and reducing unnecessary data retrieval, the page now loads much faster, improving user experience and productivity. This change focuses on performance and stability.

Original PR description

The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations:

1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order

2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000.

3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans.

Benchmark (page 1 load):

_prepare_tasks_values (milestone + count, excludes lazy main search):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.294s    | 0.230s   |
| 1,500,000 |      2,000 | 0.511s    | 0.222s   |
| 3,000,000 |     12,000 | 1.129s    | 0.258s   |
| 6,000,000 |     24,000 | 2.388s    | 0.261s   |
| *6,000,000|     24,000 | 2.015s    | 1.976s   |

*6M measured while navigating last page (full count triggered).

Main search query (ORDER BY fix):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.525s    | 0.013s   |
| 1,500,000 |      2,000 | 0.685s    | 0.017s   |
| 3,000,000 |     12,000 | 1.479s    | 0.040s   |
| 6,000,000 |     24,000 | 3.121s    | 0.043s   |
| *6,000,000|     24,000 | 7.562s    | 3.781s   |

Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5
Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b
*6M measured while navigating last page (high offset).

- opw-5478903

Forward-Port-Of: odoo/odoo#258064

#performance#portal#tasks

[FIX] purchase_stock: use final location if no warehouse in picking type

PR #269748

Coresaas-19.3purchase_stockMEDIUM

This update resolves an issue where purchase order confirmations would fail when a delivery type didn't associate with a warehouse. The fix ensures that the system correctly identifies the default destination when a warehouse isn't specified, preventing a type error and allowing purchase orders to be processed smoothly. This improves the reliability of the purchase order workflow.

Original PR description

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5 Steps to reproduce: Clear the Warehouse field (set it to False) Create a purchase order Set "Deliver…

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5

Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised

Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
    - Clear the Warehouse field (set it to False)

- Create a purchase order:
    - Set "Deliver To" to the operation type with no warehouse
    - Add any product
    - Try to confirm the PO

Problem:
A traceback is triggered:
```   return self.parent_path.startswith(other_location.parent_path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```

`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False

Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).

opw-6253817

Forward-Port-Of: odoo/odoo#268317

#purchase#inventory#warehouse

[FIX] stock: preserve MTO link when store step uses a sublocation

PR #269635

Coresaas-19.3stockMEDIUM

This update fixes an issue where delivery orders weren't correctly reserving the newly produced lot in multi-step manufacturing workflows. Specifically, changing the destination of a 'Store Finished Products' transfer to a sublocation of the warehouse caused the system to incorrectly use existing stock instead. This ensures that deliveries now always utilize the latest manufactured lot.

Original PR description

Steps to reproduce: - Create a storable product “P1” with Lot tracking - Enable routes: MTO + Manufacture - Create a BoM for the product: - Component: C1 - Configure the warehouse with 3-step…

Steps to reproduce:
- Create a storable product “P1” with Lot tracking
- Enable routes: MTO + Manufacture
- Create a BoM for the product:
    - Component: C1
- Configure the warehouse with 3-step manufacturing
- Have on-hand stock in WH/Stock with Lot 001
- Confirm a Sales Order for the product
- Confirm the generated Manufacturing Order and produce Lot 002
- In the "Store Finished Products" transfer, change the destination location from WH/Stock to WH/Stock/Shelf 1 and validate
- Check the Delivery Order reservation

Problem:
The move is reserved with Lot 001 instead of 002

When using a 3-step manufacturing flow (MTO + Manufacture), if the user manually changes the destination of the "Store Finished Products" transfer to a sublocation of WH/Stock (e.g. WH/Stock/Shelf 1), the MTO link between the production and the delivery order was incorrectly broken, causing the delivery to reserve existing stock instead of the freshly produced lot.

Root cause: `_skip_push()` only skipped push logic when the downstream move's source was a child-or-equal of the current move's destination (`m.location_id._child_of(self.location_dest_id)`). When the destination was changed to a sublocation (WH/Stock/Shelf 1), this check failed, so `_push_apply()` ran, found the delivery's source (WH/Stock) was not a child of WH/Stock/Shelf 1, and called `_break_mto_link()`, clearing `move_orig_ids` on the delivery move. The delivery then fell back to make-to-stock reservation and picked an unrelated lot.

opw-6197212

Forward-Port-Of: odoo/odoo#269141
Forward-Port-Of: odoo/odoo#268783

#manufacturing#inventory#delivery

[FIX] l10n_fr_pdp: fix KeyError 'messages' when sending invoices in demo mode

PR #269981

Coresaas-19.3l10n_fr_pdpMEDIUM

This update resolves an error that prevented invoices from being sent correctly in demo mode for French eInvoicing. The fix ensures the system correctly handles responses from the IAP service, improving the reliability of the demo environment and facilitating testing.

Original PR description

**Steps to reproduce:**
* Install `l10n_fr_pdp` module.
* Activate French eInvoicing in demo mode and enable "Participate in the pilot phase".
* Create an invoice for a French client and send it via the French E-Invoicing.

**Observed behavior:**
* A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`.

**Cause:**
* `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2.
* Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure.
* Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step.

**Fix:**
* Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2.
* Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`.
* Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message.

IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63

opw-6289723

Forward-Port-Of: odoo/odoo#269515

#french invoicing#demo mode#iap

[FIX] website_delivery_sendcloud: fix typo in module name

PR #119431

Enterprisesaas-19.3website_delivery_sendcloud

This update resolves a minor visual issue where the name of the Sendcloud website delivery module was displayed incorrectly. The typo ('Sendcould') has been corrected, ensuring consistent branding and a professional user experience. This change does not impact functionality.

Original PR description

The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary.

opw-6239003

Forward-Port-Of: odoo/enterprise#118416
Forward-Port-Of: odoo/enterprise#118223

#website#delivery#typo#Sendcloud

[FIX] l10n_fr_pdp: fix is sent condition

PR #269988

Coresaas-19.3l10n_fr_pdp

This update resolves an issue where move sending was incorrectly required for flow 10 processing in the French VAT (pdp) module. The fix also corrects errors related to copy-pasted zip files during address validation by ensuring country identification.

Original PR description

This fix removes the condition that moves must be sent to be part of a flow 10 and correct copy-pasted zip by country_id in address check.

Forward-Port-Of: odoo/odoo#269910
Forward-Port-Of: odoo/odoo#268022

#VAT#French Accounting#pdp

Branch: saas-19.2

4 changes

Bug Fixes(4)

Resolved issues and error corrections

[PERF] project: optimize portal /my/tasks page load

PR #269599

Coresaas-19.2projectMEDIUM

This update significantly speeds up the /my/tasks portal page, especially when viewing large numbers of tasks. By optimizing how data is retrieved and sorted, the page now loads much faster, improving user experience and productivity. This change focuses on efficiency within the Odoo system.

Original PR description

The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations:

1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order

2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000.

3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans.

Benchmark (page 1 load):

_prepare_tasks_values (milestone + count, excludes lazy main search):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.294s    | 0.230s   |
| 1,500,000 |      2,000 | 0.511s    | 0.222s   |
| 3,000,000 |     12,000 | 1.129s    | 0.258s   |
| 6,000,000 |     24,000 | 2.388s    | 0.261s   |
| *6,000,000|     24,000 | 2.015s    | 1.976s   |

*6M measured while navigating last page (full count triggered).

Main search query (ORDER BY fix):
| # Tasks   | # Projects | Before PR | After PR |
|-----------|------------|-----------|----------|
|   500,000 |      2,000 | 0.525s    | 0.013s   |
| 1,500,000 |      2,000 | 0.685s    | 0.017s   |
| 3,000,000 |     12,000 | 1.479s    | 0.040s   |
| 6,000,000 |     24,000 | 3.121s    | 0.043s   |
| *6,000,000|     24,000 | 7.562s    | 3.781s   |

Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5
Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b
*6M measured while navigating last page (high offset).

- opw-5478903

Forward-Port-Of: odoo/odoo#258064

#performance#portal#tasks

[FIX] purchase_stock: use final location if no warehouse in picking type

PR #269137

Coresaas-19.2purchase_stockMEDIUM

This update resolves an issue where purchase order confirmations would fail when a delivery type didn't associate with a warehouse. The fix ensures that the system correctly identifies the default destination when a warehouse isn't specified, preventing a type error. This improves the reliability of purchase order processing.

Original PR description

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5 Steps to reproduce: Clear the Warehouse field (set it to False) Create a purchase order Set "Deliver…

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5

Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised

Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
    - Clear the Warehouse field (set it to False)

- Create a purchase order:
    - Set "Deliver To" to the operation type with no warehouse
    - Add any product
    - Try to confirm the PO

Problem:
A traceback is triggered:
```   return self.parent_path.startswith(other_location.parent_path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```

`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False

Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).

opw-6253817

Forward-Port-Of: odoo/odoo#268317

#purchase#inventory#warehouse

[FIX] l10n_fr_pdp: fix KeyError 'messages' when sending invoices in demo mode

PR #269979

Coresaas-19.2l10n_fr_pdp

This update resolves a technical error that prevented invoices from being successfully sent in demo mode for French eInvoicing. The fix ensures the system correctly handles responses from the IAP service, improving the reliability of the demo environment and facilitating testing.

Original PR description

**Steps to reproduce:**
* Install `l10n_fr_pdp` module.
* Activate French eInvoicing in demo mode and enable "Participate in the pilot phase".
* Create an invoice for a French client and send it via the French E-Invoicing.

**Observed behavior:**
* A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`.

**Cause:**
* `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2.
* Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure.
* Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step.

**Fix:**
* Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2.
* Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`.
* Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message.

IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63

opw-6289723

Forward-Port-Of: odoo/odoo#269515

#french invoicing#demo mode#iap

[FIX] l10n_fr_pdp: fix is sent condition

PR #269987

Coresaas-19.2l10n_fr_pdp

This update resolves an issue where move submissions were incorrectly required to trigger a specific process (Flow 10). The fix also corrects errors related to copied zip files, ensuring accurate address validation based on country. This improves the reliability of the French PDP integration.

Original PR description

This fix removes the condition that moves must be sent to be part of a flow 10 and correct copy-pasted zip by country_id in address check.

Forward-Port-Of: odoo/odoo#269910
Forward-Port-Of: odoo/odoo#268022

#accounting#france#pdp

Branch: saas-19.1

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mrp_workorder: handle manually added SN by-products in shopfloor

PR #120484

Enterprisesaas-19.1mrp_workorderMEDIUM

This update resolves an issue where manually added by-products on manufacturing orders caused errors during production closure. The fix ensures that serial numbers are correctly assigned to manually added by-products, preventing the system from flagging them as requiring serial numbers. This improves the reliability of the shopfloor process.

Original PR description

**Issue** Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.…

**Issue**
Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.

**Steps to reproduce**
- Activate by-product in the settings
- Create a product with an empty BOM (final product)
- Create another product tracked by serial number (by-product)
- Create and confirm a MO for the final product with 1 unit of the by-product
- Go to Miscellaneaous -> operation Type -> shopfloor
- Activate the option "Pre fill lot/serial numbers in shop floor"
- Return to the MO and open the shopfloor view
- Click on the '+' button next to the by-product and assign a serial number
- Try to close the production
-> A user error is raised stating that the by-product requires a serial number.

**Cause**
When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number.

Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error:
https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669

opw-6223158

Forward-Port-Of: odoo/enterprise#118792

#manufacturing#serial numbers#by-products

[FIX] l10n_fr_pdp: fix KeyError 'messages' when sending invoices in demo mode

PR #269975

Coresaas-19.1l10n_fr_pdpMEDIUM

This update resolves a critical error that prevented French eInvoicing invoices from being sent correctly during demo mode. The fix ensures the system accurately matches the IAP response structure, allowing successful invoice processing. This improves the reliability of the demo environment for testing and development.

Original PR description

**Steps to reproduce:**
* Install `l10n_fr_pdp` module.
* Activate French eInvoicing in demo mode and enable "Participate in the pilot phase".
* Create an invoice for a French client and send it via the French E-Invoicing.

**Observed behavior:**
* A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`.

**Cause:**
* `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2.
* Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure.
* Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step.

**Fix:**
* Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2.
* Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`.
* Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message.

IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63

opw-6289723

Forward-Port-Of: odoo/odoo#269515

#french_e-invoicing#demo#invoice

[FIX] l10n_fr_pdp: fix is sent condition

PR #269986

Coresaas-19.1l10n_fr_pdpMEDIUM

This update resolves an issue where move submissions were incorrectly required for flow 10 processing in the French payroll (l10n_fr_pdp) module. The fix also corrects errors related to copied zip files during address validation by ensuring country identification. This ensures accurate and reliable payroll processing for French businesses.

Original PR description

This fix removes the condition that moves must be sent to be part of a flow 10 and correct copy-pasted zip by country_id in address check.

Forward-Port-Of: odoo/odoo#269910
Forward-Port-Of: odoo/odoo#268022

#payroll#french#accounting

Branch: saas-18.3

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] point_of_sale: display positive order change on receipt

PR #269966

Coresaas-18.3point_of_sale

The Point of Sale receipt was previously showing incorrect change amounts as negative values. This update fixes a bug where an unnecessary negation was applied, now correctly displaying the change as a positive amount on the receipt. This ensures customers receive accurate information about their refunds.

Original PR description

**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value…

**Issue:**
The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total.

**Before:**
The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers.

**After:**
The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`).

**Steps to Reproduce:**

1. Open a Point of Sale session
2. Add products to the cart (example total: `$49,496.00`)
3. Select the **Cash** payment method
4. Enter an amount greater than the order total (example: `$55,000.00`)
5. Observe that the **Change** field displays a negative value
6. Confirm the payment
7. Print the receipt and observe that the change amount is also negative

**Root Cause:**
The issue was caused by an unnecessary negation in the `export_for_printing()` method in `pos_order.js`.

The `get_change()` method already returns the correct positive change amount. However, the code applied an extra negation (`-this.get_change()`), which converted the value into a negative amount before rendering it on the receipt.

**Fix:**
Removed the unnecessary negation in `export_for_printing()` so the receipt now displays the correct positive change amount.

Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)]

opw-6211988

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#267278
Forward-Port-Of: odoo/odoo#264681

#pos#receipt#customer experience

[FIX] l10n_fr_pdp: fix is sent condition

PR #269883

Coresaas-18.3l10n_fr_pdpMEDIUM

This update resolves an issue where move records needed to be sent to be processed within the French payroll (l10n_fr_pdp) flow. The fix also corrects a problem with copied zip files being incorrectly identified based on country, ensuring accurate address validation. This improves the reliability of the French payroll processing.

Original PR description

This fix removes the condition that moves must be sent to be part of a flow 10 and correct copy-pasted zip by country_id in address check.

Forward-Port-Of: odoo/odoo#268022

#payroll#french#accounting

[FIX] l10n_fr_pdp: fix KeyError 'messages' when sending invoices in demo mode

PR #269902

Coresaas-18.3l10n_fr_pdp

This update resolves a technical error that prevented French eInvoicing invoices from being successfully sent in demo mode. The fix ensures the system correctly handles responses from the IAP proxy, addressing a mismatch in data formats and logging, ultimately improving the reliability of the demo environment.

Original PR description

**Steps to reproduce:**
* Install `l10n_fr_pdp` module.
* Activate French eInvoicing in demo mode and enable "Participate in the pilot phase".
* Create an invoice for a French client and send it via the French E-Invoicing.

**Observed behavior:**
* A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`.

**Cause:**
* `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2.
* Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure.
* Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step.

**Fix:**
* Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2.
* Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`.
* Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message.

IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63

opw-6289723

Forward-Port-Of: odoo/odoo#269515

#french invoicing#demo mode#iap

Branch: master

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] mrp_workorder: filter assigned employees by workcenter allowed emp

PR #120477

Enterprisemastermrp_workorder

This update improves control over which employees can be assigned to work orders. Now, workcenters can restrict employee selection based on a list of allowed employees, ensuring appropriate resource allocation. This change enhances efficiency and accuracy in work order management.

Original PR description

Add domain on `employee_assigned_ids` to restrict selectable employees based on the workcenter configuration. If `all_employees_allowed` is True, no filter is applied. Otherwise, only employees listed in `allowed_employees` are selectable.

opw-6208602

Forward-Port-Of: odoo/enterprise#119509
Forward-Port-Of: odoo/enterprise#117876

#workorders#employee assignment#resource management

Branch: 19.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] pos_settle_due: adapt refunds to original settlement behavior

PR #118284

Enterprise19.0posMEDIUM

This update resolves a bug where customer account refunds were causing incorrect settlement behavior in newer Odoo versions. The fix restores the original settlement process, ensuring refunds are handled consistently and preventing issues like orders reappearing after refunds and incorrect settlement calculations. This improves the reliability of customer account settlements.

Original PR description

Refunding a customer account order was introduced by this commit: https://github.com/odoo/enterprise/commit/5a1af0db647563cffcb796a257ad01c0d0c9af91

The goal was to show both the original order and its refund in the settlement list and allow settling them together.

This works in 18.2 where the feature was introduced, but it causes issues in later versions.

The main issues are:
- Refunded order still appears after the full order is refunded and a new order was created and paid by customer account.
- When two orders exist and the larger one is settled first, the second order cannot be settled correctly.

How to reproduce:
- Create OrderA with AmountA
- Create OrderB with AmountB < AmountA
- Settle OrderA
- Try to settle OrderB: it cannot be found
- Settling by amount shows incorrect values due to negative customer_due_total for settlement orders.

The fix:
Restore the original settlement behavior and handle customer account refunds the same way as settlement orders.

opw-6192248

Forward-Port-Of: odoo/enterprise#118103
Forward-Port-Of: odoo/enterprise#117520

#settlement#refund#customer account

The /my/tasks portal page suffered from severe performance degradation with large task. Three key optimizations: 1. ORDER BY: Use project_id.id instead of project_id in sort orders to avoid resolving through project.project._order 2. Capped count: Replace the unconditional search_count with a capped version (limit=10k pages). Only fetch the full count when the user navigates beyond page 10,000. 3. Milestone check: Use search(limit=1, order='id') to leverage index-only scans. Benchmark (page 1 load): _prepare_tasks_values (milestone + count, excludes lazy main search): | # Tasks | # Projects | Before PR | After PR | |-----------|------------|-----------|----------| | 500,000 | 2,000 | 0.294s | 0.230s | | 1,500,000 | 2,000 | 0.511s | 0.222s | | 3,000,000 | 12,000 | 1.129s | 0.258s | | 6,000,000 | 24,000 | 2.388s | 0.261s | | *6,000,000| 24,000 | 2.015s | 1.976s | *6M measured while navigating last page (full count triggered). Main search query (ORDER BY fix): | # Tasks | # Projects | Before PR | After PR | |-----------|------------|-----------|----------| | 500,000 | 2,000 | 0.525s | 0.013s | | 1,500,000 | 2,000 | 0.685s | 0.017s | | 3,000,000 | 12,000 | 1.479s | 0.040s | | 6,000,000 | 24,000 | 3.121s | 0.043s | | *6,000,000| 24,000 | 7.562s | 3.781s | Planer before: https://explain.dalibo.com/plan/aa47635ecddadfh5 Planer after: https://explain.dalibo.com/plan/d89gg3f5e8ed529b *6M measured while navigating last page (high offset). - opw-5478903 Forward-Port-Of: odoo/odoo#258064

Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5 Steps to reproduce: Clear the Warehouse field (set it to False) Create a purchase order Set "Deliver To" to the operation type with no warehouse Add any product Confirm the PO → TypeError is raised Steps to reproduce the bug: - Have at least 2 warehouses - Go to Inventory > Configuration > Operation Types > Receipts - Clear the Warehouse field (set it to False) - Create a purchase order: - Set "Deliver To" to the operation type with no warehouse - Add any product - Try to confirm the PO Problem: A traceback is triggered: ``` return self.parent_path.startswith(other_location.parent_path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: startswith first arg must be str or a tuple of str, not bool ``` `_get_final_location_record` computes `wh_stock_loc` from `picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id` is False (a valid configuration, operation types can be detached from any warehouse), `lot_stock_id` short-circuits to False Solution: guard the _child_of call with not wh_stock_loc. When the picking type has no warehouse, wh_stock_loc is falsy and there is nothing to compare against, so the method falls back to default_location_dest_id (the only destination available). opw-6253817 Forward-Port-Of: odoo/odoo#268317

Steps to reproduce: - Create a storable product “P1” with Lot tracking - Enable routes: MTO + Manufacture - Create a BoM for the product: - Component: C1 - Configure the warehouse with 3-step manufacturing - Have on-hand stock in WH/Stock with Lot 001 - Confirm a Sales Order for the product - Confirm the generated Manufacturing Order and produce Lot 002 - In the "Store Finished Products" transfer, change the destination location from WH/Stock to WH/Stock/Shelf 1 and validate - Check the Delivery Order reservation Problem: The move is reserved with Lot 001 instead of 002 When using a 3-step manufacturing flow (MTO + Manufacture), if the user manually changes the destination of the "Store Finished Products" transfer to a sublocation of WH/Stock (e.g. WH/Stock/Shelf 1), the MTO link between the production and the delivery order was incorrectly broken, causing the delivery to reserve existing stock instead of the freshly produced lot. Root cause: `_skip_push()` only skipped push logic when the downstream move's source was a child-or-equal of the current move's destination (`m.location_id._child_of(self.location_dest_id)`). When the destination was changed to a sublocation (WH/Stock/Shelf 1), this check failed, so `_push_apply()` ran, found the delivery's source (WH/Stock) was not a child of WH/Stock/Shelf 1, and called `_break_mto_link()`, clearing `move_orig_ids` on the delivery move. The delivery then fell back to make-to-stock reservation and picked an unrelated lot. opw-6197212 Forward-Port-Of: odoo/odoo#269141 Forward-Port-Of: odoo/odoo#268783

**Steps to reproduce:** * Install `l10n_fr_pdp` module. * Activate French eInvoicing in demo mode and enable "Participate in the pilot phase". * Create an invoice for a French client and send it via the French E-Invoicing. **Observed behavior:** * A traceback is raised with `KeyError: 'messages'` in `_send_peppol_documents`. **Cause:** * `DEMO_ENDPOINTS['send_document']` in `l10n_fr_pdp` was returning `{'ppf_messages': [...]}`, missing the `messages` key that `_send_peppol_documents` in `account_peppol` unconditionally reads for flow 2. * Additionally, the demo mock was returning `uid` instead of `uuid` inside `ppf_messages`, which does not match the real IAP response structure. * Finally, in `l10n_fr_pdp/models/pdp_flow.py`, after successfully sending a flow 10 batch, the system attempted to log `response['uid']` despite the `_send_to_proxy()` method returning `uuid`. This caused a crash during the chatter logging step. **Fix:** * Fix `DEMO_ENDPOINTS['send_document']` to return `{'messages': [...]}` with `message_uuid` entries, matching the real IAP response structure for flow 2. * Update `ppf_messages` in the demo mock to return `uuid` instead of `uid`. * Fix `pdp_flow.py` to correctly access `response['uuid']` instead of `response['uid']` when posting the success message. IAP Response: https://github.com/odoo/iap-apps/blob/b0462b9dded36a4d6dd45d00ddd13cd36e31807e/iap_services/l10n_fr_pdp_proxy/controllers/message_controller.py#L63 opw-6289723 Forward-Port-Of: odoo/odoo#269515

The displayed name contained a typo ("Sendcould" instead of "Sendcloud") All other references already use the correct spelling, so no further changes were necessary. opw-6239003 Forward-Port-Of: odoo/enterprise#118416 Forward-Port-Of: odoo/enterprise#118223

This fix removes the condition that moves must be sent to be part of a flow 10 and correct copy-pasted zip by country_id in address check. Forward-Port-Of: odoo/odoo#269910 Forward-Port-Of: odoo/odoo#268022

**Issue** Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application. **Steps to reproduce** - Activate by-product in the settings - Create a product with an empty BOM (final product) - Create another product tracked by serial number (by-product) - Create and confirm a MO for the final product with 1 unit of the by-product - Go to Miscellaneaous -> operation Type -> shopfloor - Activate the option "Pre fill lot/serial numbers in shop floor" - Return to the MO and open the shopfloor view - Click on the '+' button next to the by-product and assign a serial number - Try to close the production -> A user error is raised stating that the by-product requires a serial number. **Cause** When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number. Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669 opw-6223158 Forward-Port-Of: odoo/enterprise#118792

**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers. **After:** The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`). **Steps to Reproduce:** 1. Open a Point of Sale session 2. Add products to the cart (example total: `$49,496.00`) 3. Select the **Cash** payment method 4. Enter an amount greater than the order total (example: `$55,000.00`) 5. Observe that the **Change** field displays a negative value 6. Confirm the payment 7. Print the receipt and observe that the change amount is also negative **Root Cause:** The issue was caused by an unnecessary negation in the `export_for_printing()` method in `pos_order.js`. The `get_change()` method already returns the correct positive change amount. However, the code applied an extra negation (`-this.get_change()`), which converted the value into a negative amount before rendering it on the receipt. **Fix:** Removed the unnecessary negation in `export_for_printing()` so the receipt now displays the correct positive change amount. Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)] opw-6211988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267278 Forward-Port-Of: odoo/odoo#264681

Add domain on `employee_assigned_ids` to restrict selectable employees based on the workcenter configuration. If `all_employees_allowed` is True, no filter is applied. Otherwise, only employees listed in `allowed_employees` are selectable. opw-6208602 Forward-Port-Of: odoo/enterprise#119509 Forward-Port-Of: odoo/enterprise#117876

Refunding a customer account order was introduced by this commit: https://github.com/odoo/enterprise/commit/5a1af0db647563cffcb796a257ad01c0d0c9af91 The goal was to show both the original order and its refund in the settlement list and allow settling them together. This works in 18.2 where the feature was introduced, but it causes issues in later versions. The main issues are: - Refunded order still appears after the full order is refunded and a new order was created and paid by customer account. - When two orders exist and the larger one is settled first, the second order cannot be settled correctly. How to reproduce: - Create OrderA with AmountA - Create OrderB with AmountB < AmountA - Settle OrderA - Try to settle OrderB: it cannot be found - Settling by amount shows incorrect values due to negative customer_due_total for settlement orders. The fix: Restore the original settlement behavior and handle customer account refunds the same way as settlement orders. opw-6192248 Forward-Port-Of: odoo/enterprise#118103 Forward-Port-Of: odoo/enterprise#117520