When finishing a repair order a stock valuation entry is created for the
product used. If you then make a quotation and invoice it another
stock valuation entry would be created for the same product.

Steps to reproduce:
-------------------
* Create a category using FIFO and real time valuation
* Create a product using this category and set it's cost to 5€
* Set some on hand quantity for the product
* Create a repair order and add the product with the "Add" option
* Finish the repair order
> Observation: At this point you should have a valuation entry in the
  accouting app
* From the repair order create a quotation and invoice it
> Obesrvation: If you check the accounting entries again you will see
  a second valuation entry

Why the fix:
------------
When checking if the line is eligible for valuation we make sure that if
it is linked to a repair order, this repair order should not have any
accounting entries linked to it.

opw-5429996

Forward-Port-Of: odoo/odoo#254468

#### Description of the issue/feature this PR addresses:
The "Stock Account: Inventory Valuation Closing" cron is meant to post valuation journal entries for companies configured with periodic inventory valuation. Due to a faulty domain in ResCompany._cron_post_stock_valuation, monthly companies are never processed, and on the last day of the month daily companies are also skipped. As a result, no inventory valuation journal entries are ever generated by this cron for periodic-valuation companies.

#### Current behavior before PR:
The cron's domain requires inventory_period = 'daily', which excludes monthly companies on every non-last day of the month. On the last day of the month, an extra AND clause is added requiring inventory_period = 'monthly'. Combined with the existing 'daily' clause, this produces a contradiction (period = 'daily' AND period = 'monthly') that matches no records, so daily companies are dropped on that day as well. Net effect: monthly companies are never processed, and daily companies are skipped on month-end.

#### Desired behavior after PR is merged:
On a non-last day of the month, the cron processes companies with inventory_period = 'daily'. On the last day of the month, the cron processes both 'daily' and 'monthly' companies, so monthly valuation entries are posted at month-end without dropping daily companies.

opw-6115649

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

Forward-Port-Of: odoo/odoo#266465
Forward-Port-Of: odoo/odoo#264298

Currently an error occurs when the user tries to submit a WhatsApp
template for approval with a header type image.

Steps to produce an Error:
- Install the whatsapp module
- Create a new WhatsApp template as below
    - Header Type =  `Image`
    - Upload any image in `Template Static Header`
    - Fill in required fields
- Error occurs when click `Submit for Approval`

Error `TypeError: object of type 'LocalBinaryFile' has no len()`

This happens because of the recently refactored changes with [1]
`attachment.raw` now contains a `LocalBinaryFile` object instead
of a raw binary value. As a result, using the object directly in the
request at code line[2] (data) causes an error. 

This commit fixes the above error by using `attachment.raw.content`,
which passes the actual image binary content in the request instead
of the `LocalBinaryFile` object.


[1]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1
[2]: https://github.com/odoo/enterprise/blob/28bd32718cd147093c9d56d79dce87ff32d44508/whatsapp/tools/whatsapp_api.py#L56


Sentry-7516083183

Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion.

However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks.

This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load.

Steps to reproduce:
- Use Firefox (or a Gecko-based browser)
- Open a new mailing
- Select the Events theme and make an edit (add a space...)
- Save the mailing
- Wait for 23 seconds

The bug may be non-deterministic.

Fix:

Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs.

task-6293998

Co-authored-by: Damien Abeloos <abd@odoo.com>

Forward-Port-Of: odoo/odoo#269324

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Self-order showed one price on product cards / product page and another after adding to the order, when a preset fiscal position (e.g. take-out) changed taxes. The UI used template-only pricing and sometimes skipped fiscal position on tax computation.

Steps to reproduce:
-------------------
* Create a fiscal Position (e.g. takeout)
* Create a Taxe for that Fiscal Positions replacing the default Taxe (e.g. 0%)
* Create a pricelist with a formula increasing the price by the same % as default Taxe (e.g. 15%)
* Enable Self-Ordering for a Restaurant
* In the takeout Presets, set our Pricelist and Fiscal Positions
* Open the Mobile Menu of the Restaurant and add a product that has variants (e.g Pizza VG)

