Steps to reproduce:
1. Install CRM, Calendar, and Contacts.
2. Create a contact with an email address you can receive emails on.
3. Configure an outgoing email server.
4. Open a CRM lead and create a meeting activity using the calendar.
5. Add the created contact as an attendee of the meeting.
6. Return to the lead and click the Reschedule button on the activity.
7. Select the same meeting and change its start date to a future date.

Issue:
- Attendees receive the meeting date-change email twice.

Root cause:

- When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event.
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33
- This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails.

Solution:
- Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling.

opw-6209956

Forward-Port-Of: odoo/odoo#266675

Have an x2many field displayed as a list in a form view. In the arch, the x2many form view **isn't** inlined. In that x2many form view, there's a properties field.

When a record is clicked, `extendRecord` is called to add the new fields (those of the form) into `this.fields` and those fields are fetched. If there're properties in the property definition, fake fields are created to represent them (see `_processProperties`). However, because of extendRecord, the static list and the record don't share the same reference to the `fields` object. As a consequence, the `fields` object of the static list isn't updated with the fake property fields.

If the user closes the record, and opens/closes it again, there's a crash, because the record is re-updated with the fields of the static list, and thus doesn't know about those property fields anymore.

This commit fixes the issue by ensuring that we keep the same `fields` object when extending a record, s.t. the list and all its records always share the same object.

Bug originally reported here: https://github.com/odoo/odoo/pull/268312


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

Forward-Port-Of: odoo/odoo#269717

Version:
----------
- 18.0+

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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

Forward-Port-Of: odoo/odoo#269971
Forward-Port-Of: odoo/odoo#262396

### Steps to reproduce:
- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 2 x COMP (lot tracked)
- Put a lot for 6 units in of COMP in stock
- Create and confirm an MO for 5 units of FP
- Set the quantity producing on the MO to 1, requiring 2 of the 6 available units of COMP
- Validate the MO and create a backorder for the remaining quantity.
#### > The consumed qty on the main MO is of 0 units rather than 2.

### Cause of the issue:

Since the component is tracked, and since the pbm move was backordered, the move quantity will not be automatically set when setting the `qty_producing`:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1405-L1411 And in particular, the move is not picked as it would if the product was untracked or if the pbm move was not backordered:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1421-L1427 And, since the move will not be picked at any other point in this flow, the move will be unreserved during the `button_mark_done`: https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L2216 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1895-L1896 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1901

opw-6128575

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

Forward-Port-Of: odoo/odoo#269235

### Steps to reproduce:

1. Create a product tracked by lot
2. Put 10 units in WH/Stock without lot
3. Inventory > Operations > Adjustments > Physical Inventory
4. Select the line referring to your product and request an inventory count + Show Expected Quantity
5. Open the barcode app > Count Inventory
6. Scan your product
#### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product.

### Cause of the issue:

Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632
However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863
But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731
Note however that the super call does:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798

### Issue 2:

### Steps to reproduce:

- Steps 1 -> 5
- Click on your product line to select it
- Scan a new lot to add one new unit referring to that lot
- Confirm (1)
- Apply Now
#### > User Error: Quant's editing is restricted, you can't do this operation

Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant:
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798

Additional issue:

Fixing issue 1 and 2 highlight and other issue of the validation process:

- Steps 1 -> 6
> The line gets selected
- Scan a newlot
> a new subline is added referring to 1 unit of your new quant
- Confirm (1) > Some serials where not counted, set them as missing
#### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot

### Cause of the issue:

Applying all quantities is expecting to toggle them as counted before applying to update the existing quants:
https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63

opw-6212923

Forward-Port-Of: odoo/enterprise#118373

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#119370

Description of the issue/feature this PR addresses:
Fixes an issue where the sale order reference computation was fetching the invoice journal based on the logged-in user's current company instead of the company associated with the specific payment provider or transaction context. This caused incorrect reference processing or errors in multi-company environments when a user was logged into one company but processing an order from another.

Current behavior before PR:
The function searches for the account.journal using self.company_id.id. Since self in this context (likely a payment provider or transaction record) might be evaluated under the active user's environment context, it fetched the journal from the user's currently active company (allowed_company_ids), disregarding the actual company related to the sale order or the transaction.

Desired behavior after PR is merged:
The invoice journal search uses the correct company context (e.g., order.company_id.id or the specific company linked to the payment record), ensuring that the sale order reference is processed using the appropriate journal from the correct company, regardless of which company the logged-in user is currently switched into.




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

Forward-Port-Of: odoo/odoo#269558

