## Current behavior:
The user Partner Commissions access rights as All Documents or Own Documents and Purchase access rights as User. With this configuration, the user is unable to create new Purchase Orders, and existing Purchase Orders are also not visible in the Purchase module.

## Expected behavior:
The expected behavior is that the user should be able to create and view Purchase Orders with these access rights. Additionally, clarification is required regarding the purpose of the new Partner Commissions access group.

## Steps to reproduce:
- Go to user and assign Partner Commission rights as All or own document.
- On Purchase, select group as User.

## Cause of the issue:
partner_commission adds commission-specific purchase order record rules, but purchase users have no matching purchase-order rule in that module. For mixed-role users, the commission rule ends up restricting standard purchase orders as well.

## Fix:
Apply the module's explicit all-purchase rule to purchase users so mixed users keep base procurement access while commission-only users remain restricted by the commission rules.

opw-6366074

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

Forward-Port-Of: odoo/enterprise#125374

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

Problem:
When scanning the first product, the second move line is clicked immediately after. https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode_picking_batch/static/tests/tours/tour_test_barcode_batch_flows.js#L1529-L1541 If this happens before the first scan has finished, its quantity is incorrectly applied to the second move line that is clicked. This causes a 0 - 3 split instead of a 1 - 2 split, which results in there only being 6 move lines instead of 7.

We updated our quantity on the `currentLine`
https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1478

When finding `currentLine`, we go through `_findLine` and use `this.selectedLineVirtualId`, which is the one that is currently selected in the UI https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1705-L1712

Purpose:
By adding this step, we wait until the first line’s quantity to be updated before it moves on and clicks on the second product.

runbot-941211

Forward-Port-Of: odoo/enterprise#126847
Forward-Port-Of: odoo/enterprise#124162

The fix introduced in https://github.com/odoo/enterprise/commit/9e9c99712ad4b9d58dc7601da41a852e457ad097 didn't account for the fact that `post.get('media_url') ` could return a None value, which in turn would raise en error when trying to concatenate the value later.

This in turn:
- will block syncing of instagram instagram posts
- will raise a traceback when you open the Social Marketing module and the auto-sync kicks in.
### Example traceback
```
Traceback (most recent call last):
[...]
  File "/home/odoo/src/enterprise/saas-19.2/social_instagram/models/social_stream.py", line 86, in _fetch_stream_data
    return self._fetch_instagram_posts()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/social_instagram/models/social_stream.py", line 64, in _fetch_instagram_posts
    values['message'] = (values['message'] + "\n" + post.get('media_url')).strip()
                         ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
TypeError: can only concatenate str (not "NoneType") to str
```

### Solution:
Fallback to an empty string if `post.get('media_url')` yields a None value.

OPW-6449357

Forward-Port-Of: odoo/enterprise#127049
Forward-Port-Of: odoo/enterprise#126987

Steps to reproduce
---
1. Configure a `delivery_easypost` shipping method using the DHL Express carrier.
2. On an international delivery, use Put in Pack to create two or more packages.
3. Validate the delivery.

Issue
---
Validation is blocked with `DHLExpress: rate_error -- DHLExpress multi-shipment rate includes this shipment.`

For an EasyPost multi-shipment order, DHL Express returns the aggregate rate on the first (master) shipment only and adds an informational `rate_error` on the order stating that this rate already covers the whole order, so the remaining shipments carry no rate of their own. The message is not a real error, but `send_shipping` raises on any carrier message whose type is not exempt: https://github.com/odoo/enterprise/blob/534b42def8ae5dc884da4398377f828c49557d6e/delivery_easypost/models/easypost_request.py#L359-L364

`_post_process_ship_response` already detects and clears exactly this harmless message, but only for a hardcoded carrier allowlist introduced in a2de5bc5a14 (`Purolator`, `DPD UK`, `UPS`) that was never extended to DHL Express, so for DHL Express the message survives, reaches the raise, and aborts an otherwise valid shipment: https://github.com/odoo/enterprise/blob/a2de5bc5a14f99b8674c3ee234e4d221b406da0f/delivery_easypost/models/easypost_request.py#L416-L434

`DHL Express` is added to that allowlist so the harmless multi-shipment `rate_error` is posted on the picking and cleared instead of raised. The guard still requires a single `rate_error` carrying the "multi-shipment rate includes this shipment." text with the rate present only on the master shipment, so genuine DHL Express errors keep blocking validation.

opw-6450365

## **Steps to reproduce:**

1. Create a Service product with Create on Order set to Task and Project set to Field service project.
2. Create a Sales Order containing a storable product and a service product.
3. Confirm the Sales Order to generate the project, task, and delivery order.
4. Validate the delivery order.
5. Create and validate a return for the delivery.
6. Create a return of the return to deliver the products again, but do not validate this new delivery.
7. Open the related task and click on Mark as Done button.

