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

# How to reproduce
- Go into any form view of a model with a chatter (e.g. Quotation)
- Add multiple long log notes. You need to be able to scroll enough to not see the last log note
- Click edit on the last log note
- Scroll down to the bottom

# The problem
An empty rectangle is displayed next to the log note in edit mode.

# Cause
The rectangle comes from the NavigableList Component, which is the list that displays suggestions when typing things like "@" or "#" : https://github.com/odoo/odoo/blob/1fd44c3bb11a79d5b6aa72bf7de5a83e6c45be46/addons/mail/static/src/core/common/composer.xml#L137

This components uses the `usePostion()` hook, which purpose is to try to find the most appropriate place to put the element. It will try different postions (e.g. on the left, below, above, etc.) and will pick the most appropriate one. It will then adjust the element's style to position it correctly. It is possible to ask for a preferred position using the options given to the hook. This position will be prioritized over the others if it is suitable. In the case of the NavigableList of the chatter, we give it either 'bottom-fit' or the 'top-fit' positions, wich means it will prefer to be displayed above or below the message : https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/mail/static/src/core/common/composer.js#L449-L459

But in our case, when we scroll back up, the position of the rectangle stays on the left, even though the below space is available. That is because of this commit that introduced a memorization of the last solution :
https://github.com/odoo/odoo/commit/b2b8d2dbb8396d86492a3089db9b1b1545c8f13b https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/position_hook.js#L59-L61

This means that when we scroll down, the bottom positions fails and so the left one is defaulted to. Since the position is memorized, it stays on the left. The issue with this left position is that another commit introduced some logic that made it so if the position is not "top" or "bottom", then we set the element's height to some value : https://github.com/odoo/odoo/commit/702748e2c8e895d372d07f9aeff273282d1b1a99 https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/utils.js#L120-L124

And setting the height of the NavigableList makes it so it displayed even when there are no suggestions inside, because the hiding mechanism of the suggestion list relies on the fact that when there are no suggestions, the div is empty and has no height, so it is hidden.

# Propose solution
We introduce a settings in the options that will allow to skip the memorization of the last position. Since the left position will never be set in the options, no height will be defined.

opw-6172407

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

Forward-Port-Of: odoo/odoo#262822

Steps to reproduce:
===================
1. Configure a Cloudflare Turnstile site key on a 19.2 database.
2. Open `/donation/pay`.

=> Traceback.

Cause:
======
On `/donation/pay` (and any page embedding the donation snippet), the page crashes with `TypeError: Cannot read properties of null (reading 'classList')` in `TurnStile.disableSubmit`, breaking the form for authenticated visitors on databases with a Turnstile site key configured.

The donation page wraps its editor-only custom-fields form in a `<section class="s_website_form">` (introduced by [1]) That inner form has no submit button of its own the actual donation submit happens in the surrounding `payment.form`. The `Form` interaction's selector (`.s_website_form form, form.s_website_form`) nevertheless matches it, so the cf_turnstile patch on `Form.start` runs, queries `.s_website_form_send` / `.o_website_form_send`, gets `null`, and crashes when reading `submitButton.classList`.