**Steps to reproduce on a new db:**
(bug also reproducable on runbot but the impact 
is less easy to compute because of influence of other
existing companies)

- create a new company as company 2 and use the existing 
default company as company 1.
- create a warehouse for both company
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).
- for both comp, in settings for inventory valuation set 
'periodic' and for periodic valuation set 'daily'

From company 1 : 
- create a storable product with standard price method and 
set a cost of 30
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 30 
  - the variation lines have a balance of 30
  - all of this is expected

From company 2 :
- change the cost of the product to 10
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 10 
  - the variation lines have a balance of 10
  - all of this is expected
 
From any company :
- navigate to 'scheduled actions' and select the action 
'Stock Account: Inventory Valuation Closing'
- click on 'Run Manually'
- navigate to 'inventory valuation'

**Current behavior:**
with company 1 selected :
  - the initial balance is now 30 
  - ending stock still 30
  - no variation lines
  - the initial balance was correctly increased by the closing entry

with company 2 selected: 
  - the initial balance is now 40
  - the ending stock is still 10
  - the variation lines credit 30 in stock valuation

In company 2 the closing entry debitted 40 in stock valuation 
instead of 10 which increased the initial balance to 40 instead of 10

If you open the journal items you'll find the closing amls have a 
balance of 40 instead of 10

**Cause of the issue:**
The _cron_post_stock_valuation() method 
calls action_close_stock_valuation() on both companies
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L143-L144

This methods calls _action_close_stock_valuation
with a context modified with only self.env.company.ids
in 'allowed_company_ids'
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L56

This is needed because inside stock_value() we use 
the total value of the product 
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L92
which will be the sum of the values of the product 
for each company inside allowed_company_id
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/product.py#L274
So in case action_close_stock_valuation() was called from 
the 'generate entry' button from the inventory valuation view
we need only the main company selected to be in the
'allowed_company_ids' so that the inventory value is computed 
based only on this company (as is the accounting value).

The problem is that this does not work when calling the 
method from _cron_post_stock_valuation because then
there is no 'allowed_company_ids' in the context (because it was
called from _process_job() with a new env).
so self.env.company will be the company of the user 
which will be company 1.
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/odoo/orm/environments.py#L243

Therefore when _action_close_stock_valuation will be 
called on company 2, in the context, allowed_company_ids 
will be company 1. Then, when computing 'products', with_company() 
will add self (company 2) to the context.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L151-L152
So stock_value will return the sum of the total_value 
of each product for company 1 and company 2 which is 40 (instead 
of 10 for just company 2)
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L242

We then create the closing accounting entry to match the 
accounting value with the stock value, which explains why 
the new initial accounting balance of company 2 is 40.

**fix:**
We set the context using self instead of self.env.companies
This makes more sense as both in the cron use case and 
the generate entry use case the stock value we want is the 
one of the company in self. 
- In cron use case, it's obvious as the method is called 
in a for loop on each company
- In the generate entry use case, self will also be the main 
company, because it's called, in actionGenerateEntry, 
on this.companyId 
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L75
which is computed based on the get_report_values
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L21
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L28-L30
Which returns the main company
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/report/stock_valuation_report.py#L29


Most importantly, this is also aligned with how the accounting 
values are computed.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L103-L105


opw-6237402

Forward-Port-Of: odoo/odoo#266932

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#269973
Forward-Port-Of: odoo/odoo#265169

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

Forward-Port-Of: odoo/enterprise#118937

Steps to reproduce:
- Start from a database where the eCommerce app is not installed.
- Open the website configurator.
- In the first step, choose "I want an eCommerce".
- In the Pages and Features step, select all Pages.
- Select a theme that adds an eCommerce category snippet, for example "Treehouse".
- Build the website. => During the first `configurator_apply`, `website_sale` is installed
   after the theme and the configured menu items are already created.
=> The homepage rendering then needs a `website_sale` configurator
   snippet template requested by the theme, but it was not generated
   during that first call.
=> The client retries `configurator_apply`. It now succeeds because
   `website_sale` is fully installed, but page and menu creation runs
   again and duplicates the menu items.

Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created.

After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items.

task-5973739

Forward-Port-Of: odoo/odoo#261022

The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities.  `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price.

**Video of the bug:**
https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view

**Issue:**
When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed.

**Reproduction steps:**
- Have a main company
- Create a branch company
- Create a product, configure it as FIFO on both the main company and branch company 
- Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes)
- On the main company, set the product cost to $15 (for demonstrative purposes)
- Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt
- Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect)

**Fix:** 
Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company

Related ticket: opw-6064126

Forward-Port-Of: odoo/odoo#258199