**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.

**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.

**Current behavior:**
The cancellation email is rendered in the organizer's language.

**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.

**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.

**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.

opw-6323179

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278378

## Issue
The test `test_anglo_saxon_cogs_partial_down_payment_credit_note` from the `sale_stock` module is failing when the Kenyan localization is installed.

This issue is similar to the one fixed by https://github.com/odoo/odoo/commit/b9e5807cd70d.

## Steps to reproduce
1. Install `sale_stock` and `l10n_ke_edi_oscu_stock`
2. Run the test `test_anglo_saxon_cogs_partial_down_payment_credit_note`
3. **The test fails with the following error:**

```
AssertionError: Lists differ: [{'debit': 0, 'credit': 40, 'account_id': 268}] != []

First list contains 2 additional elements.
First extra element 0:
{'debit': 0, 'credit': 40, 'account_id': 288}

+ []
- [{'account_id': 288, 'credit': 40, 'debit': 0},
-  {'account_id': 268, 'credit': 0, 'debit': 40}]
```

## Cause
When `l10n_ke_edi_oscu_stock` is installed, the `invoice_policy` of Kenyan products (or products without a company set) is set to `"delivery"` by the `_compute_invoice_policy` method from that module:

https://github.com/odoo/enterprise/blob/f4cd9a38c699e8d8f17990a283793985bfc89948/l10n_ke_edi_oscu_stock/models/product.py#L16-L21

This impacts the `SaleOrder.qty_to_invoice` field, as we now use the `qty_delivered` (which is 0 here) instead of the `product_uom_qty`:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale/models/sale_order_line.py#L1001-L1006

With a `qty_to_invoice` set to 0, the `SaleOrder._get_invoiceable_lines` doesn't add the product as an invoiceable line:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale/models/sale_order.py#L1492-L1498

And finally, with the `'cogs'` invoice lines missing, the comparison with the expected values fail:

https://github.com/odoo/odoo/blob/d0ee4af1ddb969dfc9023c628f8b128f2b22e89d/addons/sale_stock/tests/test_anglo_saxon_valuation.py#L1879-L1887

## Fix
We manually set the `invoice_policy` of the test product to 'order' to keep the test configuration consistent regardless of the other modules installed.

runbot-242508

Steps to reproduce the bug:
- Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery' in that case)
- Run TestSaleMRPAngloSaxonValuation.test_sale_mrp_kit_bom_cogs (sale_mrp) or TestAngloSaxonValuation.test_anglo_saxon_cogs_partial_down_payment_credit_note (sale_stock)

Problem:
These tests create their products without setting invoice_policy explicitly, relying on the field's implicit default. l10n_ke_edi_oscu_stock's _compute_invoice_policy (https://github.com/odoo/enterprise/blob/4e459417dac809caafea34aa2e487fc3c1f0ce1a/l10n_ke_edi_oscu_stock/models/product.py#L16-L21) forces invoice_policy to 'delivery' for any storable product whose company_id is not set, which is the case for products created in these test fixtures.

Once invoice_policy becomes 'delivery', invoiced quantities are driven by qty_delivered instead of the ordered quantity, which the affected tests never account for (some deliver an arbitrary quantity instead of the exact BoM demand, others never validate a delivery at all), causing wrong COGS amounts or wrongly invoiced quantities as soon as such a localization is installed alongside these modules.

Solution:
Pin invoice_policy to 'order' explicitly wherever these test fixtures create their products, so the test outcome no longer depends on which other modules happen to be installed.

runbot-243633

For an MO with component tracked by lot is possible to close it without assigning the lot number even when they are marked for manual consumption.
From the shopfloor this will close the MO that will disappear when it's gone it will throw a user error, without the MO reappearing.

Steps to reproduce
---------------------------
**Issue 1**
1) Create a product "final"
2) Create a product "component" tracked by lot
3) Update the on hand quantity and don't assign a lot number
4) Create a BoM for "final" with "component" as component and manual consumption
5) Create a MO and confirm it
6) Go to shopfloor
7) Set "final" quantity
8) Set "component" quantity
10) Close the MO
-> The MO disappear (leaving a user error)
-> Since the "component" does not have a lot number it should not disappear

