Issue:
----------------------------------------
When searching for a field from `hr.version` without any rights on Employees, we get an access error.

Steps to reproduce:
----------------------------------------
- Timesheet > To Validate > All timesheet
- Filter on Employee > Department (is set for example)
- An error pops up

Cause:
----------------------------------------
The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field  `hr.employee.current_version_id`.

This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c))

Solution:
----------------------------------------
We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b))

opw-6149198 
opw-6251866

Forward-Port-Of: odoo/odoo#264953

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:
- Activate Anglo-Saxon accounting
- Create a product with track inventory and an automated inventory valuation product category
- Define MTO on the product
- Add this product to an Analytic Distribution Model (i.e. Legal)

- Create a SO for this product
- Create and confirm the PO related to it, the Analytic account is set on the PO.
- Confirm the reception of the product
- This creates a Stock valuation layer with the Analytic account
- Confirm the SO
- Confirm the delivery of the product
- This creates a Stock valuation layer with the Analytic account too
- Create the Invoice

Issue:
Missing analytic account on the 110300 Stock Interim (Delivered) creating unabalanced analytic accounting

Other:
test_report_invoice_items_anglo_saxon_automatic_valuation
introduced in this PR https://github.com/odoo/odoo/pull/205777
checks that in a project's analytic report, the values based
on cogs lines are displayed in the cost section.
With this fix, both cogs lines will have an analytic account
so their impact on the project analytic report will even out.
This made the test fail.
To keep the benefit of this test, we simulate that the user manually
removes the analytic account on some of the cogs lines
(those targetting stock interim received).


opw-6060567

Forward-Port-Of: odoo/odoo#267810
Forward-Port-Of: odoo/odoo#261798

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

Forward-Port-Of: odoo/odoo#267914

### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number

While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice

DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check

Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
    <cbc:LineID>1</cbc:LineID>
    <cac:DocumentReference>
        <cbc:ID>SETP990001021</cbc:ID>
    </cac:DocumentReference>
</cac:ParentDocumentLineReference>
```

### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432

### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number

opw-6164321

Forward-Port-Of: odoo/enterprise#118319

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#264435
Forward-Port-Of: odoo/odoo#259384

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

Currently, if you refund an order made on the customer account with the customer account as well, you can still see the order in the list of orders to settle.

Steps to reproduce:
-------------------
* Open shop
* Make an order using the customer account for a customer, don't invoice it
* Refund one of the order using the customer account, don't invoice it
* Make a new order using the customer account
* In the customer list, find the customer used and select "Settle Orders"
> The 2 orders are present in the list

Why the fix:
------------
Originally the list would only show the orders for chich the customers have due (>0).
https://github.com/odoo/enterprise/commit/bf4b6043b999b4a081b1afa73fc4113bf4db28f8

But recently the code we also see the refunds in the list as well.
https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

However this new behavior is not visible if, with the refund, the customer account temporarily falls to 0.

So currently we have some refunds that impact the amount to settle and some that don't. Originally we were thinking that either we should show all refunds in that list (given they use the customer account) or we shouldn't show any as it was previously. Both solutions are not ideal.
* Showing them all would get the list bigger than it is and would require the customer to select the order and its refund(s) and settle them together. Since refunds are not usually done right after the order they would not be close it that list. However this solution would enable the option to remove the orders from the list requiring a few step from the customer.
* Showing none isn't idea either with this use case as it means that we still see orders that were cancelled out by their refunds. To remove to order the customer has two options. Either going backend and searching the order and its refund(s)
and invoice them, either settling the order but that means that now there's money deposited on the customer account.

Any of the two option isn't perfect a it still requires manual intervention from the customer and wouldn't work on previous data. Creating a server action to correct those data wouldn't have been feasible either.

Instead, the approach we're taking is the following: When loading the list of order to settle we want to remove the orders and the potential refunds were the customer account is evened out.

We only need to look at the orders of the partners that contains refunds for which the customer account was used. If the sum of the transactions made on the customer account is 0 we can say that the order and its refunds have cancelled out each other (in terms of customer account) and we don't show them if the list of orders remaining to settle.

opw-6170830

Forward-Port-Of: odoo/enterprise#117725

The [commit] introduced the method for inverting the interval inside the given limits.
The method was failing for the following edge cases:
```python
>>> invert_intervals([(1, 2), (4, 5)], 0, 10)
result - [(2, 4), (5, 10)]
expected - [(0, 1), (2, 4), (5, 10)]?
>>> invert_intervals([(-2, -1)], 0, 10)
result - [(0, 10)]
expected - same
>>> invert_intervals([(11, 12)], 0, 10)
result - []
expected - [(0, 10)]
>>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10)
result - [(1, 2), (5, 8)]
expected - same
>>> invert_intervals([(2, 5), (8, 12)], 0, 10)
result - [(5, 8)]
expected - [(0, 2), (5, 8)]
>>> invert_intervals([(2, 5), (11, 12)], 0, 10)
result - []
expected - [(0, 2), (5, 10)]
```

This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases.

[commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c

Forward-Port-Of: odoo/odoo#268161
Forward-Port-Of: odoo/odoo#267917

## Steps to reproduce:
- Install the `quality_mrp` module.
- Create a new product.
- Create a Quality Point with: 
  Type: Measure,
  Control per: Product/Operation
  Operations: Manufacturing
- Create and confirm MO for the product.
- Update the Quality Point: 
  Remove the 'manufacturing' operation type and add 'receipts' type. 
  Change Control per to 'Quantity'.
- Open the MO and start a quality check.
- Enter an invalid measure and try to validate it.

## Error:
`AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'`

