Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Currently an error occurs when there are multiple stock references of same name, and user assigns references on Reception report.

Steps to replicate:
- Install `sale_stock`.
- Load Demo data from Settings.
- From settings, check `Reception Report`.
- Go to Operations > Reference > S00004 > Duplicate it (from the form view).
- Open Receipts > WH/IN/00002 > Allocation (Smart button) > Click 'Assign All' or the S00004 line.

Error:
```
File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 271, in action_assign
    self._action_assign(in_move, out)
  File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 343, in _action_assign
    in_move._get_source_document()._add_reference(out_ref)
  File "/home/odoo/odoo18/community/addons/stock/models/stock_picking.py", line 2102, in _add_reference
    self.move_ids.reference_ids = [Command.link(reference.id)]
  File "/home/odoo/odoo18/community/odoo/orm/fields_misc.py", line 112, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.reference(3, 19)
```

Cause:
- As the user duplicated the record, there were two records received in the variable `reference` at [1] that caused the expected singleton error.

Solution:
- The methods `_add_reference()` and `_remove_reference()` can now handle multiple reference records.

[1]: https://github.com/odoo/odoo/blob/4b2154870eebcce449f53d8f593386ae6af04a83/addons/sale_stock/models/sale_order.py#L329

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

Before this commit, rendering BuilderList with many elements caused noticeable delays.

How to reproduce:
=======================
- Use a runbot with all demo data
- Switch to edit mode in the website builder
- Add a form
- Link the form to the Contact model
- Add the "State" field

Before this commit:
The options related to the "State" field took more than one second to render.

After this commit:
Rendering is several hundred milliseconds faster. Additional commits will follow to further improve the situation.

Reason for the slowdown:
=======================
BuilderList is not optimized to render several thousand records (about 1900 in this example). This commit addresses the identified bottlenecks to reduce rendering time.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#237462

- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF.
This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default.
As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download —
since the invoices weren’t sent and no fallback was allowed.

**Steps to reproduce:**
**1:** Go to Invoices
**2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page

**What this patch does:**
- It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful.

**Possible improvements to consider:**
**1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore.

**2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once.

**3:** Instead of showing a blank page for non-sent invoices, show a user-friendly
 error message. (I noticed this was in the original commit
odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was
 introduced but was later removed — not sure why.)

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

Forward-Port-Of: odoo/odoo#234886

Currently, if a user overpays while using a different language, like French, the receipt does not show the change.

**Steps to replicate:**
* Install POS with demo data and change language to French .
* POS > Furniture Shop > Open the register
* Select a product, overpay with cash, and validate.

**Issue:**
* As seen in [1], the `Change` field doesn’t appear when overpaying with cash, even though it shows in the English version.

**Root cause:**
* The issue happens because changing the language translates the payment line name at [2] (coming from the translated return at [3]). This makes it get included in the sum at [4], which incorrectly subtracts it from the total cash paid and causes the change amount to disappear on the receipt.

**Solution:**
* Check and add up the payment lines where `is_change` is `false`, and use that instead of relying on the payment line’s name at [3].

**Before:**
<img width="830" height="556" alt="image" src="https://github.com/user-attachments/assets/5aaddfe0-fe46-49e1-a877-4fe4de2fb5c7" />

**After:**
<img width="931" height="596" alt="image" src="https://github.com/user-attachments/assets/4215d6b8-14b4-4e59-85bc-4d0f43f1d09c" />

[1]:
https://www.odoo.com/web/image/91240289?access_token=bef22d9abd1232e34f510648a34f7709d82b848ed852fccdb893f2d1149067abo0x69505fa6&filename=image.png&unique=dd2a62fbe180532cf5cf00c27adc60742f113ddc 
[2]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L146 
[3]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/models/pos_order.py#L188-L195 
[4]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L147

opw-5344903