> Observation:
Price on product selection is different from price in cart

Why the fix:
------------
We now make self-order use the same rules as an actual order: default variant for template-only display, pricelist from pos.order first (what setPreset and the session already maintain), fiscal position from the order or the preset everywhere taxes are derived, and correct tax inputs on the product page (price, pricelist, fiscalPosition, variant).
Order line tax preparation now uses that same order-or-preset fiscal position, so remapped taxes apply to lines the same way they apply to the prices shown while browsing.

opw-6120097

Forward-Port-Of: odoo/odoo#261535

**Step to reproduce**
Reproducible in single app

The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
            "product_id": no_variant_product_tmpl.product_variant_id.id,
            "name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126

**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.

breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265 
runbot-242362

Forward-Port-Of: odoo/odoo#268016

Currently when using a stripe terminal and the tips after payment feature the transaction is marked as cancelled while the transaction is marked as uncapured on stripe.

Steps to reproduce:
-------------------
* Set up terminal payment (using SIMULATOR works)
* Enable tips after payment feature
* Open restaurant
* Make an order
* Go to payment screen, select stripe
* Scan card (with simulator everything is automatic)
> Payment line is marked as cancelled

Why the fix:
------------
After this commit https://github.com/odoo/odoo/commit/c27deda808660dde89305d574b6d662157d99d16 if `captureAfterPayment` does not return true the status of the payment line will be set to `retry`.

However when pos_restaurant_stripe is also installed `captureAfterPayment` can return `undefined` when tips after payment is enabled. https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/pos_restaurant_stripe/static/src/overrides/models/payment_stripe.js#L5-L11

In this case we want to capture later and we expect the pethod to not return anything. In this case we don't want to change the status of the payment line.

opw-6223838

Forward-Port-Of: odoo/odoo#268802

Archiving guest contacts upon SO validation breaks mail confirmations for related pickings.

When a guest contact is archived, the ORM automatically filters it out from any search
https://github.com/odoo/odoo/blob/e8a372b71dc91a3e3649e572380f59ee648c5bdc/odoo/orm/fields_relational.py#L673-L677
As a result, the partner is silently dropped from the `partner_ids` Many2Many on the mail composer even though we do write it
https://github.com/odoo/odoo/blob/e8a372b71dc91a3e3649e572380f59ee648c5bdc/addons/mail/wizard/mail_compose_message.py#L538-L539
and the picking confirmation email is never sent.

A potential fix would have been to disable this filtering at the ORM level but that would have impacted any flow that relies on archived partners being excluded.

This reverts commit 3a20ff382d164f05d3d6b66e94318ed80aaa41cc.

This reverts commit 64d9ded9637286ef0cfd9e65ba7c60d4f48d6c16.

This reverts commit ef10f93b77263836815034e15bae6cddbd38c4f9.

opw-6232937

Forward-Port-Of: odoo/odoo#268568

When finishing a repair order a stock valuation entry is created for the
product used. If you then make a quotation and invoice it another
stock valuation entry would be created for the same product.

Steps to reproduce:
-------------------
* Create a category using FIFO and real time valuation
* Create a product using this category and set it's cost to 5€
* Set some on hand quantity for the product
* Create a repair order and add the product with the "Add" option
* Finish the repair order
> Observation: At this point you should have a valuation entry in the
  accouting app
* From the repair order create a quotation and invoice it
> Obesrvation: If you check the accounting entries again you will see
  a second valuation entry

Why the fix:
------------
When checking if the line is eligible for valuation we make sure that if
it is linked to a repair order, this repair order should not have any
accounting entries linked to it.

opw-5429996

Forward-Port-Of: odoo/odoo#254468

Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion.

However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks.

This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load.

Steps to reproduce:
- Use Firefox (or a Gecko-based browser)
- Open a new mailing
- Select the Events theme and make an edit (add a space...)
- Save the mailing
- Wait for 23 seconds

