### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mand

### Steps to reproduce:
- Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509)
- Have a contact with a European IBAN
- Have a company bank journal with a European IBAN
- Create a valid Direct Debit Mandate for your contact
- Create an invoice for that contact and register a payment using SEPA
- Now delete that Sepa payment from Accounting > Customers > Payments
- Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mandate although the payment was deleted
- Expected: link between invoice and mandate should not be kept if payment was deleted

### Cause:
The field `sdd_mandate_id` of the invoice is not reset when the payment is reset to draft.

### Solution:
Add an `api.ondelete` method on `account.partial.reconcile` which checks if any of the unreconciled moves is an invoice with `sdd_mandate_id`. In that case, and if the unreconciled payment is the only SEPA payment, set `sdd_mandate_id` to False.

opw-4277982

Forward-Port-Of: odoo/enterprise#75273

…ique FITID To replicate the issue: 1. Install the brazilian localization (enterprise) 2. In the accounting app dashboard, click Import Statement 3. Upload an .OFX file with duplicate FIDID 4. A validation error appears and the upload is not done Cause: The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions wi

…ique FITID

To replicate the issue:
1. Install the brazilian localization (enterprise)
2. In the accounting app dashboard, click Import Statement
3. Upload an .OFX file with duplicate FIDID
4. A validation error appears and the upload is not done

Cause:
The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions with the same FITID. An example is when PIX transfers have the same FITID as the fee charged for the PIX, which appears as another bank statement line with the same FITID.

Fix:
The function _parse_bank_statement_file is altered to call a function that fills the vals_line dictionary with the transaction's values. This function is then overwritten in l10n_br_reports to not include the FITID (unique_import_id) for journals of Brazilian companies.

opw-4317681

Forward-Port-Of: odoo/enterprise#76556

Forward-Port-Of: odoo/enterprise#76540

Forward-Port-Of: odoo/enterprise#76540

**Before this PR:** Steps to reproduce: - In an empty paragraph write something, press shift + enter - Write something in new line break - Select whole text in second line - Paste any text, notice that an extra <br> is added above pasted text. In other words, `<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `. **Desired behaviour after PR:** Now, pasting something at line-break doesn't add an extra an extra `<br>` . task-4231

**Before this PR:**

Steps to reproduce:

- In an empty paragraph write something, press shift + enter
- Write something in new line break
- Select whole text in second line
- Paste any text, notice that an extra <br> is added above pasted text.

In other words,
`<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `.

**Desired behaviour after PR:**

Now, pasting something at line-break doesn't add an extra an extra `<br>` .

task-4231290




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

Forward-Port-Of: odoo/odoo#185854

When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo. See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14 task-no Forward-Port-Of: odoo/odoo#194352

When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo.

See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14
task-no

Forward-Port-Of: odoo/odoo#194352

Before this commit, the base.automation form view displays the filter_domain field when on_change trigger type is selected but the code does not take into account the filter_domain value for this type of trigger. After this commit, this field is simply hidden in that case. Task: opw-4492554 Forward-Port-Of: odoo/odoo#194321 Forward-Port-Of: odoo/odoo#194158

Before this commit, the base.automation form view displays the filter_domain field when on_change trigger type is selected but the code does not take into account the filter_domain value for this type of trigger.

After this commit, this field is simply hidden in that case.

Task: opw-4492554

Forward-Port-Of: odoo/odoo#194321
Forward-Port-Of: odoo/odoo#194158

When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method. This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed. task-4457200 Forward-Port-Of: odoo/odoo#193715

When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method.

This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed.

task-4457200

Forward-Port-Of: odoo/odoo#193715

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different emai

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were.

In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR.

The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple.

We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most).

Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo.

Task-4361561

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#192724
Forward-Port-Of: odoo/odoo#188697

steps to reproduce: - create a leave with several employees and select 'custom hours' - validate leave - check linked leaves (one per employee) issue: - linked leaves do not use the parent start/date hours note: 8bfd00e9325ffc490d1b470cecb38c75800b8a86 fixed the issue in 16.0 and the feature has been removed in 260b999922766668713c92418bf7431d465b532e in 17.4. opw-4355770 Forward-Port-Of: odoo/odoo#193494

steps to reproduce:
    
- create a leave with several employees and select 'custom hours'
- validate leave
- check linked leaves (one per employee)
    
 issue:
    
 - linked leaves do not use the parent start/date hours
    
note: 8bfd00e9325ffc490d1b470cecb38c75800b8a86 fixed the issue in 16.0 and the feature has been removed in 260b999922766668713c92418bf7431d465b532e in 17.4.
    
opw-4355770

Forward-Port-Of: odoo/odoo#193494

It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393

It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally.

This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them.

Forward-Port-Of: odoo/odoo#194393

Fixes an issue on the partner view where a compute would try to read the proxy user, while not all users who can read the partner would have read access to the proxy user. Also fix a similar case in the action used to validate the ID, which tries to read the proxy user. error-105104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194459

Fixes an issue on the partner view where a compute would try to read the proxy user, while not all
users who can read the partner would have read
access to the proxy user.

Also fix a similar case in the action used to validate the ID, which tries to read the proxy user.

error-105104

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

Forward-Port-Of: odoo/odoo#194459

# Description The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet. Task: 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194464

# Description

The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet.

Task: 0

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

Forward-Port-Of: odoo/odoo#194464

Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode. This happens for instance in the ir.ui.view form view, which contains

Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode.

This happens for instance in the ir.ui.view form view, which contains an AceEditor field. His CodeEditor component listens on the `resize` event to redrawn itself, which causes this error. This also happens with the website builder, which does not involve the CodeEditor. It probably happens at other places as well. We thus need a global solution, like we had before.

This commit thus fixes the condition in the error service to keep swallowing that error.

opw-4500350
opw-4496862
opw-4496782
opw-4495448
opw-4493209
opw-4495309
opw-4472997

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#194483

The event listeners are never removed when the component is unmounted which means to global `env.bus` always keeps a reference to this component and everything that goes with it, including its (child)env. In version 18.0, the spreadsheet client action instantiates its own `BurgerMenu` component and also adds the spreadsheet `model` in the action child env (which can be expensive memory-wise) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

The event listeners are never removed when the component is unmounted which means to global `env.bus` always keeps a reference to this component and everything that goes with it, including its (child)env.

In version 18.0, the spreadsheet client action instantiates its own `BurgerMenu` component and also adds the spreadsheet `model` in the action child env (which can be expensive memory-wise)



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

Forward-Port-Of: odoo/odoo#194485