**Steps to reproduce:**
1. Open database with version 19.0
2. Install module l10n_fr_hr_payroll_with_accounting
3. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
4. In Payroll app create a payslip for any employee
5. In `structure` Employee cadre be choosen, And also
6. Make sure in salary inputs you make new type and in that in the
`availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

After this changes in the [commit](https://github.com/odoo/enterprise/pull/100112/files) you will face another issue for which the steps are there in steps to reporduce.

In this [commit](https://github.com/odoo/enterprise/commit/bd2ee7546df3f31c73e8aaae0244ac6767f982fb#diff-5b26ac7c31dbf0286aa98671d7dadb50c117ea2ffb0d52d55a8f4e5d16d7ee88R709) Instade of `company_id` there is `company_20id`, which is not valid field. As in this code:
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/models/res_config_settings.py#L11 we can see that `company_id ` is set as related field for nombre_employes, so I have changed from `company_20id ` to `company_id`

**opw**: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

**Steps to reproduce:**
* Install the **pos_sale** module.
* In **Settings**, enable the *Units of Measure & Packagings* option.
* Create two products, each using a different **Unit of Measure** (e.g., *Unit*, *Hours*),
and ensure both are available in POS.
* Open the **Sales** app and create a quotation including both products. Confirm the order.
* Open the **POS Store** and go to **Quotation/order** options , and select
*Created Sale Order* with the option **Settle the order**.
* Proceed to the payment screen and attempt to validate the payment.

**Observed behavior:**
* A **singleton error** is raised when validating the payment for a sale order
containing multiple lines with different UoMs.

**Cause:**
* The code incorrectly passes `self`, which may contain multiple sale order lines,
leading to a singleton expectation failure.

**Fix:**
* Pass a single sale order line to avoid the singleton error during payment validation.
---
opw-5251840

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

Currently, an error occurs when a user replaces a `combo product` with another 
product in a sale order line before the order is saved.

**Steps to produce:**

- Install the `sale_management` module with demo data.
- Open `sale order`, click `Add a product`, and add a `combo product` (Office Combo). 
  (`Make sure the form is not saved`)
- Click on the `combo name` (Office combo x 1) and replace it with another product.

**Error:**
`IndexError: tuple index out of range`

**Root cause:**
After PR [1], at [2], when a combo product is replaced before the order is
saved, the code attempts to update the combo item lines even though the
template type (`product_template_id.type`) is not `combo`. This leads to an
update of `product_uom_qty`, which triggers the `_compute_price_unit` method
and results in the error at [3].

**Fix:**
This commit prevents errors when a user replaces a combo product with another product.

[1]:
https://github.com/odoo/odoo/pull/194496

[2]:
https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/addons/sale/models/sale_order.py#L966-L970

[3]:
https://github.com/odoo/odoo/blob/c758b93a57cd98ab76c26c03bd0097f2eef50961/addons/sale/models/sale_order_line.py#L766

sentry-7009976704

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.

<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />

This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.

https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34

By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.

### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
    - Set any Vendor
    - Set any Bill Date
    - Add any Product (with a positive price, the total price of the bill must be positive)
    - Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.

This fix moves the date right above the table.

<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />


opw-5165112

Forward-Port-Of: odoo/enterprise#100487

**Steps to Reproduce the Issue**:

1. Install the following apps in version 19.0 database:
   * stock_account
2. Go to Settings → enable Lots & Serial Numbers.
3. Open the Inventory app, then go to Products and create a new product
with the following configuration:
   * Product Type: Goods
   * Track Inventory: By Unique Serial Number
   * Inventory tab: Enable Valuation by Lot/Serial
   * General Information tab: Create a new Product Category with:
     * Costing Method: AVCO (Average Cost)
4. Go to Products → Lots/Serial Numbers.
5. Create a new Lot/Serial Number and select the product you just created, then
click Save.
6. Now update the Cost in the Lot/Serial Number form and click Save again.
7. You will now encounter the trackback error.

**Description:**

In the [commit](odoo@22b9e1a#diff-2623d0e4c393b65afe1c6d00f55af80d19f022aaeb0da0e5e173e37a84138159R42) The `lot_id` is written but in `stock.move` model there is `lot_ids` [field]((https://github.com/odoo/odoo/blob/6496653de3c9bb2a3cde8e38fdda8fb7abe27713/addons/stock/models/stock_move.py#L189)) so it gives error `keyerror`.
Now i have used [`lot_id`](https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/stock/models/stock_move_line.py#L48) field of `stock.move.line` for mapping the `move_id` so that after price adjustment correct move value is set.

opw-[5266457](https://www.odoo.com/odoo/project/70/tasks/5266457)



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

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
We add a new field on the `pos.order` model to retain if that order was previously invoiced with a simplified invoice, in that case, we set its type to 'F3' instead of 'F1' when fully invoicing it.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

When using small UI, the composer of Discuss is quite low. This is a problem especially with iPhones that have heavily rounded courners for which some content is cut and thus make it hard to use.

One solution is to add some bottom margin, but it needs to be removed when composer is focused otherwise it's too high with soft keyboard. That was the strategy we used, but it has been reverted [1] because this makes clicking on the "Send" button unreliable, due to the jump of send button when moving vertically, which made OWL not register the click on the button.

This commit makes the composer bigger on small UI, so that although the bottom might be cut like on iPhones, at least the bigger size of the composer makes it less of a problem.

Also the bigger size is welcome: with touch devices, the input is now vertically sized for touch interaction, of about 44px, which is close to recommended 48px.

[1]: https://github.com/odoo/odoo/pull/226546

Before / After
<img width="284" height="616" alt="Screenshot 2025-11-27 at 15 23 33" src="https://github.com/user-attachments/assets/ff9a3b42-078b-4e4f-a1c5-4d5828f7bb56" /> <img width="284" height="616" alt="Screenshot 2025-11-27 at 15 22 32" src="https://github.com/user-attachments/assets/f9fcb6c7-08f0-4cff-a578-648cf7866050" />

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

Forward-Port-Of: odoo/enterprise#98808

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)

Forward-Port-Of: odoo/odoo#237060

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#236450
Forward-Port-Of: odoo/odoo#225014

In the stock.picking form, we can modify the `lot_id` of the product we deliver to the customers. Since 19.0, the edited `lot_id` wasn't saved properly, leading to the original `lot_id` being used when confirming the delivery.

### Steps to reproduce:

1. Install the Stock (`stock`) app.
2. Enable the *Lots & Serial Numbers* traceability settings.
3. Create a product tracked *By Unique Serial Number*
4. Create a quotation with a line that includes the product tracked by unique serial number
5. Confirm the quotation
6. Click on the *Delivery* smart button
7. Display the *Serial Numbers* column in the list view
8. Update the Serial Number of the product (remove the original serial number, then add a new one)
9. Click *Validate*, or *Save manually* and reload the page
10. The Serial Number set in step 8 is replaced by the original one

The condition at the start of the `StockMove._set_lot_ids` method was preventing the `stock.move.line` from being updated. In the context of this issue, at the moment of execution, the `stock.move.line` still has the original `lot_id`, but it should be updated to the `lot_id` set by the user. This update does not occur because of the condition.

https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_move.py#L606-L607

After applying this fix, the serial number set by the user is correctly saved and used when clicking the *Validate* button on the stock picking form.

opw-5169690

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Forward-Port-Of: odoo/odoo#237874
Forward-Port-Of: odoo/odoo#235112

Before this PR:
- Auto focus on a participant’s video when joining a call did not trigger due 
to a typo in the find() callback, causing it to always return undefined.
- The video-focus-on-join feature was only conditioned on the call component 
not being shown in the Discuss desktop view. This does not handle the cases 
when call is in meeting view or PiP view
- The video-focus-on-join feature only ran at call join time. In one-one calls, 
when the other participant turned on their camera after the call started, 
their video was not focused even when auto-focus was enabled
- When any participant had video enabled, the call component could overflow 
the chat window, causing an unwanted horizontal scrollbar.

This PR:
- Fixes the find() callback typo so the active streaming session is correctly 
detected and auto-focused when joining a call.
- Updates the video-focus-on-join conditions to support all intended layouts: 
    1. mobile (small UI)
    2. chat window
    3. PiP window.
- Extends the video-focus-on-join feature: in one-one calls, when the other 
participant turns on their camera mid-call, their video is now automatically 
focused (when auto-focus is enabled and the above layout conditions are met).
- Fixes layout overflow by preventing the call component from exceeding the 
chat window width.

Before / After fix (overflow issue):
<img width="300" height="640" alt="image" src="https://github.com/user-attachments/assets/a291949f-5a82-4c0c-a3c3-d31078e2e62e" /> <img width="300" height="640" alt="image" src="https://github.com/user-attachments/assets/f8405be4-e200-416b-b582-ecc057a0f9a3" />


part of task-[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387)