**Issue 2**
Same steps as Issue 1 until step 6:
6*) Add "comp" as barcode to the product component
7*) Go to barcode
8*) Open the manufacturing order
9*) Add the quantity to final
10*) Scan "comp"
11*) Scan a non-existent lot number, ex: "12345"
-> It raise the error

Observation
----------------------

**Issue 1**
When clicking on "Closing production" it will call [onClickValidateButton](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L481-L482)() that will lead us to validate,
and validate will [call](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L511) the function [pre_button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L507) in python.

in pre_button_mark_done, we will skip any check on the lot number, since we already have set qty_producing (when setting "final" quantity), 
 it will avoid _set_quantities where a check for lot number is made:
https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2235-L2239
https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2839-L2844
And it will also skip the consumption wizard since it doesn't check for lot number nor allow to set lot numbers:
https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/mrp/models/mrp_production.py#L1658-L1660
After avoiding both checks we go back to validate.

In validate and we update the variable underValidation which will [trigger the fadeout animation](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L154)
When the [animation ends](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L662-L665),
the call to realValidation will be triggered and will call productionValidation that will send a call to [button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L551)

In button_mark_done, when calling _action_done on the move_lines, we will finally check that there is a lot number, which will trigger an error :
https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/stock/models/stock_move_line.py#L664-L669
but because the fadeout animation is already over, the mo will have disappeared, which means we can't correct the userError that has been raised.

**Issue 2**
In barcode when scanning a lot after a product, it will not create a lot but only apply a lot_name :
https://github.com/odoo/enterprise/blob/7b57a2927aeb8abf84d0f6acc64a7e9bbc8f608d/stock_barcode/static/src/models/barcode_model.js#L1306-L1311
this cause an issue with the existing condition since it only pass the check if there is a lot, but in this case there only is a lot_name.

When we click on "Produce" in a Mo in barcode, it will call validate, that in this case, will call button_mark_done:
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/components/main.xml#L163
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/models/barcode_model.js#L602-L605
https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L14

opw-6060310

### Steps to Reproduce:
1. Make sure that the Sale and Inventory modules are installed
2. Enable Multi-Step Routes and Packages in Inventory Configurations
3. Warehouse configuration > Outgoing shipments > Select Pick then Deliver (2 steps)
4. Routes > Deliver in 2 steps (pick + ship) > Pull From > Destination Location > Select WH/Output
5. Routes > Deliver in 2 steps (pick + ship) > Push To > Action > Change to Pull From
6. Operation Types > Delivery Orders > Packages > Enable Move Entire Packages
7. Go to any product, ex. Drawer > On Hand > Set original on hand qty to 16 and new lot to 50
8. Create a new SO and make 2 lines, with the same product, and change the second line's price to something else, ex. 80.0
9. Deliveries > WH/PICK/00001 > Set quantity to 4 > Put in Pack > Validate and Create Backorder
10. WH/PICK/00002 > Put in Pack > Validate
11. WH/OUT/00012 > Mark PACK0000001 Done > Save. Observe how the first line quantity is changed from 3 to 4
12. Mark PACK0000002 Done > Save > Validate > Observe how it's asking for a backorder even though we already packed all 5 items.

### Description of the issue/feature this PR addresses:
Instead of using the `product_qty` from the stock move, use the quantity of the move line to correctly allocate the quantities in StockPackageLevel

### Current behavior before PR:
In the Shop Floor when loading packages, marking the package level as done causes issues on the quantity processed on the corresponding move lines. On stock transfers, we currently allocate the Quantity Done to the wrong product line.
The total quantity is correct, but the distribution across lines does not match the Demand values.
This causes the transfer to remain stuck in Reserved, even though the shipment was already processed operationally.

### Desired behavior after PR is merged:
The correct quantity from the move line is used and this resolves the issue with quantity distribution not matching move line quantities when using packages.

opw-6040640

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

### Steps to reproduce:

- Create 3 AVCO products: Super Kit, Kit, Comp
- Super Kit BoM: 2 x Kit
- Kit BoM: 1 x Comp
- Create and confirm a purchase order for 1 X Super Kit at 100
- Validate the receipt of 2 Comp
- Go to the valuation
> Both units of Comp are valued at 100 for a total of 200

