**Issue** : The computation of `l10n_it_document_type` fails when multiple `l10n_it.document.type` records share the same code. This can happen if a user duplicates an existing Document Type or creates a new one with the same code, causing `get()` on the grouped recordset to return multiple results.

**Traceback :** 
```python
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/fields.py", line 3252, in convert_to_cache
    raise ValueError("Wrong value for %s: %r" % (self, value))
ValueError: Wrong value for account.move.l10n_it_document_type: l10n_it.document.type(1, 23)
```

**Steps to Reproduce:**
1. Install the `l10n_it_edi_ndd` module.
2. Go to Customer Invoices and create a new invoice.
3. Set a Document Type, then confirm the invoice.
4. Open that Document Type and duplicate it.
5. Create another invoice without setting a Document Type, then confirm it.

observation: you will receive a traceback for wrong value error

**Solution :** This fix adds a check to ensure that the `code` field remains unique across all `l10n_it.document.type` records.

opw - 4902513
related upgrade pr : https://github.com/odoo/upgrade/pull/8032

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

Forward-Port-Of: odoo/odoo#218662
Forward-Port-Of: odoo/odoo#217155

Since [^1], we allow reconciliation in draft. To allow that, a mechanism has been added to break the reconciliation when changing certain fields rather instead.
However, resetting to draft was still breaking the reconciliation, which is counter productive.

Reproduce:
* create an invoice
* create a bank statement line with the same amount
* reconcile both in the bank reco widget
* reset the invoice to draft

=> The invoice is not marked as paid anymore, the statement line still has the amount on the receivable account, we need to reconcile manually both lines.

This commit also fixes 2 related issues:
* the test `test_caba_undo_reconciliation` was actually not generating a caba move. Now, it is checking that we unreconcile what we need, when we need, and that it was reconciled in the first place.
* the function `_reconciled_by_number` was not using `sudo`, leading to lines potentially missing from the returned set. However, the logic using it needed to see the whole picture. Instead, we now do the search in `sudo`, while keeping the initial access rights for reading the field if necessary.

task-4873072

[^1]: https://github.com/odoo/odoo/commit/404fbaeeeb16a65900c60f47967d6d79373c6213

Forward-Port-Of: odoo/odoo#214363

### Issue:
There are several issues with the XML of FacturX.

### Steps to reproduce:
- Create a partner with a direct debit mandate
- In the Accounting tab of the partner select "FacturX" as eInvoice format
- Create an invoice with this partner, pay with SDD, confirm
- Send to FacturX
- Verify the PDF with https://www.portinvoice.com/
	1 Missing namespaces
3. In the XML the code for the payment means does not adapt to the payment method: 42 (Payment to bank account) and not 59 (SDD)

