**Description:**
While loading the budget report, the bad queries are created by 
```def _get_aal_query()``` and ```def _get_pol_query()``` function, makes 
the budget report unusable.

**Root cause:**
Instead of doing a hash join while searching the record,
 the OR statement in the Left Join in the condition 
```(%(bl)s IS NULL OR %(a)s = %(bl)s)``` 
creates a nested for loop that compares everything single aal to bl, 
this causes a significant performance issue as the number of the 
number of check will be the the number aal * bl,
if a database has a 70k aal and 20k bl, both numbers are not large
but it will cause a 70k * 20k search which is more than a billion.

**Fix**:
There are some refactors made in this PR.

_First_, separate out the Q1.
In order to find the aal that has no bl connects to it. 
Doing a search to find the aals that have bl and then subtract them from all aals.

_Second_, Instead of doing a nested loop for by using
 ```(%(bl)s IS NULL OR %(a)s = %(bl)s)```, 
originally we will have do something like
```
JOIN budget_line bl
  ON (bl.x_plan2_id IS NULL OR aal.x_plan2_id = bl.x_plan2_id)
 AND (bl.x_plan3_id IS NULL OR aal.x_plan3_id = bl.x_plan3_id)
 AND (bl.x_plan4_id IS NULL OR aal.x_plan4_id = bl.x_plan4_id)
```
Assuming each bl has three plans ```x_plan2_id```, ```x_plan3_id```, ```x_plan4_id```

Grouping the bl base on whether a specific plan is set, (i.e. shapes)
we can skip the ```IS NULL OR``` because we already know which plan
 is null and do the hash join directly.

For example, the shapes will be a dictionary with a key of a tuple of booleans
based on whether a plan is set or not and the value is a list of bl_id.

```
{
    (True, False, False): [1, 2],
    (False, True, True):  [3, 4],
    (False, False, False): [5],
}
```

we can end up doing something like

```
JOIN budget_line bl
 ON bl.id = ANY(ARRAY[3,4])
 AND aal.x_plan3_id = bl.x_plan3_id AND aal.x_plan4_id = bl.x_plan4_id
```
which is way more faster.

---
The benchmark is made locally from this client's database which contains
 69k aal, 23k bl, 6829 pol and 3 plans for aal and bl.

|Record count                                      |Time before|Time after|
|--------------------------------------------------|-----------------|---------------|
|69k aal, 23k bl, 6829 pol, 3 plans    |70.04s         |4.6s            |

Dalibo:

Before: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/8h3d4e89aaf9f3d4
Overall grand total by company:
https://explain.dalibo.com/plan/445g1f9caf4923e2
Month-over-month grand total by plan: 
https://explain.dalibo.com/plan/53a138ca50b2a7c4
Overall grand total by plan: 
https://explain.dalibo.com/plan/hdbe169ddc7g5785

After: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/hcc86c801e6872bf
Overall grand total by company:
https://explain.dalibo.com/plan/69b2421a3581f98h
Month-over-month grand total by plan:
https://explain.dalibo.com/plan/a88f398bbbch3148
Overall grand total by plan: 
https://explain.dalibo.com/plan/1gg749ae7ab1553c

opw-6345552

Forward-Port-Of: odoo/enterprise#127732
Forward-Port-Of: odoo/enterprise#124161

Currently an exception is generated when the user tries to export (downlaod) a
`CSV` file of the `General Ledger` report as the below step:
- Install the `accountant` module with demo data
- Enable and change to the `French` language
- Go to `Comptabilité` > `Analyse` > `General Ledger`
- Click the cog icon in the menu > Click on `CSV`
- An error occurs in the log, and nothing is downloaded

Error: `TypeError: 'NoneType' object is not subscriptable`

This issue occurs after the recent refactoring changes in [1]. When
`_generate_csv_lazy_export` is called, it uses the `_()` method for
translation, which accesses `self.env`. However, at this point, the cursor
is already closed. As a result, when the code at [2] is reached from
`ormcache`, it raises the above error because
`model.env.transaction.ormcaches__` is `None` (code ref [3]).