The bug may be non-deterministic.

Fix:

Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs.

task-6293998

Co-authored-by: Damien Abeloos <abd@odoo.com>

Forward-Port-Of: odoo/odoo#269324

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


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120175
Forward-Port-Of: odoo/enterprise#112859

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Self-order showed one price on product cards / product page and another after adding to the order, when a preset fiscal position (e.g. take-out) changed taxes. The UI used template-only pricing and sometimes skipped fiscal position on tax computation.

Steps to reproduce:
-------------------
* Create a fiscal Position (e.g. takeout)
* Create a Taxe for that Fiscal Positions replacing the default Taxe (e.g. 0%)
* Create a pricelist with a formula increasing the price by the same % as default Taxe (e.g. 15%)
* Enable Self-Ordering for a Restaurant
* In the takeout Presets, set our Pricelist and Fiscal Positions
* Open the Mobile Menu of the Restaurant and add a product that has variants (e.g Pizza VG)

> Observation:
Price on product selection is different from price in cart

Why the fix:
------------
We now make self-order use the same rules as an actual order: default variant for template-only display, pricelist from pos.order first (what setPreset and the session already maintain), fiscal position from the order or the preset everywhere taxes are derived, and correct tax inputs on the product page (price, pricelist, fiscalPosition, variant).
Order line tax preparation now uses that same order-or-preset fiscal position, so remapped taxes apply to lines the same way they apply to the prices shown while browsing.

opw-6120097

Forward-Port-Of: odoo/odoo#261535

**Step to reproduce**
Reproducible in single app

The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
            "product_id": no_variant_product_tmpl.product_variant_id.id,
            "name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126

**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.

breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265 
runbot-242362

Forward-Port-Of: odoo/odoo#268016

Currently when using a stripe terminal and the tips after payment feature the transaction is marked as cancelled while the transaction is marked as uncapured on stripe.

Steps to reproduce:
-------------------
* Set up terminal payment (using SIMULATOR works)
* Enable tips after payment feature
* Open restaurant
* Make an order
* Go to payment screen, select stripe
* Scan card (with simulator everything is automatic)
> Payment line is marked as cancelled

Why the fix:
------------
After this commit https://github.com/odoo/odoo/commit/c27deda808660dde89305d574b6d662157d99d16 if `captureAfterPayment` does not return true the status of the payment line will be set to `retry`.

However when pos_restaurant_stripe is also installed `captureAfterPayment` can return `undefined` when tips after payment is enabled. https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/pos_restaurant_stripe/static/src/overrides/models/payment_stripe.js#L5-L11

In this case we want to capture later and we expect the pethod to not return anything. In this case we don't want to change the status of the payment line.

opw-6223838

Forward-Port-Of: odoo/odoo#268802

When finishing a repair order a stock valuation entry is created for the
product used. If you then make a quotation and invoice it another
stock valuation entry would be created for the same product.

Steps to reproduce:
-------------------
* Create a category using FIFO and real time valuation
* Create a product using this category and set it's cost to 5€
* Set some on hand quantity for the product
* Create a repair order and add the product with the "Add" option
* Finish the repair order
> Observation: At this point you should have a valuation entry in the
  accouting app
* From the repair order create a quotation and invoice it
> Obesrvation: If you check the accounting entries again you will see
  a second valuation entry

Why the fix:
------------
When checking if the line is eligible for valuation we make sure that if
it is linked to a repair order, this repair order should not have any
accounting entries linked to it.

opw-5429996

Forward-Port-Of: odoo/odoo#254468

Report edits could be applied on shared layouts such as web.basic_layout instead of the report-specific document view.

This caused Studio customization diffs to affect unrelated reports and could also lead to rendering errors when report-specific fields were evaluated in a different report context.

The issue occurred because content was inserted directly into the shared layout article section instead of the nested report document view.

