To reproduce error.
1) make a new interview record
2) make sure user has interview group but not survey group 3) try to access/make an interview record.

convert_to_cache returns none when it is passed an empty list see link below:
https://github.com/odoo/odoo/blob/b16aaff17a65987c958c3285157ef1e4443e864f/odoo/orm/fields_misc.py#L71

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 279, in __call__
    response = serve_db(request)
               ^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 443, in serve_db
    raise _update_served_exception(request, exc)
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 441, in serve_db
    return retrying(serve_func, env=request.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/retrying.py", line 52, in retrying
    result = func()
             ^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 593, in serve_ir_http
    response = request.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/dispatcher.py", line 311, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/service/model.py", line 55, in call_kw
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2084, in onchange
    snapshot1 = RecordSnapshot(record, fields_spec)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2170, in __init__
    self.fetch(name)
  File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2185, in fetch
    self[field_name] = self.record[field_name]
                       ~~~~~~~~~~~^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 6130, in __getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1815, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1986, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-19.3/addons/mail/models/mail_thread.py", line 502, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4340, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 82, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/addons/hr_recruitment_survey/models/survey_survey.py", line 19, in _compute_allowed_survey_types
    survey.allowed_survey_types = [*survey.allowed_survey_types, 'recruitment']
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool

```

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

Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`:

* **Redundant updates** were performed on `location_dest_id` in the move lines and the package levels (which internally update all related move lines too), even when the location remained unchanged.
* The main loop inside `_check_entire_pack` was **O(N^2)** time relative to the number of move lines due to internal filtering logic.
* **Cache misses** triggered unnecessary SQL queries when retrieving `move_line_ids` from `package levels`, while they are already cached via the pickings and can be grouped by `package_level`.

---

### Benchmark
Benchmark conducted on a customer database with **400k** `stock_move_line` records within **800** `pickings`, testing performance of the action `StockQuant.action_validate` with different sizes of move lines. Each test was run multiple times and shown is the average mean, all with negligible variance.

| Metric | Before | After | Delta |
| :--- | :--- | :--- | :--- |
| **Benchmark (1k lines)** | 10.5s | 2.2s | -80% |
| **Benchmark (5k lines)** | 121s | 8.5s | -93% |
| **Benchmark (50k lines)** | 887s | 56s | -94% |
| **Benchmark (400k lines)** | timeout | 777s | (within time limit) |

**OPW-6045513**

Forward-Port-Of: odoo/odoo#262717
Forward-Port-Of: odoo/odoo#257829

Steps to reproduce
1. Create a company with Egypt localization, currency EGP
2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts
3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount
4. Switch the user language to Arabic
5. Open the Accounting dashboard

Issue
The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see
https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252

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

Forward-Port-Of: odoo/odoo#267812
Forward-Port-Of: odoo/odoo#266742

### Issue:
When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format

According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225):
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf

### Cause:
The invoice JSON generation does not consider the company's `tax_periodicity`

This logic was probably omitted because `account_reports` may not be installed
However, when the periodicity is configured, the generated SII document should reflect it correctly