This commit fixes the above issue by performing the translation
using the existing `handler` variable, which contains an environment
with the new cursor (see code ref [4]).


[1]: https://github.com/odoo/odoo/commit/13c3adf3a8b5ba6325190d6b9aea45fb8a6a8b2f
[2]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/cache.py#L111
[3]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/environments.py#L1012
[4]: https://github.com/odoo/enterprise/blob/912a47b8f0828ef8316b7e4ecdabf8a2f305b313/account_reports/models/account_general_ledger.py#L524

Sentry-7608119520

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#127733
Forward-Port-Of: odoo/enterprise#124096

This commit fixes a couple things with this tour:
    
1. We need to confirm the dialog that appears when we try to confirm the payrun itself

2. Depending on whether or not a particular l10n_XX module is installed, the trigger that we were previously using to check whether or not a payslip had been confirmed, `.btn[name='action_payment_report']` might not be there; i.e., l10n_us_hr_payroll, among others: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/l10n_us_hr_payroll_account/views/hr_payslip_run_views.xml#L11-L13

   It can be seen there ^ that that button is invisible under a slightly different condition than the base `hr_payroll` version of that button, causing an inconsistency in this test when that module is installed: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/hr_payroll/vie
ws/hr_payslip_run_views.xml#L175

   We resolve this by checking for either button in that step: `trigger: ".btn[name='action_paid'], .btn[name='action_payment_report']"`

runbot-243607

…ern pypdf backend

`export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is opened. the old PyPDF2

`odoo.tools.pdf` picks its backend dynamically it first tries to import PyPDF2==2.12.1  and only falls back to the modern `pypdf` library if PyPDF2 is not importable, which is the case on Python 3.13 per requirements.txt, or on any worker where PyPDF2 failed to install.

The PyPDF2-based writer still exposes `setPageMode`, so the bug was never seen on backends using it. The modern pypdf-based writer replaced that method with a `page_mode` property (getter/setter) and never kept a camelCase alias for it

As a result, any request hitting this code got a beautiful HTTP 500
    `AttributeError: 'BrandedFileWriter' object has no attribute 'setPageMode'`

`setPageMode` is not called anywhere else so
this fixes the call site directly instead of adding a new alias to the shared _pypdf.py

opw-6382905

Forward-Port-Of: odoo/enterprise#124480

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 Community PR: https://github.com/odoo/odoo/pull/274426

opw-6350841

Forward-Port-Of: odoo/enterprise#125637

**Description:**
While loading the budget report, the bad queries are created by 
```def _get_aal_query()``` and ```def _get_pol_query()``` function, makes 
the budget report unusable.

**Root cause:**
Instead of doing a hash join while searching the record,
 the OR statement in the Left Join in the condition 
```(%(bl)s IS NULL OR %(a)s = %(bl)s)``` 
creates a nested for loop that compares everything single aal to bl, 
this causes a significant performance issue as the number of the 
number of check will be the the number aal * bl,
if a database has a 70k aal and 20k bl, both numbers are not large
but it will cause a 70k * 20k search which is more than a billion.

**Fix**:
There are some refactors made in this PR.

_First_, separate out the Q1.
In order to find the aal that has no bl connects to it. 
Doing a search to find the aals that have bl and then subtract them from all aals.

_Second_, Instead of doing a nested loop for by using
 ```(%(bl)s IS NULL OR %(a)s = %(bl)s)```, 
originally we will have do something like
```
JOIN budget_line bl
  ON (bl.x_plan2_id IS NULL OR aal.x_plan2_id = bl.x_plan2_id)
 AND (bl.x_plan3_id IS NULL OR aal.x_plan3_id = bl.x_plan3_id)
 AND (bl.x_plan4_id IS NULL OR aal.x_plan4_id = bl.x_plan4_id)
