Currently, payments may remain in the 'in_process' state even when the
associated vendor bills are fully paid. This occurs primarily when using
early payment discounts (EPD) and journals without outstanding accounts.

Steps to reproduce:
- Create an early payment term.
- Create a Vendor Bill with EPD and post it.
- Register a payment for this bill (no outstanding account set on
  journal => no move created).
- Create a bank transaction fully paying the bill.
- Reconcile the transaction with the bill.

Issue: Access the payment of the bill. The payment state remains
'in_process' instead of 'paid'.

Analysis: The issue occurs because the reconciliation process misses the
trigger to set the payment state to 'paid'. Specifically:
- The payment amount does not match the bill total due to the EPD.
- The payment compute method does not monitor 'reconciled_bill_ids',
  causing it to ignore the status of linked vendor bills.

This change adds 'reconciled_bill_ids' to the compute dependencies and
ensures that if a payment is reconciled with any moves (invoices or
bills), their payment_state is considered to determine the final state
of the payment.

Test in enterprise: https://github.com/odoo/enterprise/pull/112398

opw-5881976

Forward-Port-Of: odoo/odoo#256486

### Issue:

In certain flows, basic mrp users (mrp.group_mrp_user) can not mark MO's as done or split production due to the associated automatic creation of accounting analytics.

As concrete examples, the tests:
- test_automatic_backorder_no_redirect
- test_change_qty_produced can not be performed with a user with basic mrp access rights.

### Steps to reproduce:
- Incarnate a user with only mrp user rights
- Create and confirm an MO for 2 units with an operation
- Click on the cog wheel icon > Split production > split
#### > Access Error: You are not allowed to access 'Analytic Line' (account.analytic.line) records.

### Cause of the issue:

To begin with, members of the `mrp.group_mrp_user` do not and should not have read nor create access rights with respect to the `account.analytic.line` model. However, as soon as `mrp_account` is installed the `button_mark_done` can end up requiring such access.

1. The `_split_productions` fails for multiple reasons:

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2000 fails because of the assignment since this call:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L27-L35 requires write and read access on the `account.analytic.line` model.

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2002 fails because the `copy_data` now checks that the user has the `read` access rights of the comodel when copying `many2many` data's: https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/odoo/orm/models.py#L4781-L4783 This is an issue for instance for the `wip_move_ids` field that can not be copied since mrp users do not have a read access to the `account.move` comodel:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L15

This line:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp/models/mrp_production.py#L2017 will fail since it checks the read access right on the comodel `account.move` of the `wip_move_ids` fields.

2. The `_post_inventory`:

https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L2221 Fails as it sets the duration:
https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L1922 which calls the `_create_or_update_analytic_entry`: https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp_account/models/mrp_workorder.py#L18-L21 which it self creates and update `account.analytic.lines` to which you do not have any read access.

backport of b5c7d5fed2d893bcd5ea2c2c5ed1cb9d8dfa2424

opw-6066674

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

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#256658
Forward-Port-Of: odoo/odoo#255780

**Steps to reproduce:**
- Install contacts and account
- Create a second company
- Stay in the first company

- Create a new contact:
  * Company: [the second company]
  * Account Receivable: [create a new one in the second company]
  * Account Payable: [create a new one in the second company]
- Save

**Issue:**
A UserError is raised because "Account Receivable" and "Account Payable" don't belong to the current company.

**Cause:**
Those fields are company-dependent.
As their value is registered for the current company, they are forced in that company, even if the linked record belongs to another one.
It would be weird for a company-dependent field to belong to another company than the one it is defined in.
However, it is also weird to create a record that belongs to a company and that have fields belonging to another company.

**Solution:**
In "_check_company" method, verify that the company set on the company-dependent co-records is the same than the company of the record when it is set.

opw-5409503



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

**Steps to reproduce:**
* Install `account_iso20022` and `hr_expense`  module.
* Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method.
* Leave the `Vendor` field empty.
* Submit, approve, and post the expense.

**Observed behavior:**
* The expense is posted successfully without a vendor, creating a payment with `partner_id = False`.
* The payment cannot be reset to draft due to the missing vendor, and SEPA XML generation fails because the creditor name (`<Cdtr><Nm>`) requires a partner.

**Cause:**
* The `hr_expense` module overrides `_compute_show_require_partner_bank`. to set `require_partner_bank_account = False` for expense payments, bypassing the partner bank validation in `account.payment.action_post`.
* `_prepare_payments_vals` uses `self.vendor_id.id` for `partner_id`, which evaluates to `False` when no vendor is set.
* The `_post` method on `account.move` only validates partner presence for invoices (sale/purchase documents), not for `entry` type moves, which payments use.