## **Issue:**

In a delivery -> return -> return of return workflow, the stock move goes into this code
https://github.com/odoo/enterprise/blob/59b86f106862c3a364ba633a1580d9051f2fe7ca/industry_fsm_stock/models/project_task.py#L89-L90 the traversal repeatedly revisits the same stock moves through move_dest_ids, causing the loop to alternate between the same move recordsets indefinitely. As a result, the loop never terminates, eventually exhausting the memory and raising a `MemoryError`.

## **Solution:**

Track the stock moves that have already been visited and continue the traversal only with unseen destination moves.

Runbot Video : [Video](https://drive.google.com/file/d/1wiqggjx8T-Mtl4T1JgCsfwBbgQU18nYF/view?usp=drive_link)

OPW - 6420961

Problem:
On a flexible working schedule, a time off of a few hours (neither a full nor a half day) was treated as a full day off. The Attendance list then reported the whole day's attendance as overtime, and the Time Off gantt grayed out the entire day instead of only the leave's hours.

Steps to reproduce:
1. Give an employee a flexible working schedule (e.g. 8h/day) with an overtime ruleset based on the contract's expected hours.
2. Record a 2-hour time off, then an 8-hour attendance on the same day.
3. Observe the attendance reports 8 hours of overtime instead of 2.

Current behavior:
A partial time off makes the whole day count as extra hours.

Expected behavior:
Only the hours actually taken off reduce the day's expected hours.

Cause:
For a flexible schedule, _handle_flexible_leave_interval expands a leave to the whole day. The override already narrows full-day and half-day leaves, but any other number of hours fell through to that full-day expansion. The expanded interval is subtracted from the day's expected hours in _work_intervals_batch, so they drop to zero and every worked hour becomes overtime.

Fix:
A leave of an arbitrary number of hours should only remove the hours it actually covers, so it keeps its requested interval instead of being stretched to the whole day.

opw-6291536

**Steps to reproduce:**
* Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules.
* Create two companies with Dutch localization.
* Go to **Accounting → Configuration → Tax Units** and create a Tax Unit with its own **Tax ID** (e.g. `NL826317558B01`), adding both companies.
* On the main company form, fill in the **Omzetbelastingnummer** field (e.g. `123456782B90`).
* Go to **Accounting → Reporting → Tax Return**, select the Tax Unit in the filter, and click **XBRL → Download XBRL File**.

**Observed behavior:**
* The `<xbrli:identifier>` in the exported XBRL file contains the company's **Omzetbelastingnummer** (`123456782B90`) instead of the Tax Unit's VAT (`826317558B01`).
* The tax authority rejects the return because the identifier does not match the fiscal unity registration.

**Cause:**
* `_get_sbr_identifier()` in `l10n_nl_reports_sbr_ob_nummer` unconditionally returns `self.env.company.l10n_nl_reports_sbr_ob_nummer` before consulting the Tax Unit.
* The `super()` call, which correctly routes to `tax_unit.vat` via `report.get_vat_for_export()`, is only reached when the company field is empty — so the Tax Unit's VAT is never used when a company OB-number is set.

**Fix:**
* When a Tax Unit is active in the report options, delegate immediately to `super()._get_sbr_identifier()`, which resolves `tax_unit.vat` through the existing `get_vat_for_export()` logic.
* The company-level `l10n_nl_reports_sbr_ob_nummer` override is preserved as a fallback for the `company_only` (no Tax Unit) case.

opw-6350840

Forward-Port-Of: odoo/enterprise#126999
Forward-Port-Of: odoo/enterprise#125167

**Description**

When printing the legal PDF of a CFE, the report can request a dedicated addenda page (`adenda=true` report parameter) when the addenda does not fit in the small box of the standard report (roughly 6 lines of 140 characters).

`l10n_uy_edi_document._get_report_params()` computed the addenda by calling `self.move_id._l10n_uy_edi_get_addenda()` directly. For e-remito EDI documents created from stock pickings, `move_id` is not set, so the addenda was always empty and the dedicated addenda page was never requested for delivery guides.

**Changes**

- Resolve the addenda from the document origin record: reuse the existing `_get_origin_record()` abstraction. Add it on `l10n_uy_edi.document` (returns the move) and let `l10n_uy_edi_stock` extend it to fall back to `picking_id`; `_get_report_params()` now reads the addenda through it.
- Remove a no-op `_get_pdf()` override in `l10n_uy_edi_stock`.
- Add a unit test covering the dedicated addenda page threshold (6 lines x 140 chars) for delivery guides.

**Note**

This PR replaces branch `adhoc-dev:18.0-t-stock-edi-addenda-fix-kz` (original authorship preserved); resubmitted from a new branch to keep follow-up and tracking with the current maintainer.

Forward-Port-Of: odoo/enterprise#124539