## Cause:
Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error.

## Fix:
This commit uses the first lot/serial from the MO.
Note: Multiple produced lots are only possible for serial-tracked products.

sentry-7511513479

Forward-Port-Of: odoo/enterprise#119231

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#268128
Forward-Port-Of: odoo/odoo#266917

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#267869
Forward-Port-Of: odoo/odoo#264272

Issue:
Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobilira CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button).

opw-5432421

Forward-Port-Of: odoo/enterprise#119244
Forward-Port-Of: odoo/enterprise#108355

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692

Forward-Port-Of: odoo/odoo#268434
Forward-Port-Of: odoo/odoo#265352

Currently, it's possible to experience very slow loading speed of the partner list and/or browser crashes in the POS when there are thousands of customers stored in the browser cache.

This appears to be caused by a few reasons compounding together:

1. While we limit the number of customers in the initial render of the list, there is no limit during the search. Therefore, if there are thousands of customers matching the search pattern loaded in the browser cache, the browser will attempt to render equally as many `PartnerLine` components.
2. A 100 ms debounce time is fast enough to trigger the render after each key stroke. 200~300ms is the industry standard for Software UI debounce.
3. For each customer rendered in the list, we may perform a search for its parent partner amongst all loaded customers with the function `PosStore.getPartnerCredit()`.

This PR aims at reducing the number of partner lines rendered in a short period of time and thus, at improving speed and avoiding crashes.

Steps to reproduce:
1. Create a fresh db + install the point_of_sale with demo data
2. Populate the res.partner model by a factor of 100 to reach 4000+ partners
3. Update the following system parameter to make sure that we load all partners in the browser cache when we open the POS session:
    - `point_of_sale.limited_customer_count` -> 5000
4. Open a POS session and and click on the `Customer` button to render the partner list
5. Type `adm` in the search bar at normal typing speed
6. Crash

Ticket: opw-5435973

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

Forward-Port-Of: odoo/odoo#258667