### Cause of the issue:

The issue has been introduced by:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063 To be more precise, the price unit of each unit of Comp is expected to be computed by the `_get_price_unit`. This method used to rely on the `product_qty` appropriately:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063#diff-687527af1723e60816358020c4d83687479df62ca0cfd71079f0a82afb4b3efeL27 However, backorder adapt the move demand and hence did not provide the appropriate demand in this flow that computation logic was changed to rely on the `bom` and `bom_line` quantities:
https://github.com/odoo/odoo/blob/29977a6a80442af49ecefa7fef54f085483d8f77/addons/purchase_mrp/models/stock_move.py#L20-L40 This new computation is not correct in case of nested boms since the `bom_line` only carries the unit demand on the last explosion stage.

### Additional issue:

If nested kit boms lead to the creation of 2 moves with the same `cost_share` and `bom_line_id`, these moves will be merged without summing their `cost_share` leading to an under pricing of the kit since its related `stock_move`'s `cost_share` will not sum up to 100 percents anymore.

This issue is tested in `test_avco_purchase_nested_kit_explode_cost_share_backorder_2` and fixed similarly to demand merging:
https://github.com/odoo/odoo/blob/613f3cb7b2f4813ce6c8f53718a6cca841b081ad/addons/stock/models/stock_move.py#L1122-L1134

### Note:

We also modify the test `test_valuation_with_backorder` to be understandable and to make appropriate asserts.

opw-6253776

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

With "Round Globally" tax rounding, invoicing a 100% down payment and then creating the final regular invoice yields a credit note of 0.01 instead of an invoice of 0.00. The sales order is still flagged as fully invoiced, so the customer is left with an unexpected refund document.

A down payment line can only store a `price_unit` rounded to the 'Product Price' decimal precision, while the product lines it must offset are aggregated from their raw amounts. When a product subtotal falls on a half cent (e.g. quantity 0.5 at 1.01 => 0.505), the final invoice carries a raw residual of -0.005. `_round_tax_details_base_lines` rounds that aggregate to -0.01 and `_distribute_delta_amount_smoothly` assigns the cent to the largest base line, leaving its `balance` one cent away from its own `price_subtotal`. Since `amount_untaxed` derives from the balances, the invoice totals -0.01 and `_create_invoices` switches it to a refund.

The product amounts have already been invoiced and rounded on the down payment invoice, so the aggregation must target those rounded amounts. Declare them through `manual_total_excluded_currency`, which is read from the base line dict and feeds `target_total_excluded`. `total_excluded` is unchanged, so no posted or displayed amount moves.

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

Steps to reproduce
---
1. Confirm a purchase order and receive it a few days later.
2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure.

Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date.

Issue
---
The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has
been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573).
The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the
scheduled date and the receipt) rather than date_done - date_order.
https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28

opw-6226523

Issue
-----
Adding packagings of products through the catalog sometimes doesn't work.

Steps to reproduce
-----
- Create multiple products with some packaging
- Create a PO
- Open the product catalog
	- Add products & packagings (click the product then the pack button)
- Go back to the PO

=> Some lines might not have the packaging but instead a single unit

Cause
-----
The problem is a race condition with the
`/product/catalog/update_order_line_info` route

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/product/controllers/catalog.py#L32-L33

The problem comes from the call to `_update_order_line_info` where the bahviour is different depending on the order in which the calls are treated.

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/purchase/models/purchase_order.py#L1195-L1238

The expected flow is for the call to add the product to be treated first, then the call to add the packaging. If the order of the calls is reversed, the packaging call does not go into either of the conditions and nothing happens, then the "add product" call is handled and a line for a single unit is created.

This is caused by the JS where the "add product" calls are handled in order by processing them in a promise queue

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/product/static/src/product_catalog/kanban_record.js#L68-L78

The "packaging" calls, however, are fired directly, meaning there is no guarantee the line has already been created.

https://github.com/odoo/odoo/blob/427d398880c381981e088f7001f855a10d1cd581/addons/purchase/static/src/product_catalog/kanban_record.js#L34-L47

-----
Ticket:
opw-6401919