```
Assuming each bl has three plans ```x_plan2_id```, ```x_plan3_id```, ```x_plan4_id```

Grouping the bl base on whether a specific plan is set, (i.e. shapes)
we can skip the ```IS NULL OR``` because we already know which plan
 is null and do the hash join directly.

For example, the shapes will be a dictionary with a key of a tuple of booleans
based on whether a plan is set or not and the value is a list of bl_id.

```
{
    (True, False, False): [1, 2],
    (False, True, True):  [3, 4],
    (False, False, False): [5],
}
```

we can end up doing something like

```
JOIN budget_line bl
 ON bl.id = ANY(ARRAY[3,4])
 AND aal.x_plan3_id = bl.x_plan3_id AND aal.x_plan4_id = bl.x_plan4_id
```
which is way more faster.

---
The benchmark is made locally from this client's database which contains
 69k aal, 23k bl, 6829 pol and 3 plans for aal and bl.

|Record count                                      |Time before|Time after|
|--------------------------------------------------|-----------------|---------------|
|69k aal, 23k bl, 6829 pol, 3 plans    |70.04s         |4.6s            |

Dalibo:

Before: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/8h3d4e89aaf9f3d4
Overall grand total by company:
https://explain.dalibo.com/plan/445g1f9caf4923e2
Month-over-month grand total by plan: 
https://explain.dalibo.com/plan/53a138ca50b2a7c4
Overall grand total by plan: 
https://explain.dalibo.com/plan/hdbe169ddc7g5785

After: 
Month-over-month grand total by company:
https://explain.dalibo.com/plan/hcc86c801e6872bf
Overall grand total by company:
https://explain.dalibo.com/plan/69b2421a3581f98h
Month-over-month grand total by plan:
https://explain.dalibo.com/plan/a88f398bbbch3148
Overall grand total by plan: 
https://explain.dalibo.com/plan/1gg749ae7ab1553c

opw-6345552

Forward-Port-Of: odoo/enterprise#127581
Forward-Port-Of: odoo/enterprise#124161

…ern pypdf backend

`export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is opened. the old PyPDF2

`odoo.tools.pdf` picks its backend dynamically it first tries to import PyPDF2==2.12.1  and only falls back to the modern `pypdf` library if PyPDF2 is not importable, which is the case on Python 3.13 per requirements.txt, or on any worker where PyPDF2 failed to install.

The PyPDF2-based writer still exposes `setPageMode`, so the bug was never seen on backends using it. The modern pypdf-based writer replaced that method with a `page_mode` property (getter/setter) and never kept a camelCase alias for it

As a result, any request hitting this code got a beautiful HTTP 500
    `AttributeError: 'BrandedFileWriter' object has no attribute 'setPageMode'`

`setPageMode` is not called anywhere else so
this fixes the call site directly instead of adding a new alias to the shared _pypdf.py

opw-6382905

When creating an employee declaration without selecting an employee, a traceback occurs.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll`` module with demo data
- Switch to Belgian company
- Go to Payroll > Reporting > Individual Accounts > Create a new Individual Account >
  Click on Eligible Employees > Create a new employee declaration without employee > Save

Traceback:
```py
ValueError: Expected singleton: hr.employee()
```

https://github.com/odoo/enterprise/blob/000544c3d5b93e194264e15bb73d9599525106e3/hr_payroll/models/hr_payroll_employee_declaration.py#L71
The ``_compute_version_id()`` method calls ``_get_version()``.
When ``employee_id`` is empty, ``_get_version()`` is invoked on an empty ``hr.employee`` record,
and its ``ensure_one()`` call raises the above traceback at [1].

[1]: https://github.com/odoo/odoo/blob/3c358ae2badad69b125695a97b4a14e8ab77fccd/addons/hr/models/hr_employee.py#L745-L750

sentry-7625826444

Forward-Port-Of: odoo/enterprise#125175

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#127733
Forward-Port-Of: odoo/enterprise#124096