[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

Backport of https://github.com/odoo/odoo/pull/267790

Before this commit, when loading discuss app initially with demo data, sometimes there was a crash from maximum stack.

This happens due to infinite loop in discuss store with field `livechats`, which as a computed inverse `appAsLivechat`:

- Initially the field `livechats` has 2 conversations `[1, 2]`
- When adding conversation `3`, the `appAsLivechat` auto-computes to add this conversation to `livechats`, which triggers these field commands:

1. `appAsLivechat`: `[["REPLACE", 3]]`
2. `livechats`: `[["ADD.noinv", DiscussApp]]`

This is fine by itself, but somehow the `"ADD.noinv"` triggers a `[["DELETE.noinv", 1]]` on the inverse field `appAsLivechat`, which is then turned by the versioning system into a `[["REPLACE", [3]]]`, which in turn does a `[["DELETE.noinv", 1]]` and so on infinitely.

The `"DELETE.noinv"` is turned into `"REPLACE"` by the versioning of fields, which is ok, but it does it mistakenly with only considering new field `[3]` rather than having also `[1, 2]` that was there before. The history lacks `[1, 2]` so that's why it can't `"REPLACE"` with these values, even though the saved data already has them, but then the store is aware of deletion of these records, hence the infinite loop.

The underlying issue is that live chats `[1, 2]` were added in store without any track in history. This comes from some internal operations on record lists that apply related change on inverse, but this is done immediately with `.add()` or `.delete()` which doesn't reach the tracking of history of field version in `updateFields()`.

This commit fixes the issue by converting the `[inverse].add()` and `[inverse].delete()` into `updateFields()`, so that this is the same operation but it makes it tracked by the field version history.

Task-6073452

### [FIX] website: prevent inserting block snippet with powerbox in inlines

Inserting block snippet with powerbox when the selection is inside an editable part limited to an element that can only contain inline nodes leads to invalid html (like `<div>` inside `<span>`).

This commit disables insertion of block snippets when the selection is such a part of the document.

Steps to reproduce:
- Open website builder
- Put cursor in "copyright" at the bottom of the footer
- Type `/alert` and press enter
- Bug: `<div>` element is inserted inside `<span>`, that is invalid html

task-6259092

### [FIX] website: prevent unwrapping `s_blockquote` on insert with powerbox

When the snippet `s_blockquote` was inserted with the powerbox or pasted from clipboard in an unbreakable element which does not allow blocks as children, the `<blockquote>` element itself was abandonned and its children were inserted instead. This lead to insertion of a broken snippet.

This commit marks the `s_blockquote` snippet as "unsplittable" so that always stays in one piece when inserted.

Steps to reproduce:
- Open website builder
- Put cursor in a link
- Type `/blockquote` and press enter
- Bug: the snippet's children are inserted, instead of snippet itself

task-6259092

Forward-Port-Of: odoo/odoo#267111

**Steps to reproduce:**
- Install Accounting and l10n_ro_edi
- Switch to a Romanian localization (e.g. RO Company)
- Configure Romanian E-Factura

- Create an invoice with a product having a name longer than 100 chars
- Confirm the invoice
- Send E-Factura to SPV
- Fetch E-Factura status

**Issue:**
The invoice is rejected with the following error:
"[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100."

**Similar issue with the product description:**
"[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200."

**Similar issue with the note (i.e. Terms and Conditions):**
"[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300."

**Solution:**
Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300.

opw-5964904




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

Forward-Port-Of: odoo/odoo#268351
Forward-Port-Of: odoo/odoo#265811

**Steps to reproduce:**
- Install eLearning app with gamification
- Go to Settings > Gamification Tools > Challenges
- Set a challenge with multiple participants (portals / internals)
- Set its state to Done
- Notification email is sent to every participants
- They can see each other in the mail header
(portal user can see all other portal users, internal user can see all portal users)

**Issue:**
Since [1] external recipients are added in the mail header, but this is not adequate for every flows
(here there is no need for the participants to be aware of each other).

**Fix:**
In [2] this issue was mitigated by removing the `'X-Msg-To-Add'` from the header for models which don't need it.
Then in [3] the solution was replaced by a more generic approach using `_CUSTOMER_HEADERS_LIMIT_COUNT = 0`.

[1] https://github.com/odoo/odoo/commit/42aaaef59d21558438c767c6dd8a21674e5df9df
[2] https://github.com/odoo/odoo/commit/e6c13ce4436b3c8b3a2058d2ccf65a7da1b256b2
[3] https://github.com/odoo/odoo/commit/c4dbd868b9c7e26f11db4d2cacef7ffce6c87082

opw-6099745

Forward-Port-Of: odoo/odoo#267192