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

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] 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

[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

**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

When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message:
> The recipient bank account linked to this invoice is archived.
So you cannot confirm the invoice.

The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team:
> In practice, a compute method cannot expect active_test to have
> a particular value. It may be invoked with any context. There is no
> "context purge" done by the ORM. The computation may be "prepared"
> with a context (the one of modified()) and actually done with another
> context (code accessing the field before some explicit flush). In
> other words, if the compute method searches for a record that matches
> some conditions, and if that record cannot be inactive, then this
> condition must be explicit in the search domain (or in the context).

opw-6229286

Forward-Port-Of: odoo/odoo#267398

# 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

Forward-Port-Of: odoo/odoo#268303
Forward-Port-Of: odoo/odoo#268039

### [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 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

# 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

Forward-Port-Of: odoo/odoo#268303
Forward-Port-Of: odoo/odoo#268039

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#118479

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

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

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

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

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

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

- OPW: 6247870

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

### 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

opw-5978673

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#118479

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

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

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

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

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

opw-6252040

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

**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

## 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

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

The Incapacidad node in the nomina 1.2 complement had two issues
preventing CFDI stamping for payslips with IMSS incapacity leaves:

1. The ImporteMonetario attribute was missing entirely. This is a
   conditional attribute defined in the SAT XSD (nomina12.xsd) to
   express the monetary amount of the incapacity. Without it, the
   SAT rejects the CFDI with validation error NOM95:
     'El atributo Deduccion:Importe no es igual a la suma de los
     nodos Incapacidad:ImporteMonetario, ya que la clave expresada
     en Nomina.Deducciones.Deduccion.TipoDeduccion es 006.'

2. The DiasIncapacidad attribute was rendered as a float (e.g. '11.0')
   instead of an integer ('11'). The XSD defines it as xs:int with
   minInclusive=1, so the float representation caused error 301
   (XML mal formado).

Per the SAT filling guide, the ImporteMonetario value depends on
the context:
- Default: the amount comes from deduction 006 (Descuento por
  incapacidad), which is the discount applied to the worker.
- Exception: when perception 014 (Subsidios por incapacidad) exists,
  the amount comes from that perception instead, representing the
  subsidy paid to the worker.

When neither deduction 006 nor perception 014 exist on the payslip,
the attribute is omitted (None) to comply with its conditional
nature in the XSD.

There have been multiple issues that happened when enabling/disabling lot valuation.

Odoo is flexible with the reservation/consumption of lots on StockQuant without lots.
This means that while your product is valued by lot/SN, you can still end up with a discrepancy between your lot quantity on hand and your lot quantity valued.

You can be in a situation where you don't have any negative lots on hand, but the valuation shows the negative amount.
If you tried to fix the discrepancy by setting the StockQuant to zero, you are blocked because a lot/SN is required.
If you tried to disable the valuation by lot configuration, it was allowed (because no negative quants on hand), but the valuation remaining data would be broken.

This PR aims to fix the methods '_svl_empty_stock' and '_svl_replenish_stock' by supporting negative lots.

OPW-4888289

---

One way to break the lot valuation:

https://github.com/user-attachments/assets/b5f0d8c5-d798-4110-9564-951d0be9dcc6

---

After this PR:
- `_svl_empty_stock` simply set the valuation for the lot/product to 0, it's not an OUT/IN svl, and no need to call `_run_fifo` or `_run_fifo_vacuum` (perf++).
- The user can enable/disable lot valuation with negative lots
- When enabling the lot valuation, the lot valuation will be replenished even if the global quantity is 0.
- The user can disable lot valuation when they have a quant without lot.
- The user can NOT enable lot valuation when they have a quant without lot.

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

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119391
Forward-Port-Of: odoo/enterprise#118759

### Issue:
In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled

However, these fields must only be used for EU countries

For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors

### Cause:
`_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries

As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU

Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create a customer in Switzerland with a valid VAT number
- Create and confirm an invoice for that customer
- Go to Accounting → Audit Reports → General Ledger
- Select the full year
- From the gear menu, export DATEV DATA (zip)
- Open the `EXTF_customer_accounts` file

### Before the fix:
`EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty

### After the fix:
`EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled

`Land` is filled using the following priority:
1. Partner country_code
2. Country extracted from the VAT number
3. Empty

opw-5902565

Description of the issue/feature this PR addresses: Issue: When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue.

Solution: This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds.

Current behavior before PR:
A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue.

Desired behavior after PR is merged:
The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created.

opw-6218288

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

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

Starting version 2.1.4 of markupsafe, they decided to adapt the striptags function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex.

A problem has been spotted with qweb templates that used striptags with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster.

The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better.

The benchmark cases are in the form `<case_description>_<number_of_tags>`. We can see that the only cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex.

Apart from that, the old implementation is consistently much more performant, for both small and large inputs.

Benchmarks:

| Case                               | Regex µs | Current µs   | Speedup  |
|----------------------------------------|----------|--------------|----------|
| plaintext_no_tags_50k_words            | 2937.05  | 2795.78      | 0.95x ← current_implementation |
| html_entities_only_no_tags_5k               | 4843.88  | 4818.92      | 0.99x ← current_implementation |
| comments_only_1k                       | 382.75   | 1985.56      | 5.19x ← regex_old_implementation |
| comments_containing_tags_1k            | 234.88   | 1243.65      | 5.29x ← regex_old_implementation |
| comments_only_50k                      | 21047.84 | 21081024.01  | 1001.58x ← regex_old_implementation |
| comments_containing_tags_50k           | 13948.90 | 11301014.95  | 810.17x ← regex_old_implementation |
| short_tags_5k                          | 915.32   | 28235.99     | 30.85x ← regex_old_implementation |
| short_tags_20k                         | 3603.37  | 876001.98    | 243.11x ← regex_old_implementation |
| short_tags_50k                         | 10648.04 | 9064394.50   | 851.27x ← regex_old_implementation |
| nested_divs_1k_deep                    | 148.99   | 880.14       | 5.91x ← regex_old_implementation |
| nested_divs_10k_deep                   | 1730.14  | 54162.25     | 31.31x ← regex_old_implementation |
| tags_with_many_attrs_2k                | 1165.15  | 16554.24     | 14.21x ← regex_old_implementation |
| tags_with_many_attrs_20k               | 12659.77 | 7297957.10   | 576.47x ← regex_old_implementation |
| multiline_tags_20k                     | 10227.63 | 5476065.12   | 535.42x ← regex_old_implementation |
| mixed_comments_with_tags_text_2k            | 309.79   | 3034.69      | 9.80x ← regex_old_implementation |
| mixed_comments_with_tags_text_10k           | 1593.39  | 79993.58     | 50.20x ← regex_old_implementation |

This PR is needed because requirements.txt in Odoo specifies the following dependency:
MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)

This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe.

opw-5999688


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

### What & why

`odoo db load` always calls `restore_db(..., copy=True)`, which forces the
generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is
the right default when *duplicating* a database, but it breaks the intended
behaviour when *moving* a database between servers: Enterprise subscription codes
are registered against the database UUID, so regenerating it deregisters the
moved database.

The web database manager already lets the user choose between copying and moving
(the `copy` flag of the `/web/database/restore` route), but the CLI exposed no
equivalent and forced a copy unconditionally. The CLI is the better tool for
server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits
and can run unattended or interactively.

### Steps to reproduce the current limitation

1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID)
2. On server B: `odoo db load mydb mydb.zip`
3. `database.uuid` has changed → the subscription is deregistered

### Fix

Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`,
keeping the original UUID. The default remains `copy=True`, so existing behaviour
is unchanged.

```sh
odoo db load mydb mydb.zip          # unchanged: restore as a copy (new UUID)
odoo db load --move mydb mydb.zip   # new: restore as a move (keep the UUID)
```

### Backport request

This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well.
Those are precisely the versions that ship the `odoo db` CLI subcommand, so the
fix is applicable to all of them — which is why the backport range is 16.0 → 19.0
and stops at 16.0.