Steps to reproduce:
1. Open Studio on any module and create or edit a report.
2. Select any of the External, Minimal, or Blank report types.
3. Add content to the report body and save the report.
4. Open another module and create a report using the same report type.
5. Observe that the previous customization is already present.

Before this fix, the generated diff could inherit from web.basic_layout. After this fix, body edits are kept inside the report-specific document view.

Related Ticket:
opw-6245485

Forward-Port-Of: odoo/enterprise#118880

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


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120175
Forward-Port-Of: odoo/enterprise#112859

Steps to reproduce:
-------------------
1. Install Fleet with demo data.
2. Create a contract for a vehicle (A) with a recurring cost of 1000
 and "Monthly" frequency.
3. Go to Reporting > Costs and verify the monthly cost
 (it shows 1000).
4. Create another contract for the same vehicle (A) with a
 recurring cost of 50 and "Monthly" frequency.
5. Check the monthly cost again.

Issue:
------
The reported cost is incorrect. Instead of 1050 (1000 + 50), it shows 2100.

Cause:
------
The query uses multiple LEFT JOINs on the contract table, including:
https://github.com/odoo/odoo/blob/9ca36dbe53692309bac84329de3b54a1c510cce0/addons/fleet/report/fleet_report.py#L103

These joins overlap and produce duplicate rows for the same
vehicle and month, which results in inflated cost totals.

Solution:
---------
Replace the multiple LEFT JOINs with a single LATERAL join.
This ensures the contract table is processed once per vehicle per month and
avoids duplication, resulting in correct totals.

**Before:**
<img width="940" height="609" alt="image" src="https://github.com/user-attachments/assets/e5b3e747-1135-4674-97c9-4e4fd9986dfd" />

**After:**
<img width="1053" height="590" alt="image" src="https://github.com/user-attachments/assets/f0df3819-07fb-4de5-aab3-5b4c6f10d213" />



opw-6024132





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

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120011
Forward-Port-Of: odoo/enterprise#115256

\* = website, website_crm

### Issue:
When a page is created either through the configurator or from an
existing page template, block-level snippets do not display the correct
title in the builder sidebar. Instead, "Block" is shown for all
snippets.

### Steps to Reproduce:

- **Configurator:**
  1. Install the website module or create a new website from Settings.
  2. Complete all configurator steps. Do not use "Skip and start from
     scratch".

- **Page template:**
  1. Open the website and click the "New" button in the systray.
  2. Click on "Page" and choose any template other than a blank page.

### Observed behavior:
The builder sidebar shows "Block" in the option container for all
snippets instead of their actual names.

### Reason:
Previously, just before the builder was opened, the `data-name`
attribute was injected through `_computeSnippetTemplates()` for any
snippet that did not already have it. This behavior was lost after the
plugin refactoring.

### Fix:
As before, we now inject the `data-name` attribute during builder setup
for snippets that do not already have it.

