When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in payment_ref.

If this payment refs contains only spaces (eg. ' '), it will trigger an index out of range traceback. This is explained by the fact that spaces are striped then '' is considered as False in some filtering leaving the list empty.

From the UI, putting ' ' is not supposed to be possible because spaces are striped before write but there is many ways to import statement lines which may lead to this hence the decision of handling this scenario to make the code more robust.

Steps to reproduce:
1/ Create two statement lines with payment_ref as ' ' (you can force it using a write)
2/ Click "Set account" on first one and pick 100000 Issued Capital
3/ Do the same for the second statement line
=> Traceback

In this commit, we do not check for common substring if there is less than two
labels.

opw-6379977

Forward-Port-Of: odoo/enterprise#125779

**Description of the issue/feature this PR addresses:**

When a document is rejected by a signer, the notification email sent to
other involved parties incorrectly displays the recipient's name in the
subject line instead of the person who actually refused to sign.

This occurs because the subject string was using `partner.name` (the
current email recipient) instead of `refuser.name`. This commit updates
the string to reference the refuser, ensuring the subject accurately
identifies the individual who rejected the document.

**Steps to reproduce:**

- Sign > upload any PDF > add signature request for 2 different signers > Send > choose signers, e.g. Abigail Carter and Marc Demo > Send
- Settings > Technical > Emails > Emails
  - Select one of the sent emails > Sign document > sign > Validate & Send Completed Document
  - Select the other email > Sign document > top-right dropdown arrow > Decline to sign > Decline
- Settings > Technical > Emails > Emails
  - Observe that all emails sent state that the recipient of the email rejected the signing


**Current behavior before PR:**

- Rejection email subject states that the recipient refused to sign

**Desired behavior after PR is merged:**

- Rejection email subject states that the refuser refused to sign

opw-6421188

Forward-Port-Of: odoo/enterprise#126412

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows: 
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users
`(role.user_ids)` within the core task-copying logic in both `project` and
`project_enterprise` modules. This ensures archived users are universally
excluded from task assignments during template copying, regardless of what
triggers the template instantiation.

Related Enterprise PR: https://github.com/odoo/enterprise/pull/125637

opw-6350841

Description of the issue/feature this PR addresses:

A user without accounting rights cannot open an invoice form when l10n_es_edi_verifactu is installed.

The module adds a VeriFactu page and three warning banners to the standard invoice form without any groups restriction, so every user able to open an invoice reads three fields (l10n_es_edi_verifactu_document_ids, l10n_es_edi_verifactu_warning, l10n_es_edi_verifactu_warning_level) pointing at l10n_es_edi_verifactu.document.

That model only grants read access to account.group_account_invoice and account.group_account_readonly.

Steps to reproduce:
- install `l10n_es_edi_verifactu`
- create a salesman user with sales rights but no accounting right (*Own Documents Only* is enough)
- create an ES company and an ES customer
- give the salesman access to the ES company
- activate Peppol in the general settings
- log in as the salesman
- create a sale order in the ES company for the ES customer
- confirm it
- click **Create Invoice**
- click **Create Draft**

Current behavior before PR:

An error access is raised:

Failed to read field account.move.l10n_es_edi_verifactu_document_ids

You are not allowed to access 'Veri*Factu Document' (l10n_es_edi_verifactu.document) records.

This operation is allowed for the following groups:
	- Invoicing/Billing
	- Technical/Show Accounting Features - Readonly

Contact your administrator to request access if necessary.


In Odoo sh (for databases 19.0), the standard test sale_management / TestSaleFlowTourPostInstall.test_basic_sale_flow_with_minimal_access_rights fails  for the same reason as soon as l10n_es_edi_verifactu is installed alongside sale_management.

Desired behavior after PR is merged:

On a database with l10n_es_edi_verifactu installed, a non-accountant user having the possibility to create invoices should not have the error message displayed.


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

Forward-Port-Of: odoo/odoo#280879

**Steps to reproduce:**
1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Create a website for the belgian company and enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Open the website, add any product to cart, go to checkout and make a payment using SEPA

**Issue:**
- Check the transaction in Stripe dashboard: the order reference is currently sent only
in the `Description` field which is for internal information and is not shown to
customers on their bank statements. Customers only see "MACKNET", so they cannot
identify which order the payment relates to.

**Expected behavior:**
- Should also send the order reference to Stripe's `statement_descriptor` field, which
is the field used for the customer-facing bank statement reference.
- The `statement_descriptor` value must comply with Stripe's requirements:
Must not contain <, >, \, ', ", or *
Must contain at least one letter
Maximum 22 characters