Solution:
==========
On master, we fixed this by adding `s_website_form_no_recaptcha`` to the donation section. For stable versions, since the view is noupdate, we used a JS workaround: if there is no submit button, simply skip attaching Turnstile.

[1]: https://github.com/odoo/odoo/commit/dc0618014deace4757f35ee432629a2aa7ebe998

opw-6208466

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

Forward-Port-Of: odoo/odoo#267404

**Steps to reproduce:**
1. Install l10n_mx_hr_payroll.
2. Create an employee with a contract date over 35 years ago (e.g., 1985).
3. Create a payslip for this employee.
4. Click on "Compute Sheet".

```Error: KeyError(36) while evaluating```

**Cause:**
The rule parameter [rule_parameter_holiday_table](https://github.com/odoo/enterprise/blob/c02c4571bb7db7197b07539ba390d4d20fdce9fe/l10n_mx_hr_payroll/data/hr_rule_parameters_data.xml#L722-L758) defines values
only up to 35 years. Seniority exceeding this range causes a KeyError.

**Solution:**
Extended the `rule_parameter_holiday_2024` table from 35 to 60 years,
following the Mexican Federal Labor Law (LFT) reform formula
(+2 days every 5-year milestone from year 6 onwards).

**NOTE:**(Alternative approach)
```python
@staticmethod
def _get_mx_holiday_days(years_worked):
    if years_worked <= 0:
        return 0
    if years_worked <= 5:
        return 12 + (years_worked - 1) * 2
    five_year_periods = (years_worked - 6) // 5
    return 22 + five_year_periods * 2
    
  ```
This approach removes the need for XML data maintenance and handles
all future seniority values mathematically without any cap issues.
  
  
opw-6090590

Forward-Port-Of: odoo/enterprise#113536

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#120322
Forward-Port-Of: odoo/enterprise#112859

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#269570
Forward-Port-Of: odoo/odoo#268568

# How to reproduce
- Activate Accounting & l10n_be modules with demo data
- Use "BE Company CoA"
- Go to Settings > Users & Companies > Companies > "BE Company CoA" > Branches
- Create new branch company
- Go to Settings and Enable PEPPOL, then save
- Still in Settings, click on "Activate Electronic Invoicing" > Activate Peppol (demo)
- Now use the branch company
- In Settings, click on "Activate Electronic Invoicing", select "Send from parent company" > Activate Peppol (demo)
- Go to Settings > Users & Companies > Users > any user (can be the current one)
- Remove the user's access to "BE Company CoA"
- Log in as that user if it is not the current one
- Create a partner that can receive PEPPOL invoices :
	- Country : Belgium
	- Invoice sending : by Peppol
	- eInvoice format : EU Standard (Peppol Bis 3.0)
	- VAT : BE0477472701
	- Peppol id : Belgian Company Registry
- Create an invoice for that partner
- Click on Confirm, then Send

# The problem
You cannot select the "by Peppol" sending method. It has the "(no access)" error attached to it.

# Cause
The sending method's enable state is computed by : https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/account_peppol/wizard/account_move_send_wizard.py#L13

This method runs multiple check to see if the invoice can be send via peppol and one of them calls `_have_unauthorized_peppol_parent_company()` : https://github.com/odoo/odoo/blame/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/account_peppol/models/res_company.py#L136-L143

This checks that the current user has access to the parent company, which is our exact use case. This specific flow was indeed blocked by the task that introduced branch company PEPPOL invoicing : https://github.com/odoo/odoo/commit/6dd8bc34ba79c14408dc271c19ca7afb0f85fa44

The reason behind this block is in part explained by this comment : https://github.com/odoo/odoo/pull/216864#discussion_r2205047170

But after talking with the Peppol PO, this flow should be allowed

# Proposed solution
Entirely remove the `_have_unauthorized_peppol_parent_company()` check. 
After testing, it does not seem we have any access issues to worry about.

opw-6080867

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

Forward-Port-Of: odoo/odoo#262523

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#120098
Forward-Port-Of: odoo/enterprise#109032

Currently, an error occurs when downloading the asset template.

**Steps to Reproduce:**
 - Install the `account_asset` module without demo data.
 - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts`.
 - Open the `Fixed Assets` account, set a `Depreciation` value, and remove the `account code`.
 - Go to `Accounting` > `Accounting` > `Assets & Liabilities` > `Assets`.
 - Click `With our template` on the screen.

`TypeError: startswith first arg must be str or a tuple of str, not bool`

After this [recent commit], account codes became optional and can be removed. As a result, when 
the code is removed from the Fixed Assets account and when donloading the asset template, the 
system checks whether the account name starts with the account code [1]. Since the account 
code is `False`, it raises an error.

This commit ensures that the check is only performed when the account code exists; otherwise, 
the account name is used directly for the asset account.

[recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277

[1]- https://github.com/odoo/enterprise/blob/421fce171dc158faa3b13406b6cea5c1c907ee49/account_asset/controller/asset_template_controller.py#L46-L49

sentry-7487406857

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#120349
Forward-Port-Of: odoo/enterprise#117211

Steps to reproduce
1. Configure a Polish company with KSeF enabled.
2. Create a customer invoice using a tax tagged with K_21 (0% EU G, intra-Community supply of goods), K_12 (0% EU S, services taxed in the buyer's EU country) or Triangular Sale.
3. Send the invoice to KSeF and download the generated FA(3) XML.

Issue
The Podmiot1 (seller) block in the rendered FA(3) XML omits the PrefiksPodatnika element, see https://github.com/odoo/odoo/blob/89219a843545d8bb0cad6ea806a1167cee6289da/addons/l10n_pl_edi/data/fa3_template.xml#L34-L42. According to the official Ministry of Finance documentation (https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf, page 11), this conditional field must carry the value "PL" when the invoice documents:
- the intra-Community supply of goods,
- the provision of services referred to in Article 100 sec. 1 item 1 of the Act for EU VAT taxpayers,
- the supply carried out under a simplified triangular transaction by the second taxpayer (Article 135 sec. 1 item 4 (b) and (c)). The XSD marks the element as optional (minOccurs="0", fixed="PL") so KSeF accepts the XML, but the seller's tax reporting is still legally non-compliant for the three cases above, and the field is missing from the KSeF PDF viewer rendering.

opw-6213178

Forward-Port-Of: odoo/odoo#264659

\* = website

### 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#269287
Forward-Port-Of: odoo/odoo#259893

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#268675
Forward-Port-Of: odoo/odoo#238138

**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#120384
Forward-Port-Of: odoo/enterprise#115256

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#269696
Forward-Port-Of: odoo/odoo#269291