**Fix:**
* Add a validation in `hr.expense.action_post` that checks whether the payment method is `sepa_ct`. If so, `vendor_id` must be set before posting.
* This catches the issue early in the expense flow, before the payment and journal entry are created.

opw-5930687

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#258188
Forward-Port-Of: odoo/odoo#248619

Currently, in the mass mailing editor, an error occurs when a user replaces an image with an illustration.

Steps to reproduce:
1. Open the mass mailing editor
3. Drag and drop a snippet containing an image
4. Double-click on the image
5. In the image search bar, type "test" and press `Enter`
6. Select an illustration

=> A traceback is raised.

When an illustration is selected, it is automatically stored as an attachment with the mimetype `image/svg+xml; charset=utf-8`. The editor then loads the image using the attachment URL (e.g. `/html_editor/shape/illustration/usability-testingsvg-258?...`).

When the media dialog is closed (via `on_media_dialog_saved_handlers`), the editor attempts to process the image and calls the `/html_editor/get_image_info` route to retrieve the image info. This route retrieves the corresponding attachment from the database using the attachment url, but filters results based on a predefined set of allowed mimetypes.

The issue arises because this set does not account for valid mimetypes that include optional parameters such as `charset=utf-8`. As a result, the attachment is not found, preventing the image from being processed and ultimately causing the crash. To fix the issue, we will update the domain used to retrieve image attachments so that it accepts valid mimetypes with optional parameters (e.g. `image/svg+xml; charset=utf-8`).

During image processing, the transformed image is temporarily encoded in base64 and stored in the src attribute. When the record is saved, this base64 image is converted into a new attachment via the `/html_editor/modify_image/<id>` route. **This conversion step is necessary because many email clients have limited support for SVG images. Converting the illustration to PNG ensures better compatibility and visibility across mail clients.**

After conversion, the image url is then set to `/html_editor/shape/illustration/335/usability-testingsvg-258?...` This URL is handled by the `html_editor/shape/<module>/<path:filename>` route. Its purpose is to process SVG files and dynamically adjust their colors based on query parameters (e.g. the `c1` parameter).

However, once the image has been converted to PNG, this logic no longer applies. To address this, an additional conditional check will be introduced: if the file is not an SVG, the route will bypass the SVG-specific transformation logic and instead serve the image directly.

Task-5977962

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

# How to reproduce
- Go to Website app > Configuration > Websites > Select your website > Custom Code
- In the "Custom <head> code" section add the script given at the last section of this PR (with a proper TAG_ID)
- Go to a new Incognito Tab and go to the Website front page
- Refuse the optionnal cookies
- Open the browser's console and go to Application > Storage > Cookies

# The problem
The Google Ads cookies are present (prefixed by _ga)

# Why
This commit introduced the blocking of 3rd party cookies :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1

It works by doing 2 things, but none of them works in our case :

First, it edits the view rendering to replace the `src` value with "about:blank" for watched
tags, but this does not work for `website.custom_code_head` (our case) and `website.custom_code_footer` because it is t-out'ed which bypasses this code :

https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-a27798e1ecfe96676dd48766e0aa9d12fbc0784e328ac1a3ec82b1ce199fc58bR121-R166

Second, it adds a script in the head of the page that patches the setter for the `src`
property of the script tags. If the value that we try to set is a URL to a site that we
block and the cookies are not yet accepted, we replace the `src` value with "about:blank".

https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/website/static/src/js/content/cookie_watcher.js#L8

This sadly does not work for parser-inserted scripts that are directly parsed from the HTML.
Indeed, they do not use the setter of `HTMLScriptElement.prototype`.

It is possible to verify this by adding a `MutationObserver` that checks for new script
insertions and adding breakpoints in this observer and in the patched setter. For the
first scripts of the page, the breakpoint in `MutationObserver`is triggerred while the
 one in the setter is not.

# Proposed solution
We move this code into new helper functions :
https://github.com/odoo/odoo/blob/95dc247ecd773044ef9c9f1512c7d86d73df836c/addons/website/models/ir_qweb.py#L130-L135

And use these helper functions to create another helper function that allows us to check
an html field for trackers that would need to be removed

We then use this helper function on `website.custom_code_head` and `website.custom_code_footer`