**Fix:**
- Pass the order reference, which should already satisfy the first two requirements based
on Odoo order/invoice naming conventions

opw-6424994

Forward-Port-Of: odoo/odoo#280985

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

Forward-Port-Of: odoo/odoo#280747
Forward-Port-Of: odoo/odoo#273929

## Steps to reproduce:
	- Install Employee
	- Create a 2-week working schedule and set it as the company default
	- Try to create a new working schedule
	- Notice when you click save a ValidationErroe arise


## Cause:
Two parts where causing this. First when creating a new calendar and
we try to fetch default attendances we don't set the sequence in the
newly created attendances

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L735-L749

so it will get the default value which is 10 so when calling onchange for 
the attendance_ids_1st_week and attendance_ids_2nd_week each attendance
will be set to the odd_week_seq

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L184-L200

which will then make this condition fail

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L615-L616

Second part was related to the `two_weeks_calendar` when saving,
its value won't be passed to the vals_list in `web_save()` as when
we read the values to be changed we ignore readonly fields and since
two_weeks_calendar was used in invisible condition but isn't defined
in a separate `<field>` the view create a tag for it

`
<field name='two_weeks_calendar' invisible='True' readonly='True' data-used-by='invisible='flexible_hours or not two_weeks_calendar' (page,working_hours)' on_change='1'/>
`
This tag would be readonly by default so when the ArchParser
gets each field's info it puts `two_weeks_calendar` as a readonly
field and ignore it in the creation values

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/web/static/src/views/fields/field.js#L276-L279

which then fails this condition and pass all the 2 weeks attendances in the else condition

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L134-L138

After fixing this another bug was found where if you saved the calendar
the attendances will disappear. This was happening when we create the
resource.calendar.attendance records it will call the inverse method
of the attendance_ids_1st_week and attendance_ids_2nd_week where they are
still not computed so it will set attendance_ids to empty

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L152-L156

so after when computing the two weeks attendance it will be empty
as well and it will disappear.

Last bug was if after creating this you tried to switch the calendar
type it will call the same validation error mentioned earlier. As when
calling _get_default_attendance_ids it will try to create attendances
from the company's default working schedule which will have a conflict
since the company's schedule is 2-weeks schedule and we are switching
our schedule to 1-week schedule so we are gonna have attendances for 2-weeks
in 1-week schedule so it will fail the same condition

https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/resource/models/resource_calendar.py#L615-L616

## Fix:
To fix those issues we needed to set the sequence values when copying
the data of the company's schedule when computing the default values. 

Also we need to skip the inverse method when we are still upon creating the records
and to do so we are passing a context in the create method to skip
the inverse.

Last we need to check for the difference between the schedule type and the
company's schedule when fetching the default attendances.

opw-6374237

Forward-Port-Of: odoo/odoo#279182

[FIX] mail: attach dropped files to the message in edition

Root cause:
When editing a message in the chatter, the composer shown inside the message does not get the dropzoneRef prop, so it does not create its own dropzone:
https://github.com/odoo/odoo/blob/5ca10578a2fd1b40cd371ed5ad20c1654dfe54d3/addons/mail/static/src/core/common/composer.js#L197-L209

The chatter creates a dropzone covering the whole chatter that saves dropped files as attachments of the record:
https://github.com/odoo/odoo/blob/5ca10578a2fd1b40cd371ed5ad20c1654dfe54d3/addons/mail/static/src/chatter/web/chatter_patch.js#L106-L138

Since the composer of the message in edition has no dropzone, a file dropped on it is caught by the chatter dropzone and ends up attached to the record instead of the message.

Fix:
Pass the message body as dropzoneRef to the composer in message.xml. The composer then creates its own dropzone over the message, the same way the chatter composer gets one from chatter.xml, and the dropped file is added to the message in edition.

The chatter dropzone and the thread composer dropzone cover that same area and would show at the same time, so both are turned off while a message is in edition. The thread already knows which message that is through messageInEdition, so neither of them has anything to keep track of.

Steps to reproduce:
1. Open the Contacts app and open any contact
2. Click Log note, type some text and click Log
3. Hover the note and click the pencil icon to edit it
4. Drag a file from the file explorer and drop it on the note

=> the file is added to the attachments of the contact instead of the note

Ticket [link](https://www.odoo.com/odoo/project.task/6385377)

opw-6385377

Forward-Port-Of: odoo/odoo#278373