Steps to reproduce
---
1. Enable Storage Locations and Lots & Serial Numbers.
2. Add a putaway rule sending a lot-tracked product from WH/Stock to WH/Stock/Shelf 1.
3. Confirm a receipt reserving 2 units of that product; putaway sets the reserved move line destination to WH/Stock/Shelf 1.
4. In the Barcode app, scan a first lot, then a second lot.

The second lot lands on a separate line at WH/Stock instead of WH/Stock/Shelf 1.

Issue
---
The first lot reuses the reserved line and keeps its Shelf 1 destination. The second lot cannot reuse it because its tracking number differs, so `_findLine` returns nothing and `_getNewLineDefaultValues` builds a new line with `location_dest_id` set to `_defaultDestLocation()`, the picking's default destination (WH/Stock).

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L1591-L1601

Putaway relocates the destination on the move line at reservation, never on the picking, so only the reserved line carries Shelf 1. Since `groupKey` includes `location_dest_id`, the new line does not group with the first lot and shows separately at WH/Stock. This is not a regression: new lines have always defaulted to the operation destination.

https://github.com/odoo/enterprise/blob/314a79b774f30dc9377b2971492576c4b84483e1/stock_barcode/static/src/models/barcode_picking_model.js#L239-L241

The new line now inherits the selected line's `location_dest_id`, already relocated by putaway, instead of the default.

opw-6317077

Forward-Port-Of: odoo/enterprise#125309

**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Start Date** and **End Date** fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Reports → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written.
* Inside the header loop, set `annotations_header_written = True` after writing the header.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header.

opw-6354473

Forward-Port-Of: odoo/enterprise#127726
Forward-Port-Of: odoo/enterprise#122768

**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

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#127733
Forward-Port-Of: odoo/enterprise#124096

Version: saas-18.3

Reported issue:
1. Marc Demo creates a sign request from a template whose fields are automatically populated from the linked record.
2. It is sent to himself. He does not have access to all records of a referenced model (e.g. Sales Orders).
3. The "Linked To" (reference_doc) field is edited afterwards to point to a record the signer does not have access to. By the time it's signed, the value of that record becomes visible - so a user can, simply by changing the linked record, see the value of a record they were never authorized to access. Even a Sign Manager could link a request to a record they have no access to and later see its value through it.

Issue:
`reference_doc` could be set or changed to any record of any allowed model with no validation that the acting user actually has access to it. In the interface, you can only create a signature request from a record you can see, but editing `reference_doc` manually (via write(), RPC, etc.) was not held to the same rule, making it an easy way to leak information about records outside your normal access.

Cause:
The only restriction was cosmetic, enforced client-side by the record picker widget filtering its search results. Nothing on the server validated the value being written to `reference_doc`.

Fix:
`write()` now checks that the acting user has read access to the target record before allowing `reference_doc` to be set, raising a ValidationError otherwise, bringing manual edits in line with what the interface already enforces when creating a request.

Forward-Port-Of: odoo/enterprise#127715

**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Start Date** and **End Date** fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Reports → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written.
* Inside the header loop, set `annotations_header_written = True` after writing the header.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header.

opw-6354473

Forward-Port-Of: odoo/enterprise#127726
Forward-Port-Of: odoo/enterprise#122768

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#127733
Forward-Port-Of: odoo/enterprise#124096

Version: saas-18.3

Reported issue:
1. Marc Demo creates a sign request from a template whose fields are automatically populated from the linked record.
2. It is sent to himself. He does not have access to all records of a referenced model (e.g. Sales Orders).
3. The "Linked To" (reference_doc) field is edited afterwards to point to a record the signer does not have access to. By the time it's signed, the value of that record becomes visible - so a user can, simply by changing the linked record, see the value of a record they were never authorized to access. Even a Sign Manager could link a request to a record they have no access to and later see its value through it.

