During the rework of the follow-up report, we removed the
"No Follow-Up" field from journal items, making it impossible to exclude
individual journal items from triggering a follow-up.

In this commit we do the following:
-  Re-introduce a field for that, since it is a common
   requirement to be able to exclude individual items from the follow-up
   reports.
   The field is stored on the journal item, but can also be toggled from
   the journal entry. In case of multiple installments on the invoice,
   toggling the field on one installment will toggle it for all
   installments.
-  Adapt the Follow-Up Report and Customer Statement variants of the
   Partner Ledger to add a toggle for the "No Follow-Up" field on each
   report line, that toggles the field on the corresponding journal
   item(s).
-  Prevent the follow-up status on the partner to change when all of the
   overdue journal items are marked as "No Follow-Up".
-  Make sure users can toggle the "No Follow-Up" setting on the invoice
   level when opening the "Overdue Invoices" view from the partner's
   "Accounting" tab.
-  Make sure all receivable/payable lines without a due date (either
   from a manual miscellaneous entry or a PoS entry) are put under the
   "Due" section in the Follow-Up Report instead of the "Overdue"
   section. Since there is no due date, they can't be overdue.
-  Make sure the PDF and XLSX exports of the Follow-Up Report don't
   include the "No Follow-Up" lines, and the customer follow up email
   only includes the amount of the other lines.

Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9
and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615
Task: 5138378

Upgrade PR → https://github.com/odoo/upgrade/pull/8864

## Issue:
When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised:
`Sorry, you are not allowed to access this document`

## Cause:
This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197
However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment
As a result, non-admin users (like demo) triggered an access error during Global Invoice creation

## Steps to reproduce:
- Switch to the MX company
- Create a product with an UNSPSC Category (Accounting Tab)
- Create and Confirm an Invoice for the product (enable CFDI to public)
- Connect as Demo
- Go in Accounting > Customers > Invoices
- Toggle the last created invoice checkbox
- Actions > Create Global Invoice
- Before the fix, the Access Error is displayed
- Check in the invoice Chatter for the Global CFDI document creation success

opw-5181925

Forward-Port-Of: odoo/enterprise#98218

# Description of the issue/feature this PR addresses:

Currently, the constraint `account.account._check_account_type_unique_current_year_earning` raises a validation error when there are more than one accounts of type "Current Year Earnings" in the same company. This is expected behaviour.

However, the ORM will throw an exception if it finds two or more accounts of this type across multiple inactive companies. Example:

```sql
lare_3183476=>
    SELECT COUNT(account.id), account.company_id, company.active
      FROM account_account account
      JOIN res_company company
        ON account.company_id = company.id
     WHERE account.account_type = 'equity_unaffected'
  GROUP BY account.company_id, company.active;
 count | company_id | active
-------+------------+--------
     1 |          1 | t
     1 |          2 | f     --
     1 |          3 | t
     1 |          4 | f     --
     1 |          5 | t
     1 |          6 | t
(6 rows)
```

# Current behavior before PR:

When the above constraint retrieves accounts of type "Current Year Earnings" grouped by their companies, those records belonging to inactive companies are grouped together into an "empty" company, res.company(). This raises an exception due to the definition of the constraint even though the accounts belong to a different company, and therefore, don't break the condition.

# Desired behavior after PR is merged:

To address this issue, we will modify the context of the environment to consider inactive records in the search by disabling the flag `active_test`. Since only two models are involved in the query, and account.account doesn't have a field for active records, this addition will correctly group the accounts in their correct company.

---

upg-3185680
upg-3143424

Thanks to @jlom-odoo for providing initial insights on the problems as well as additional examples.

---

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/18.0/addons/l10n_mx/migrations/2.2/end-migrate.py", line 7, in migrate
    env['account.chart.template'].try_loading('mx', company, force_create=False)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
    return self._load(template_code, company, install_demo, force_create)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/stock_account/models/account_chart_template.py", line 12, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
    self._setup_utility_bank_accounts(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 874, in _setup_utility_bank_accounts
    self.env['account.account']._load_records([
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5503, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1103, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5421, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1036, in write
    res = super(AccountAccount, self.with_context(defer_account_code_checks=True, prefetch_fields=not any(field in vals for field in ['code', 'account_type']))).write(vals)
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 343, in write
    return super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4830, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 42, in _check_account_type_unique_current_year_earning
    raise ValidationError(_('You cannot have more than one account with "Current Year Earnings" as type. (accounts: %s)', [a.code for a in account_unaffected_earnings]))
odoo.exceptions.ValidationError: You cannot have more than one account with "Current Year Earnings" as type. (accounts: [False, False])
```

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

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#233757

When paying with Bancontact, in case a 3DS validation is required (challenge flow), Wordline will send a webhook (see below) to indicate that an external (asynchronous) validation was requested.

Example of recevied webhook:
```
{
  'apiFullVersion': 'v1.1',
  'apiVersion': 'v1',
  ...
  'payment': {
     'status': 'AUTHORIZATION_REQUESTED',
      'statusOutput': {
        'isAuthorized': False,
        'isCancellable': False,
        'isRefundable': False,
        'statusCategory': 'PENDING_CONNECT_OR_3RD_PARTY',
        'statusCode': 51
      }
   },
 'type': 'payment.authorization_requested'
}
```

Since efc2788dfccd, when receiving such webhook we set the transaction as error then force the user flow to `redirect`; this was done to handle payment w/ token (`online_token`) where a 3DS challenge is still required.

But for Bancontact - which is non-tokenizable - we will always be in the "redirect" mode, so we must keep the transaction as `pending`.

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

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

When a FEC file imports journal items, it will create them to draft with reconciliations stated by a matching number starting with "I" (also the case for other some types of imports). Once the entries are posted, the system will create odoo reconciliation records for those journal items.

The issue lies in this part of the code removing the matching when performing reconciliations for the same matching number
https://github.com/odoo/odoo/blob/9d34c7ee85d105a56c3393a3dbb3e5d62d4d634a/addons/account/models/account_partial_reconcile.py#L206

Most of the time it's not a problem for the auto reconcile mechanism of FEC. However since this mechanism reconciles grouped on matching + account, we can end up in a case where a first reconciliation on account A will remove all matching number similar but on account B leading to no automatic reconciliation for them.

This commit aims to fix that by removing amls imported matching number (starting with "I") from the reconciled amls to consider.

opw-5086823

Currently, an error occurs when a portal user opens a `shared project` and tries 
to `mention(@)` someone in the chatter of a `new(unsaved) task`.

**Steps to produce:**

- Install the `project` module.
- Open the project app and create a new project with at least one task.
- From the project’s `dropdown menu(⋮)`, select `Share Project`.
- Add a `collaborator: Joel Willis`, with `Edit access` mode, copy the public link, 
  and click `Share Project`.
- Open the shared link in an incognito window and sign in as a portal user.
- Open the `project folder` > open any task > click `New` > type `'@'` in the chatter.

**Error**:
`ValueError: Expected singleton: project.task()`

**Root cause:**
The `composer(message box)` allows typing and mention suggestions even when 
the task record is not yet saved (`self.thread.id` is `undefined`). At [1], the method 
is called on an `empty` recordset, causing an `error`.

**Fix:**
This commit prevents users from writing in the chatter by stopping the composer 
initialization when the record(thread) is `unsaved`.

[1]:
https://github.com/odoo/odoo/blob/5cf96828652c2388808b3e49ae67e188c401ec63/addons/project/models/project_task.py#L2051-L2071

sentry-6982269693