### Cause:
1. The namespaces are not there ([doc](https://fnfe-mpe.org/factur-x/factur-x_en/)).
3. We always input "42" as payment mean

### Solution:
1. Added namespaces `xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"` and `xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"`
3. Added the code "59" for SDD, a lot of codes could be added but this commit only handles this one

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4907827)
opw-4907827

Forward-Port-Of: odoo/odoo#219804
Forward-Port-Of: odoo/odoo#217763

To reproduce:
=============
- Install project, voip
- Create a second company
- Switch Company
- Open "Project / Tasks / All Tasks"
- For the first task with activity and assigned to admin, edit the activity and change the date

Problem :
=========
problem in this line :
https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/models/res_partner.py#L259 it's returning users from other companies due to cache pollution. In the ORM, the first time you access an X2many (partner.user_ids), we read it with the access rights of the current user (env.user), depending on the sudo flag (env.su), and put the result in the cache. This cached value remains valid until the end of the transaction. When you access partner.user_ids a second time with a different user and/or sudo=False, the cached value is used, which may return records that you cannot access with the current user. This is an ORM inconsistency that rd-framework-py want to fix, but it is not a small change. This issue has existed since v13.0

Solution :
===========
browse partner.user_ids in sudo mode

PR test link : 
===========
https://github.com/odoo/enterprise/pull/88999

opw-4778418

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

Forward-Port-Of: odoo/odoo#212769

reproduction 1:
1. create a db without website installed
2. In todo, create a link with internal link
3. click on the link, the redirection is 404 not found

reproduction 2:
1. create a db installed website and project
2. In todo, create a link with internal link pointing to a project task
3. click the link, it always redirects to the website homepage

ref pr: https://github.com/odoo-dev/odoo/pull/4465

Before this commit: With the reference PR, we introduced `navbar_link_popover` for the website menu. When the website is in editing mode, if the URL points to a page created by the website, the URL is opened in edit mode (e.g., the website edit button is unfolded). However, this functionality should only be available when the website module is installed. Additionally, the redirection condition need to be refined to apply only to website pages.

After this commit: The navbar-related link code has been moved to the website module, and the link popover is patched with the `onClickForceEditMode` method. This ensures that the functionality is only applicable when the website module is installed.  Note that, in link_plugin, only the added code related to menu item and nav_bar is moved, the more generalized code is kept as it extends the link plugin to support other use cases outside of html_editor.

task-4879511


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

Currently, an error occurs when rescheduling a task's date from the Gantt view.

**Steps to Reproduce:**

 - Install the `project_enterprise` module.
 - Go to `Settings` and enable `Task Dependencies`.
 - Go to `Projects`, create a `project`, and add `two tasks` (Task 1 and Task 2) under that project.
 - Open `Task 2` > `Blocked By`, click `Add a line`, and select `Task 1`.
 - Return to the `project's tasks`, switch to `Gantt View`, and choose `Auto-Reschedule (Keep Buffer)` as the 
   rescheduling method.
 - `Double-click` on any date in the unassigned block, select `Task 1`, and `drag it to next date`.

`TypeError: '>' not supported between instances of 'bool' and 'datetime.datetime'`

This error occurs when rescheduling a task to a forward date, and a dependent
task has no start date. When the parent task is rescheduled, the system
attempts to reschedule the dependent task as well, but since it has no
start date, an error occurs [1] due to condition at [3].

The same error occurs when rescheduling a task to a backward date, and a
depends on task has no deadline date. When the child task is rescheduled,
the system attempts to reschedule the parent task as well, but since it has no
deadline date, an error occurs [2] due to condition at [3].

**Steps to Reproduce for backward rescheduling:**
 - Follow the first 5 steps from the forward rescheduling steps.
  - Remove the Deadline from Task 1, if it has.
 - Double-click on any date in the unassigned block, select Task 2, and drag
   it to previous date.

This commit ensures that the incorrect condition is removed from [3]. Now,
it checks whether the record is a candidate for moving, and both forward
and backward rescheduling are handled safely.

[1]- https://github.com/odoo/enterprise/blob/aaad26c28fd4bc1e94e99717076ecbcf74f5f357/project_enterprise/models/project_task.py#L1209

[2]- https://github.com/odoo/enterprise/blob/8cc8443dc11c176b55f7eb3efa07db5edb7e6b0c/project_enterprise/models/project_task.py#L1221

[3]- https://github.com/odoo/enterprise/blob/302f1a5e82ffbf383d37f003820fe780654fae2f/project_enterprise/models/project_task.py#L1203

sentry-6738017612

[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines()
In big databases, this method called on large recordsets of statement lines would take too much time, or worse: timeout.
This is mainly because the 2 SQL queries are doing too complex searches and hence are badly optimized by the query planner.

To solve that,
* We search for reconciliable accounts outside the queries to avoid a join
* We add a trigram index on statement_line.payment_ref and only use ILIKE operations for reference matching so that it can be used
* Instead of using complex and costly regexp_split, we search for matches by splitting account_move_line.ref on ' - '
* We move some logic in python, amount matching, rather than in sql
* We don't try anymore to match on amounts found in the payment_ref

Additionnally,
* The algorithm now treats the statement lines with and without partner the same for reference matching, but lines without partner are just ignored for the amount matching, as it's way too dangerous
* Bug of with_prefetch, pre-loading the ids of a wrong object, has been fixed
* We revert the patch https://github.com/odoo-dev/enterprise/commit/da52bc70cd745f3e9f7a0539528c84aa47b98cc5 because it was only a temporary measure while the time was back to acceptable
* The test_matching_rules_with_empty_aml_ref, irrelevant, was removed

Benchmark
---------
Importing a csv file of 200 statement lines, on a database of 21M account.move.line, and thus triggering the culprit function, takes (hot timings):

| Before | After | Speed-up |
|--------|-------|----------|
| 185 s  |  52 s |   ~3.5x  |

see https://github.com/odoo/odoo/pull/218642

Forward-Port-Of: odoo/enterprise#90077

Current behavior before commit:

When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction.

Root Cause:

The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises
a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored.

Fix:

Replaced the direct lock date check with _get_lock_date_violations(), which:

- Correctly considers user-specific temporary lock date exceptions.

- Returns violations based on effective lock rules (including hard lock).

- Provides a more generic error message.

Steps to reproduce:

- Use a tax report with carryover values (e.g. Belgian VAT return, line 81).

- Post a refund using a tax that maps to the carryover (e.g. 21% M).

- Generate a closing entry.

- Set the company’s tax_lock_date to a date covering the refund.

- Grant a temporary lock date exception to the user, covering the same date.

- Try to reset the closing entry → Lock date error is raised (incorrectly).

opw-4715100

Forward-Port-Of: odoo/enterprise#87814
Forward-Port-Of: odoo/enterprise#85337

## [PERF] hr_referral: Send refusal notification to referrer's users

Description
-----------
Following https://github.com/odoo/enterprise/commit/764f9b6f513c90eb79935d9e8469989ea704b61b, `_send_notification` will not attach the message on the `hr.applicant` itself, so a `model` was provided.
But due to a missing `res_id`, `message_notify` will set both `model` & `res_id` to `False` since both are not specified. This leads to the creation of a `mail.message` with no `res_id` and no `model` (as `self` is an empty `mail.thread` recordset).

This leads to a performance regression when mail references need to be computed to attach to the notification in `_notify_by_email_get_base_mail_values`, due to the missing `model` and `res_id` of the message.

This commit attaches the notification to the referrer's users instead, providing its `model` and `res_id`.

Reference
---------
opw-4943488

---

## [FIX] hr_referral: Do not send notif when opening the refuse wizard

Description
-----------
Currently, when opening the refusal wizard for an applicant, a call to `archive_applicant` is made. However, there is an override of it in `hr_referral` to send a notification for the applicant's refusal, and closing the `referral_state`, even though the applicant may have not been provided a reason for refusal, and the HR can simply close the wizard instead of confirming it.

This commit removes the override of `archive_applicant` and moves its logic into `action_refuse_reason_apply` which is called when the wizard is confirmed.

Reference
---------
opw-4943488

Forward-Port-Of: odoo/enterprise#90563
Forward-Port-Of: odoo/enterprise#90309

After [this PR](https://github.com/odoo/enterprise/pull/81894) was merged, we are encountering below errors.

**Issue 1:**

An error occurs when attempting to connect a new bank account.

**Step to produce:**

- Install the `account_online_synchronization` module and open `invoicing`.
- Go to: `Configuration > Banks > Add a Bank Account`.
- `Add new bank > Enter Details > Connect`.

**Error:**
`TypeError: AccountOnlineLink.create_new_bank_account_action() takes 2 positional arguments but 3 were given`

**Root cause:**
It appears that removal of `@api.model` was missed in [this PR](https://github.com/odoo/enterprise/pull/89932) during the forward-port process, leading to this error.

**Fix:**
This commit removes `@api.model` so that the method behaves like a recordset method, as done in [this PR](https://github.com/odoo/enterprise/pull/81894).

**Issue 2:**

An error occurs when attempting to Setup Bank.

At [1], when an exception occurs, the method returns an empty list, and this displays the `Setup Bank` button. Upon clicking the button, an error occurs.

[1]
https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_journal.py#L88-L97

**Error:**
`ValueError: Expected singleton: account.online.link()`

**Root Cause:**
At [2], the JS method `fallbackConnectBank` was passing only one positional argument instead of two. However, the corresponding Python method at [3] requires two positional arguments.

[2]
https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L67-L71

[3]
https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_online.py#L418

This commit updates the JS method `fallbackConnectBank` to pass two positional arguments as required by the python method at [3].

sentry–6745764054,6388425767

Forward-Port-Of: odoo/enterprise#90225