task-[6087348](https://www.odoo.com/odoo/all-tasks/6087348)

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

Forward-Port-Of: odoo/odoo#268637
Forward-Port-Of: odoo/odoo#259893

[FIX] ai: scope AI_ADJUST_SEARCH bus event to originating session
The AI_ADJUST_SEARCH handler did not check aiSessionIdentifier, so any
browser tab subscribed to the bus would apply the AI's resulting search
to its current view. When the view's model lacked a field referenced in
the response (e.g. an "Active or Queue" filter on stage_id leaking from
a project.task chat into a timesheet view), the view raised a KeyError.
Align it with the four AI_OPEN_MENU_* handlers, which already drop events
from other sessions since https://github.com/odoo/enterprise/commit/d85e17d9ccf70f9cfd51c7d6b2a5b52510807484.

Steps to reproduce:
- Run Odoo with the crm and contacts modules installed
- Open two tabs:
    - Tab 1: navigate to CRM and ensure you are in List view
    - Tab 2: navigate to Contacts and ensure you are also in List view
- In Tab 1 (CRM), open the Ask AI chat and type "Switch to Kanban view"
- CRM switches to Kanban view as expected
- Bug: Tab 2 (Contacts) also switches to Kanban view along with Tab 1,
  even though you did not interact with it

Forward-Port-Of: odoo/enterprise#118237

Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion.

However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks.

This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load.

Steps to reproduce:
- Use Firefox (or a Gecko-based browser)
- Open a new mailing
- Select the Events theme and make an edit (add a space...)
- Save the mailing
- Wait for 23 seconds

The bug may be non-deterministic.

Fix:

Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs.

task-6293998

Co-authored-by: Damien Abeloos <abd@odoo.com>

Forward-Port-Of: odoo/odoo#269324

**Issue**
In the shop floor, floating-point values may display excessive decimals.

**Steps to reproduce**
- Create a BoM for a product, with a component tracked by lots
- Set the component to be consumed in a work order operation
- Create several lots for the component, per ex 2:
	- LOT01 with 16.528 units
	- LOT02 with 10,000.00 units
- Create an MO for 220.800 units of the finished product
- Click on the shopfloor icon
- Click to register the component consumption for the component.
- Choose the first lot
- Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits.

**Cause**
Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 
inducing a floating-point precision error.
The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding.

opw-6243804

Forward-Port-Of: odoo/enterprise#118976

Self-order showed one price on product cards / product page and another after adding to the order, when a preset fiscal position (e.g. take-out) changed taxes. The UI used template-only pricing and sometimes skipped fiscal position on tax computation.

Steps to reproduce:
-------------------
* Create a fiscal Position (e.g. takeout)
* Create a Taxe for that Fiscal Positions replacing the default Taxe (e.g. 0%)
* Create a pricelist with a formula increasing the price by the same % as default Taxe (e.g. 15%)
* Enable Self-Ordering for a Restaurant
* In the takeout Presets, set our Pricelist and Fiscal Positions
* Open the Mobile Menu of the Restaurant and add a product that has variants (e.g Pizza VG)

> Observation:
Price on product selection is different from price in cart

Why the fix:
------------
We now make self-order use the same rules as an actual order: default variant for template-only display, pricelist from pos.order first (what setPreset and the session already maintain), fiscal position from the order or the preset everywhere taxes are derived, and correct tax inputs on the product page (price, pricelist, fiscalPosition, variant).
Order line tax preparation now uses that same order-or-preset fiscal position, so remapped taxes apply to lines the same way they apply to the prices shown while browsing.

opw-6120097

Forward-Port-Of: odoo/odoo#261535

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#113133

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#119164
Forward-Port-Of: odoo/enterprise#109032

Currently when using a stripe terminal and the tips after payment feature the transaction is marked as cancelled while the transaction is marked as uncapured on stripe.

Steps to reproduce:
-------------------
* Set up terminal payment (using SIMULATOR works)
* Enable tips after payment feature
* Open restaurant
* Make an order
* Go to payment screen, select stripe
* Scan card (with simulator everything is automatic)
> Payment line is marked as cancelled

Why the fix:
------------
After this commit https://github.com/odoo/odoo/commit/c27deda808660dde89305d574b6d662157d99d16 if `captureAfterPayment` does not return true the status of the payment line will be set to `retry`.

However when pos_restaurant_stripe is also installed `captureAfterPayment` can return `undefined` when tips after payment is enabled. https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/pos_restaurant_stripe/static/src/overrides/models/payment_stripe.js#L5-L11

In this case we want to capture later and we expect the pethod to not return anything. In this case we don't want to change the status of the payment line.

opw-6223838

Forward-Port-Of: odoo/odoo#268802

Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

Forward-Port-Of: odoo/odoo#268886
Forward-Port-Of: odoo/odoo#267479

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#113133

When reloading a chart of accounts, `_pre_reload_data` resolves an account via its xmlid and then evaluates:
```py
    re.match(f'^{values["code"]}0*$', account.code)
```
`account.code` is a non-stored computed field that reads from the company-dependent field `code_store`. If the resolved account has no `code_store` entry for the target company (e.g. the account was originally set up under a different company but its xmlid was prefixed with the current company id), `_compute_code` returns False instead of a string, causing a TypeError in re.match.
```py
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 442, in _pre_reload_data
    if not account or not re.match(f'^{values["code"]}0*$', account.code):
  File "/usr/lib/python3.10/re.py", line 190, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object
```
```sql
apan_4342860=> SELECT
    aa.id,
    aa.code_store,
    imd.module,
    imd.name
FROM account_account aa
JOIN ir_model_data imd
    ON imd.res_id = aa.id
   AND imd.model = 'account.account'
WHERE aa.id = 1056;
  id  |   code_store    | module  |      name
------+-----------------+---------+-----------------
 1056 | {"2": "510500"} | account | 1_co_puc_510500
(1 row)
```

This situation arises when a customer moves or reassigns an account between companies but the xmlid retains the original company prefix.

**Fix:**
After resolving the account via xmlid, check whether it actually belongs to the target company using filtered_domain with _check_company_domain. If it does not pass the check, unlink the stale ir.model.data entry and treat the account as not found, allowing the reload to re-establish the correct xmlid linkage via the code-based lookup that follows.

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

Forward-Port-Of: odoo/odoo#269291

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

Ticket [link](https://www.odoo.com/odoo/project.task/5117571)
opw-5117571

Forward-Port-Of: odoo/odoo#238138

Steps to reproduce
1. With a Mexican POS configured, create a POS order and sign a Global Invoice for it.
2. Open a new session and partially return the order; close the session.
3. On the original order, cancel the Global Invoice through the CFDI page.
4. Try to create a new Global Invoice for the original order.

Issue
The wizard raises "Orders <REFUND-NAME> are already sent or not eligible for CFDI."

Validating the refund auto-signs an `invoice_sent` CFDI on the refund pos.order because its parent is `global_sent`, see `_l10n_mx_edi_check_autogenerate_cfdi_refund` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L98. Cancelling the GI only flips its own document to `ginvoice_cancel`; the refund's `invoice_sent` doc stays untouched, so the refund's computed `l10n_mx_edi_cfdi_state` stays `'sent'`. The chain check in `_l10n_mx_edi_check_orders_for_global_invoice` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L184 then rejects the refund as already sent and the new GI cannot be created.

opw-6181136

Forward-Port-Of: odoo/enterprise#120100
Forward-Port-Of: odoo/enterprise#117211

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#113133

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#119017
Forward-Port-Of: odoo/enterprise#118773

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#119098
Forward-Port-Of: odoo/enterprise#118714

#### Description of the issue/feature this PR addresses:
Opening the Asset Depreciation Schedule report with a period comparison enabled crashes with KeyError: 'no_format' when prefix grouping is active (large number of assets in one account group). The report becomes unusable for affected customers.

#### Current behavior before PR:
_regroup_lines_by_name_prefix sums each subline column by indexing prefix_subline['columns'][i]['no_format'] directly. Empty columns are built as {} by _build_column_dict (both col_value and col_data are None), so they have no 'no_format' key. With a comparison period enabled, an asset that has no value in the comparison period produces an empty column for that period; once prefix grouping fires (len(lines) >= prefix_groups_threshold, default 4000), the direct lookup hits that empty dict and raises KeyError: 'no_format'.

#### Desired behavior after PR is merged:
The prefix group total treats a missing 'no_format' as 0, matching the sibling caller in account_asset/models/account_assets_report.py that already guards with .get('no_format', 0). The report builds without crashing and the empty comparison column contributes 0 to the prefix group total.

opw-6225639

Forward-Port-Of: odoo/enterprise#119775
Forward-Port-Of: odoo/enterprise#119088

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#113133

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

Ticket [link](https://www.odoo.com/odoo/project.task/5117571)
opw-5117571

Forward-Port-Of: odoo/odoo#238138