### Steps to reproduce:
- Install `l10n_es_edi_sii` and `account_reports`
- In Settings, set `Tax Periodicity` to `Quarterly`
- In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española`
- Change ES Company vat number to `ESA12345674`
- Create an invoice (Date: 01/05/2026, Customer: ES Company)
- Open the generated JSON document
- Check the Periodo value, it should be 2T in May

opw-6050587

Forward-Port-Of: odoo/odoo#267708
Forward-Port-Of: odoo/odoo#264063

Description of the issue/feature this PR addresses:

Prevent an internal server error when a customer cancels a Redsys payment
and returns to Odoo.

Current behavior before PR:

When the customer cancels the payment from the Redsys checkout page,
Redsys redirects back to Odoo without the `Ds_MerchantParameters`
parameter.

The payment flow assumes the parameter is always present and tries to
decode it unconditionally, causing an internal server error.

Desired behavior after PR is merged:

Odoo gracefully handles payment cancellations when
`Ds_MerchantParameters` is missing from the callback parameters.

The customer is redirected correctly without triggering a server error.

Steps to reproduce:

1. Install the Redsys payment provider.
2. Configure a test environment.
3. Create a sales order or invoice.
4. Start the payment process.
5. Cancel the payment from the Redsys checkout page.
6. Return to Odoo.
7. Observe the internal server error caused by the missing
   `Ds_MerchantParameters` parameter.


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

Forward-Port-Of: odoo/odoo#265655

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#118863
Forward-Port-Of: odoo/enterprise#112041

**Description of the issue this PR addresses:**
----------------------------------------------
Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation.

**Current behavior before PR:**
----------------------------------------------
- Visitors can type @ in the livechat composer and trigger partner mention suggestions.
- The suggestions only include the visitor themselves or odoobot.

**Desired behavior after PR is merged:**
----------------------------------------------
- The @ delimiter is disabled for visitors in livechat threads.
- Partner mention suggestions are no longer triggered for visitors.
- Internal users (operators) can still use @ mentions normally.

Task-5119068

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

Forward-Port-Of: odoo/odoo#267788
Forward-Port-Of: odoo/odoo#253551

**Problem:**
A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered.

**Steps to reproduce:**
1. Create a combo product bundling two storable items.
2. Sell the combo on a sale order, confirm and invoice it.
3. Deliver every combo item.
4. Open Accounting > Review > Invoiced Not Delivered.

**Current behavior:**
The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information.

**Expected behavior:**
The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered.

**Cause of the issue:**
A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where
`qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever.

**Fix:**
Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct.

opw-6215110

Forward-Port-Of: odoo/enterprise#118942

**Steps to reproduce:**
- create a new company A
- in the branch tab, create a new branch A for this company
- create a warehouse for the company A and a warehouse for 
the branch A
- from the company A, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From the branch A:
- create a storable product with standard perpetual category
- set a cost of 10
- confirm a PO for 10 and validate delivery
- navigate to 'inventory valuation'

Make sure the branch A is the main company, but 
both branch A and company A are selected: 
- click on generate entry
- click on the 'Other Info' tab

**Current behavior:**
The company of the account move is the parent company
(Company A)

**Expected behavior:**
It should be the branch A. 
(As it is the case if only branch A is selected when clicking 
on "Generate entry")
IAs a consequence, f you click on 'Inventory Valuation' on the 
top left to go back to the view, you will have an access error. 