Issue:
`reference_doc` could be set or changed to any record of any allowed model with no validation that the acting user actually has access to it. In the interface, you can only create a signature request from a record you can see, but editing `reference_doc` manually (via write(), RPC, etc.) was not held to the same rule, making it an easy way to leak information about records outside your normal access.

Cause:
The only restriction was cosmetic, enforced client-side by the record picker widget filtering its search results. Nothing on the server validated the value being written to `reference_doc`.

Fix:
`write()` now checks that the acting user has read access to the target record before allowing `reference_doc` to be set, raising a ValidationError otherwise, bringing manual edits in line with what the interface already enforces when creating a request.

Forward-Port-Of: odoo/enterprise#127715

Version: saas-18.3

Reported issue:
1. Marc Demo creates a sign request from a template whose fields are automatically populated from the linked record.
2. It is sent to himself. He does not have access to all records of a referenced model (e.g. Sales Orders).
3. The "Linked To" (reference_doc) field is edited afterwards to point to a record the signer does not have access to. By the time it's signed, the value of that record becomes visible - so a user can, simply by changing the linked record, see the value of a record they were never authorized to access. Even a Sign Manager could link a request to a record they have no access to and later see its value through it.

Issue:
`reference_doc` could be set or changed to any record of any allowed model with no validation that the acting user actually has access to it. In the interface, you can only create a signature request from a record you can see, but editing `reference_doc` manually (via write(), RPC, etc.) was not held to the same rule, making it an easy way to leak information about records outside your normal access.

Cause:
The only restriction was cosmetic, enforced client-side by the record picker widget filtering its search results. Nothing on the server validated the value being written to `reference_doc`.

Fix:
`write()` now checks that the acting user has read access to the target record before allowing `reference_doc` to be set, raising a ValidationError otherwise, bringing manual edits in line with what the interface already enforces when creating a request.

Forward-Port-Of: odoo/enterprise#127715

#### Description of the issue/feature this PR addresses:
The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it raises AttributeError: 'hr.employee' object has no attribute '_create_multi_appraisals'.

#### Current behavior before PR:
Commit 8845eb2ac29 replaced the multi-appraisal flow with hr.appraisal.campaign.wizard: it deleted _create_multi_appraisals and repointed the employee list header button to action_open_appraisal_campaign_wizard, but left the action_create_multi_appraisals record in hr_appraisal/views/hr_employee_views.xml. Its code is now the only reference to the deleted method, so the action crashes whenever it is run.

#### Desired behavior after PR is merged:
The dangling action is gone. Requesting appraisals for several employees at once is done with the "Launch Campaign" button already present in the Employees list view; action_open_appraisal_campaign_wizard reads active_ids when active_model is hr.employee and pre-fills the selected employees.

Nothing references the removed xml id, and the record is not noupdate, so _process_end removes it from existing databases on update; no migration script is required. Verified on a 19.0 database: with the orphan record loaded, updating hr_appraisal with this change deletes it.

opw-6408609

### Steps to Reproduce:
1. Create a sign request and have 3 total signers (User, Customer, Employee)
2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee
But make the User and Employee the same contact
3. Send and sign the request > Notice that (1) is able to sign for (3) immediately after, (2) has not signed yet.

### Description of the issue/feature this PR addresses: 
**Issue:** The signing order is ignored when the same user has to sign multiple times on a document, even if it is configured for a different person to sign in between. This happens because all signature request items are initialized in the 'sent' state upon creation, rather than strictly advancing based on the order. As a result, the system prematurely allows users to sign out of order and prompts them with their next turn too early.

**Solution:** To resolve this,  the controller was updated to include an `is_mail_sent = True` domain filter. This ensures that the UI's post-sign popup only displays documents where it is explicitly the user's active turn, rather than prompting a premature sign.

### Current behavior before PR: 
Users are able to sign prematurely, and the system will disregard the configured signing order.

### Desired behavior after PR: 
Users will only be prompted and able to sign a document when it is explicitly their turn, per the `mail_sent_order`. This way, documents are signed in order.

opw-6417327