# The script
```html
<!-- Google tag (gtag.js) -->
  <script async src="[https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script](https://www.googletagmanager.com/gtag/js?id=TAG_ID%22%3E%3C/script)>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());

    gtag('config', 'TAG_ID');
  </script>
```
Source : https://developers.google.com/tag-platform/gtagjs

opw-6007810

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

### Issue before this commit:
After generating a stock valuation closing entry from the Inventory Valuation report, reopening the report raised an access rights error. Users with Accounting permissions could no longer access the report.

### Steps to reproduce the issue:
1. Access the database with a user having Accounting Admin rights.
2. Go to the Inventory Valuation report.
3. Click to generate a closing entry.
4. Try to open the Inventory Valuation report again.
5. Result: System shows an access rights error.

### Cause of the issue:
The method _get_last_closing_date() retrieves the field state of the model account.move by querying the technical model ir.model.fields. However, accounting users do not have read access to this model. When the report tries to compute the last closing date after a closing entry exists, this lookup triggers an error.

### Reason to introduce the fix:
The lookup of account.move.state is only used internally to inspect tracking values in the chatter and determine the posting date of the closing entry. Since this requires reading a technical metadata model, the query is executed with sudo() to bypass the restriction while keeping the functional access to accounting data unchanged.

opw-5998151

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

**Description of the issue/feature this PR addresses:**
The `Store.getMentionsFromText` method fails to identify mentions for users with special characters (&, <, >) in their names. Because the function processes raw HTML, these characters are encoded as entities, causing them to be [filtered out](https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/mail/static/src/core/common/store_service.js#L599-L601)

In order to resolve this, I translate the entities back into their normal representation, allowing our includes to find them.

**Steps to reproduce bug:**
1) Create a user with a name containing &, <, >
2) Set it so they receive emails for notifications
3) Mention them in a long note
4) Observe that no email is sent

**Current behavior before PR:**

https://drive.google.com/file/d/1itBlz6havFmFi2G3mbOm3qh2_WH6uM76/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1PC2_hjBAhhC6ZSOEzs9SPYjSHrZbaplp/view?usp=drive_link

opw-5895188

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

Steps to reproduce:
- Set a journal with documents folder sync (by default with demo data)
- Create and post a customer invoice
- Add an image or pdf attachment via a log note (it becomes message_main_attachment_id and creates a documents.document with res_model=False)
- Click Send & Print

Issue:
KeyError: `proforma_pdf_attachment`

Cause:
During Send & Print, _link_invoice_documents creates the invoice pdf attachment (res_model='account.move', res_field='invoice_pdf_report_file') and sets it as invoice.message_main_attachment_id.

During the acoun_move write, in `documents_account`, it searches for an existing document matching the previous `message_main_attachment_id` (`initial_attachment`) and sets `document.attachment_id` to the invoice pdf. https://github.com/odoo/enterprise/blob/6bdcc357b195faa0aad8c05eac23aa0a762dd76b/documents_account/models/account_move.py#L41-L54

This triggers the versioning logic which
resets the parent of the attachment when its `res_model` and `res_id` differs from the document. Because the document has res_model=False, the condition always matches and the pdf is re-parented to `documents.document`, deleting res_field's binding to account.move.

After invalidate_recordset
https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L477 invoice_pdf_report_id recomputes to an empty
recordset.
https://github.com/odoo/odoo/blob/7b384a6ec13c372b44e2a58134c61d54de152395/addons/account/models/account_move.py#L2205 _get_invoice_extra_attachments returns empty,
Eventually, we try to access move_data['proforma_pdf_attachment'] which was never set (fallback for otehrscenario) https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L856 -> KeyError.

Solution:
We prevent the creation of a document if no res_model is set.
And extra guard-rail is kept:
Skip re-parenting in DocumentsDocument.write() when the incoming attachment
has res_field set. Attachments linked via a Binary field are owned by their
model and must never be moved to documents.document regardless of the
document's own res_model.

opw-5930888

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

# How to reproduce
- Create a new Journal
- Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account
- Go to the Transactions of the Journal
- Add a new Transaction for partner X and amount Y
- Add a second Transaction also for partner X and amount Y

# The issue
A popup appears that can never be saved

# Cause
When we click on "Add & New" or "Add & Close", we run the `validate()` function :

https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16

Which tries to do a model save, but it fails so it show the Form dialog :

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163

The save fails because :
This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so :

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245

But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once:

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737

opw-6063654

Forward-Port-Of: odoo/enterprise#112750