**Cause of the issue:**
When computing the company_id on the account move, 
move.journal_id.company_id will be the parent company because 
the journal_id of the branch is the one of the parent company 
(by default).
So we will call _accessible_branches() on the parent company.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/addons/account/models/account_move.py#L878-L881
Inside __accessible_branches(), 'accessible' will be based on 
self.env.companies 
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L430-L439
(which is based on 'allowed_company_ids' in the context.
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/environments.py#L266)
So the return value of __accessible_branches()
will be a list with 2 ids, the one of the parent 
company and the one of the branch. 
And we will use the first element of this list,
which will be the parent company_id, in _compute_company_id
to set the company of the account move.

**fix:**
When fetching the data for the inventory valuation view, 
only the data from the main company selected matters,
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

The idea of the fix is to do the same in action_close_stock_valuation
when creating the account move.
We already did something very similar in this PR
https://github.com/odoo/odoo/pull/262776 where we also 
modified the context in action_close_stock_valuation()
before calling _action_close_stock_valuation()
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/res_company.py#L56

opw-6144294

Forward-Port-Of: odoo/odoo#265369
Forward-Port-Of: odoo/odoo#263828

**Problem:**
Adding a single-value attribute to a product template that has variants with manually-set sales prices wipes those prices, resetting each variant back to the template's base list_price.

**Steps to reproduce:**
1. Create a template "Cable" with attribute Length [1m, 5m, 10m, 15m] (template list_price=1.0).
2. On each variant, manually set a unique Sales Price (10/20/30/40).
3. Add a single-value attribute (e.g. Brand=MELODIKA) to the template.
4. Observe variant Sales Prices.

**Current behavior:**
All four variant prices are reset to 1.0 (the template list_price). Variant ids are unchanged.

**Expected behavior:**
Variant prices remain at the manually-set values, since no variant is created or removed.

**Cause of the issue:**
In 19.x, product.product.lst_price is a stored compute with readonly=False, allowing per-variant overrides. The single-value branch of product.template._create_variant_ids writes
product_template_attribute_value_ids on each existing variant to attach the new attribute. That write invalidates the variant's price_extra (One2many depends), which in turn invalidates the stored lst_price compute. On the next flush, lst_price is recomputed as list_price + price_extra, overwriting the user override.

**Fix:**
Snapshot each variant's lst_price before the single-value-attribute write loop and restore the snapshot afterwards if the recompute changed it. This preserves user-set per-variant prices in the case the loop already exists to handle (single-value attribute that does not require recreating variants). Trade-off: if the single-value attribute itself carries a non-zero price_extra and the user had manual overrides, the extra will not auto-propagate to overridden variants. That is preferable to wiping the override entirely, which is the reported regression.

opw-6229147

**Problem:**
A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered.

**Steps to reproduce:**
1. Create a combo product bundling two storable items.
2. Sell the combo on a sale order, confirm and invoice it.
3. Deliver every combo item.
4. Open Accounting > Review > Invoiced Not Delivered.

**Current behavior:**
The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information.

**Expected behavior:**
The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered.

**Cause of the issue:**
A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where
`qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever.

**Fix:**
Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct.

opw-6215110

Forward-Port-Of: odoo/enterprise#118942

**Description of the issue this PR addresses:**
----------------------------------------------
Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation.

**Current behavior before PR:**
----------------------------------------------
- Visitors can type @ in the livechat composer and trigger partner mention suggestions.
- The suggestions only include the visitor themselves or odoobot.

**Desired behavior after PR is merged:**
----------------------------------------------
- The @ delimiter is disabled for visitors in livechat threads.
- Partner mention suggestions are no longer triggered for visitors.
- Internal users (operators) can still use @ mentions normally.

Task-5119068

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

Forward-Port-Of: odoo/odoo#267788
Forward-Port-Of: odoo/odoo#253551

When the cogs are computed using the Stock Moves values, we would not differentiate between deliveries and returns, taking both in the cogs value computation. This meant that when doing multiple deliveries with returns before posting the invoice, if the deliveries/returns had different cost, the COGS would be an average of all of them. Example: Delivery $10 -> Return $10 -> Delivery $20  ==>  COGS $13.33

## HOW TO REPRODUCE
- Create Product FIFO Perpetual, cost=10, onHand=1
- Create Sale order for 1 unit
- Deliver and return
- Change cost from 10 to 20:
  - Set on hand to 0
  - Change product cost to 20
  - Set on hand to 1
- Duplicate SO delivery and validate
- Create and Post Invoice => COGS == 13.33


## FIX EXPLANATION

Returns / Refunds are counted negatively.
So when we compute the moves value, instead of doing `(10 + 10 + 20) / (1 + 1 + 1)`, we do `(10 - 10 + 20) / (1 - 1 + 1)`.
We need to propagate this logic to the cogs quantity, so that we don't believe that we invoiced 3 units while only 1 (1-1+1) was delivered.

---

Note:
For the update in test `test_fifo_delivered_invoice_post_delivery_with_return`, I put back the original values modified by 5978bc5dc683d317f4ab87f6c9c9d843568bf4ea

---

<img width="1852" height="363" alt="image" src="https://github.com/user-attachments/assets/ea9f16b2-a818-4c21-b3c3-aa296792f477" />
<img width="1203" height="787" alt="image" src="https://github.com/user-attachments/assets/7348d15a-b840-4ee0-b1da-2b954cdb3d5e" />

---

## Test result without fix:
```
2026-05-28 11:57:45,899 36667 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: Starting TestAngloSaxonValuation.test_fifo_invoice_with_delivery_with_return ... 
2026-05-28 11:57:47,138 36667 INFO oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: ====================================================================== 
2026-05-28 11:57:47,138 36667 ERROR oes_test_19.0 odoo.addons.sale_stock.tests.test_anglo_saxon_valuation: FAIL: TestAngloSaxonValuation.test_fifo_invoice_with_delivery_with_return
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/sale_stock/tests/test_anglo_saxon_valuation.py", line 1099, in test_fifo_invoice_with_delivery_with_return
    self.assertRecordValues(invoice.line_ids, [
  File "/home/odoo/Odoo/src/19.0/odoo/odoo/tests/common.py", line 727, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'ac[22 chars]t': 0, 'credit': 50}, {'account_id': 9141, 'de[114 chars]: 0}] != [{'ac[22 chars]t': 0.0, 'credit': 50.0}, {'account_id': 9141,[132 chars]0.0}]

First differing element 2:
{'account_id': 9138, 'debit': 0, 'credit': 20}
{'account_id': 9138, 'debit': 0.0, 'credit': 13.33}

- [{'account_id': 9162, 'credit': 50, 'debit': 0},
+ [{'account_id': 9162, 'credit': 50.0, 'debit': 0.0},
?                                   ++           ++
-  {'account_id': 9141, 'credit': 0, 'debit': 50},
+  {'account_id': 9141, 'credit': 0.0, 'debit': 50.0},
?                                 ++             ++
-  {'account_id': 9138, 'credit': 20, 'debit': 0},
?                                 ^^
+  {'account_id': 9138, 'credit': 13.33, 'debit': 0.0},
?                                 ^^^^^           ++
-  {'account_id': 9168, 'credit': 0, 'debit': 20}]
?                                             ^^
+  {'account_id': 9168, 'credit': 0.0, 'debit': 13.33}]
?                                 ++            ^^^^^

```

---

OPW-6213321

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

Forward-Port-Of: odoo/odoo#266917

**Problem:**
A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered.

**Steps to reproduce:**
1. Create a combo product bundling two storable items.
2. Sell the combo on a sale order, confirm and invoice it.
3. Deliver every combo item.
4. Open Accounting > Review > Invoiced Not Delivered.

**Current behavior:**
The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information.

**Expected behavior:**
The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered.

**Cause of the issue:**
A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where
`qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever.

**Fix:**
Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct.

opw-6215110

Forward-Port-Of: odoo/enterprise#118942

Currently, an error occurs when a user sets a non-numeric value as the journal's next check number.

**Steps to Reproduce:**
 - Install the `account_check_printing` module with demo data.
 - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`.
 - Open the `bank journal`.
 - In the `Outgoing Payments` tab > Enable `Manual Numbering`.
 - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`.

`ValueError: invalid literal for int() with base 10: 'FA1234'`

After [this commit], the next check number is converted to an integer without first validating that it 
contains only numeric characters [1]. Since the value can be non-numeric, converting it directly 
to an integer raises the error.

This commit ensures that the next check number is converted to an integer only after verifying 
that it contains numeric characters only.

[this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4

[1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61

sentry-7498755988

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

Forward-Port-Of: odoo/odoo#266280

Steps to reproduce:
===================
1. Edit a page, add a Cover/Banner block.
2. Set its background to a video, paste an Instagram URL
3. Save and open the published page.

=> Instagram embed is broken (iframe shows nothing / error).

Cause:
=======
Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render.

The unconditional append is itself a regression from the public-widget → interaction refactor in [2].
The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram.

Solution:
=========
remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction

[1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492
[2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4

opw-6233081

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

Forward-Port-Of: odoo/odoo#267016

### Issue
Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns
The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button

Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes

### Cause
The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant
No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts

### Steps to reproduce
- Install `l10n_pe_reports` and `accountant`
- Switch to a PE Company
- Go to the Tax Report Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry

### Notes
This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely

enterprise-pr: https://github.com/odoo/enterprise/pull/117891
opw-5978673

# How to reproduce
- Install the Accounting module
- In the settings, enable "Sales Credit Limit"
- Remove the Accounting access rights of the current user
- Try to create a new user

# The issue
An access error is raised on the field `credit_limit`

# Cause
Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518

When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users`  inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error.

# Proposed solution
Back port of this commit : https://github.com/odoo/odoo/pull/267193

Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150

opw-6240494

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

[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
-  Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
  (e.g. `8426904171073`).
- Select the product and trigger the server action:
  `Action -> Get Pictures from Barcode Lookup`

Issue:

**During image fetching:**

-  Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
-  `_get_image_from_url()` assumes the response is always a `requests.Response`
   object and directly accesses:  `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`

**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
     - `requests.Response` for successful requests
     - `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
   response attributes.

**Solution:**
- Make barcode_lookup_request() always return a One Response
  object.
- Move the response validation to the callers instead of returning custom
  dict objects.

**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.

**OPW-6200749**

Forward-Port-Of: odoo/enterprise#116925

Currently, an error occurs when a user sets a non-numeric value as the journal's next check number.

**Steps to Reproduce:**
 - Install the `account_check_printing` module with demo data.
 - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`.
 - Open the `bank journal`.
 - In the `Outgoing Payments` tab > Enable `Manual Numbering`.
 - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`.

`ValueError: invalid literal for int() with base 10: 'FA1234'`

After [this commit], the next check number is converted to an integer without first validating that it 
contains only numeric characters [1]. Since the value can be non-numeric, converting it directly 
to an integer raises the error.

This commit ensures that the next check number is converted to an integer only after verifying 
that it contains numeric characters only.

[this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4

[1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61

sentry-7498755988

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

Forward-Port-Of: odoo/odoo#266280

Currently, an error occurs when user tries to select a property field in auto field.

Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.

Error:
- saas-18.3 and later:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
    field = records._fields[field_name]
            ^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```

- saas-18.2:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
    if len(records) > PREFETCH_MAX:
       ^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```

Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.

- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.

Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.

[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41

sentry-7378769090

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

Forward-Port-Of: odoo/enterprise#118832
Forward-Port-Of: odoo/enterprise#112482

### Description of the issue/feature this PR addresses:
This PR introduces batch processing to the VAT Books ES (Libros de IVA) report generation. When attempting to export the report for periods containing a massive volume of invoices, the ORM cache continuously accumulates records, leading to severe memory consumption. By implementing batching and explicitly clearing the environment cache, use memory use will remain stable and efficient.

### Current behavior before PR:
Generating the VAT Books report loads all account move lines into memory at once. Because the ORM cache is never cleared during the iteration, RAM usage spikes continuously. On databases with tens or hundreds of thousands of invoices in a single period, this leads to significant performance degradation, worker timeouts, or complete Out-Of-Memory (OOM) crashes.

### Desired behavior after PR is merged:
The report engine now splits the recordset into manageable batches (e.g., 50,000 accounts per batch). After processing each chunk to extract the income and expense line values, invalidate_model() is called to flush the ORM cache related to the searched records. This frees up memory continuously, keeping the server's RAM usage flat and allowing the successful export of massive datasets without crashing.

### Benchmark:
The model is iterating through ~1.1M account move lines when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 385 MB | 666 MB |
| ~340,000 account move lines |1.2 GB | 1.5 GB |
| ~1.2M account move lines | MemoryError | 1.5 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~77,000 account move lines | 32s | 12s |
| ~340,000 account move lines | 2:29min | 1:11min |
| ~1.2M account move lines | MemoryError | 4:11min |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#118903
Forward-Port-Of: odoo/enterprise#116139

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#119259
Forward-Port-Of: odoo/enterprise#118711

## Steps to Reproduce:
1. Install the Accounting module.
2. Go to Accounting > Reporting > Executive Summary.
3. Activate debug mode.
4. Click on the gear icon at the top.
5. In the "Options" tab, disable the "Date Range".
6. Open the report again.

## Error:
`TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'`

## Cause:
At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported.

## Fix:
This commit takes the fiscal-year's start date, when the date-range feature is disabled.

[1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570
[2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16

sentry-7455506965

Forward-Port-Of: odoo/enterprise#119162
Forward-Port-Of: odoo/enterprise#116888

**Steps to reproduce:**
* install `l10n_lu_reports`.
* Create a company in Luxembourg with a `company_registry` number set.
* Link this company to an accounting firm that is a natural person (independent accountant) with no business registration number — i.e. `l10n_lu_agent_rcs_number` is left empty on the agent partner.
* Go to the tax report and generate the XML declaration.

**Observed behavior:**
* The `<Agent><RCSNbr>` field in the generated XML contains the company's own `company_registry` value instead of `NE`.
* The file is rejected by the Luxembourg tax administration.

**Cause:**
* In `l10n_lu_generate_xml.py`, the `agent_rcs_number` template value was built with a plain `or` chain: `agent.l10n_lu_agent_rcs_number or company.company_registry or "NE"`
* When an agent is set but has no RCS number (natural person), the fallback incorrectly continued to `company.company_registry` instead of stopping at `"NE"`.

**Fix:**
* Use a conditional expression so that `company.company_registry` is only used as a fallback when **no agent is linked** to the company: `(agent.l10n_lu_agent_rcs_number if agent else company.company_registry) or "NE"`

opw-6044689

Forward-Port-Of: odoo/enterprise#112968

Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Currently, an error occurs when the user clicks on the translate button.

**Steps to Reproduce:**

 - Install the `CRM` module.
 - Go to `settings` and in `Languages` add 1 more language.
 - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`.
 - Click `New` and, in the `Name` field click the `translate button` on the right.

**Behavior in 18.0**

When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, 
the translation dialog shows the translated value on the second click.

**Behavior in saas-19.1**

`AssertionError: Invalid falsy real id`

Error:
After this [recent commit], when the user clicks on the translate button, if the record has a 
root record, the root record is saved before opening the translation dialog. However, in the 
case of an editable DynamicList view, the record does not have a root record so saving 
the record returns a promise instead of the resolved value [1].
Because of this promise, the condition fails [2], and the translation dialog is opened with a 
falsy ID since the record is not yet saved [3]. 
In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f).

This commit ensures that await is used so the resolved value is returned after the record is 
saved before opening the translation dialog.

[recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be

[1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23

[2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26

[3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41

sentry-7384270487

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

**Problem:**
If the Rental Transfers setting is enabled, a traceback occurs
when validating a delivery order containing a kit that will be exploded
during the validation.

**Cause:**
When validating a delivery (`button_validate`), `_action_done` is run
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/stock/models/stock_picking.py#L1441

The `sale_stock_renting` and `sale_mrp_renting` overrides of this
method both execute after other overrides
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_stock_renting/models/stock_move.py#L63
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_mrp_renting/models/stock_move.py#L11

The `mrp` override of `_action_done` calls `action_explode`, which can
unlink records contained in `self` in the calls of `_action_done`
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/mrp/models/stock_move.py#L543-L544
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/mrp/models/stock_move.py#L582

The `sale_stock_renting` and `sale_mrp_renting` overrides of
`_action_done` then resolve after this, and attempt to iterate on `self`
or values within `self`, causing a Missing Record Error to occur when
attempting to read properties of a deleted record within `self`
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_stock_renting/models/stock_move.py#L65
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_mrp_renting/models/stock_move.py#L13

**Purpose:**
Modify the _action_done method's overrides to ensure that
records that no longer exist are not iterated on. This allows the
validation to resolve correctly and explode the kit, requiring a second
validation for the individual components of the kit.

**Steps to Reproduce in Runbot:**

1. Enable the Rental Transfers setting.
2. Create a Product with Tracked Inventory, then add it to a Quotation
   and confirm it.
3. Add a Kit type Bill of Materials to the Product.
4. Attempt to validate the Delivery made when confirming the Quotation.

Similar Fix: https://github.com/odoo/odoo/pull/258403

opw-6144693

**Problem:**
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. and the schedule is flexible and is set to 40h per week. When we open the Attendances app, the expected hours for this employee show 48h.

**Steps to reproduce:**
- Create an employee with a flexible 40h/week schedule and a contract.
- Set employee timezone to Asia/Pyongyang and the working schedule timezone to Europe/Brussels.
- Open Attendances > Overview > Dashboard in week view.
- denominator shows 48h or any other number than 40h.

**Cause:**
In flexible calendars, weekly expected hours are computed by iterating within `[start_dt, end_dt]`. and That logic truncated bounds to `.date()`, assuming `end_dt - 1 second` would always move to the previous day.

That assumption breaks when employee timezone differs from schedule timezone and the employee timezone is far from UTC (like Asia/Pyongyang). so, `end_datetime` is no longer near midnight in local time, so subtracting one second keeps the same date. The loop then includes one extra day and allocates an extra 8h, showing 48h expected instead of 40h in Attendances.

**Fix:**
This change keeps full datetime bounds (instead of truncating to date), so comparisons preserve timezone offset and time of day precision. This prevents the extra day and restores correct weekly expected hours. The original code before this 332cb43 was like this:
```python
                    start_date = start_datetime.date()
                    end_datetime_adjusted = end_datetime - relativedelta(seconds=1)
                    end_date = end_datetime_adjusted.date()
```
this will not work as `.date()` will do the same problem of the extra day allocation.

Affected from 18.0 -> 18.4
Fixed in 19.0+ by this
Backport of https://github.com/odoo/odoo/pull/252847

opw-6171432

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