As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

Forward-Port-Of: odoo/enterprise#126764

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

### Issue:
When accessing the Bank Reconciliation view directly via URL or bookmark, auto-matching with reconciliation models may not trigger and the upload button may be visible on synchronized journals

### Cause:
`_action_open_bank_reconciliation_widget` injects two context keys:
- `auto_statement_processing`: triggers auto-reconciliation on statement creation
- `bank_statements_source`: hides the upload button for synchronized journals

When the view is accessed directly, these keys are not present, causing the UI to ignore them

`auto_statement_processing` is now set directly in the user context via `onWillRender`/`onWillDestroy` in `BankRecKanbanController` `bank_statements_source` requires an ORM call to fetch the journal's value and is resolved via `fetchBankStatementsSourceInto` on startup

Notes:
The fix for `bank_statements_source` was added opportunistically while addressing `auto_statement_processing`

Steps to reproduce:
- Install `accountant` with demo data
- Duplicate the Bank Journal and set Bank Feeds to Online Synchronization
- Open the Accounting Dashboard and open the Bank (copy)
- Create a transaction (Label: Test, any amount) and click Add & Close
- In the 3 dots menu, choose Manage Models
- Create a Reconciliation Model (Label contains: Test, Lines: any account, default values)
- Click Automate
- Go back to the Bank Reconciliation page and verify:
 -- The transaction is reconciled automatically
 -- No Upload button is displayed
- Create a new transaction, it should be reconciled automatically
- Copy the URL and open it in a new tab
- Create a new transaction

Before the fix, the transaction is not reconciled and the Upload button is present

opw-6391107

Forward-Port-Of: odoo/enterprise#126909
Forward-Port-Of: odoo/enterprise#126359

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

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#126790
Forward-Port-Of: odoo/enterprise#122038

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

Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed.

### Steps to reproduce

- In Documents, share a folder with a portal user and set an expiration date.
- Wait until the expiration date has passed.
- Share the same folder with the same user again from the invite box.

=> The dialog says the member was added, but the user has no access and does not appear under "People with access".

### Cause

The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success.

### Fix

Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged.

opw-6387559

Forward-Port-Of: odoo/enterprise#127050
Forward-Port-Of: odoo/enterprise#125140

As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

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

### Steps to reproduce:
- Set the environment timezone (`env.tz`) to a timezone ahead of UTC (e.g., Europe/Brussels)
- Run the enterprise tests (L10n standalone, Single app, or Multi l10n) during the late evening in UTC (e.g., 23:00 UTC)

> UserError: The Payment Date cannot be later than the Value Date, please make sure that the
correct dates are set

### Cause of Issue:
In the payroll payment report wizards, a race condition occurs around midnight due to mismatched timezone context evaluations between different date fields. The `effective_date` field (defined in the base hr_payroll module) derives its default value using `fields.Date.context_today`, which correctly applies the client's timezone offset to the current server time.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L23-L26

However, `l10n_sa_wps_value_date` (and similar date fields in other localizations like AU, HK, AE) derives its default value using `fields.Date.today()`, which strictly relies on the server's UTC time.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/l10n_sa_hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L13-L14

When the nightly Runbot builds execute late at night UTC time, the environment timezone frequently crosses midnight into "tomorrow" while the server time is still on "today". Because of this offset, `effective_date` rolls over to tomorrow, but `l10n_sa_wps_value_date` evaluates as today + 1 day (which is also tomorrow). The validation check `effective_date >= l10n_sa_wps_value_date` evaluates to True.
https://github.com/odoo/enterprise/blob/54b7035b4cb6b9427092a3eebe73f2bee7f2ae09/l10n_sa_hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L93-L94

### Fix:
Standardize the default date computations to ensure they are all evaluated within the same timezone context and prevent the midnight timezone rollover discrepancy.

runbot-937793

Forward-Port-Of: odoo/enterprise#126718
Forward-Port-Of: odoo/enterprise#125364

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

Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed.

### Steps to reproduce

- In Documents, share a folder with a portal user and set an expiration date.
- Wait until the expiration date has passed.
- Share the same folder with the same user again from the invite box.

=> The dialog says the member was added, but the user has no access and does not appear under "People with access".

### Cause

The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success.

### Fix

Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged.

opw-6387559

Forward-Port-Of: odoo/enterprise#127050
Forward-Port-Of: odoo/enterprise#125140

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

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

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

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

Forward-Port-Of: odoo/enterprise#126003

When opening reports with `default_opening_date_filter='this_year'`(e.g., P&L, Partner Ledger), the date filter dropdown showed incorrect defaults for non-selected period types:
- Month showed the last month of the fiscal year (e.g., December)
  instead of the current month
- Quarter showed Q4 instead of the current quarter

This happened because `initDateFilterState()` used the backend's `date_to` (fiscal year end) as the reference for computing all filter periods. For `this_year`, `date_to` is the year-end date (e.g., 2026-12-31), so `computePeriodRange()` for month/quarter returned periods containing that date rather than today's date. Reports with `this_month` or `today` defaults were unaffected because their `date_to` is naturally close to today.

Now, non-selected filters use today as their reference date on initial load whenever today falls within the report period, while the selected filter continues to use the backend's `date_to`, preserving the alignment behavior introduced in the date filter refactor (https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7).

Additionally, selecting the custom comparison filter now triggers an immediate reload so its default date range is recomputed by the backend. The custom comparison range is initialized using the current fiscal year up to today, capping its end date to today instead of inheriting the report's `date_to`, which could otherwise default to a future date for yearly reports.

task-6229588

## Behavior Before the PR
When an employee did not have explicit `hours_from` and `hours_to` values defined, their shift was in the **Schedule by X** pivot view but was not included in the **Planning / Timesheets Analysis** report.

## Steps to Reproduce
1. Create an employee with a Flexible Working Schedule in the Employee form, or configure working hours where both `Hour from` and `Hour to` are left unset.
2. Add a shift for this employee linked to a project and a task.
3. Publish the shift.
4. Navigate to **Planning → Schedule → By Project**, switch to the pivot view, and observe that the shift created in step 2 appears and is counted.
5. Navigate to **Planning → Reporting → Planning / Timesheets Analysis**, switch to the pivot view, and observe that the same shift does not appear.

## Behavior After the PR
When an employee does not have explicit `hours_from` and `hours_to` values, their shift is now considered valid in both the **Schedule by X** views and the **Planning / Timesheets Analysis** report.

## Additional Notes
- In earlier versions of Odoo, the `Work From` and `Work To` fields were mandatory. With a change to flexible working schedules and the option to define only the total number of hours per day, these fields may now be left empty. This change exposed the underlying issue addressed by this fix.

task-[5969788](https://www.odoo.com/odoo/project/4105/tasks/5969788)

Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed.

### Steps to reproduce

- In Documents, share a folder with a portal user and set an expiration date.
- Wait until the expiration date has passed.
- Share the same folder with the same user again from the invite box.

=> The dialog says the member was added, but the user has no access and does not appear under "People with access".

### Cause

The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success.

### Fix

Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged.

opw-6387559

Forward-Port-Of: odoo/enterprise#127050
Forward-Port-Of: odoo/enterprise#125140

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

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

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

Forward-Port-Of: odoo/enterprise#126003

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

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

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

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

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

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

### Steps to Reproduce:
1. Go to Helpdesk and create an SLA
2. Create a new Ticket
3. Use Studio to add the field `sla_reached`
4. Apply the SLA
5. Notice that the field is True

### Description of the issue/feature this PR addresses:
**Issue:** The `_compute_sla_reached` method in on `helpdesk_ticket.py` determines whether an SLA has been reached by checking if `exceeded_hours` is less than 0 on its `helpdesk.sla.status` records. Since every newly assigned SLA has a future deadline, `exceeded_hours` starts as negative (AKA <0), so the ticket is immediately flagged as `sla_reached = True` before any progress has been made. Conversely, a ticket that reaches its target stage after the deadline has `exceeded_hours >= 0`, so it's incorrectly flagged as `sla_reached = False` even though the SLA target was genuinely reached (it was just late).

**Solution:** Change the domain in `_compute_sla_reached` to check `reached_datetime != False` instead of `exceeded_hours < 0`, matching the field already listed in the method's `@api.depends` and the same field `_sla_reach()` sets when a ticket enters its target stage. This makes `sla_reached` reflect actual stage progression rather than a time-remaining calculation.

### Current behavior before PR: 
A newly created ticket with a pending SLA shows `sla_reached = True` and `sla_success = True` immediately upon creation, before the ticket has moved to any target stage. SImilarly, a ticket that reaches its target stage after the SLA deadline is incorrectly marked `sla_reached = False`.

### Desired behavior after PR: 
`sla_reached` is False on ticket creation and only becomes True once the ticket actually enters the SLA's target stage. Lateness continues to be tracked separately and correctly via `sla_reached_late`

opw-6361851

Forward-Port-Of: odoo/enterprise#126432

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

### Steps to Reproduce:
1. Go to Helpdesk and create an SLA
2. Create a new Ticket
3. Use Studio to add the field `sla_reached`
4. Apply the SLA
5. Notice that the field is True

### Description of the issue/feature this PR addresses:
**Issue:** The `_compute_sla_reached` method in on `helpdesk_ticket.py` determines whether an SLA has been reached by checking if `exceeded_hours` is less than 0 on its `helpdesk.sla.status` records. Since every newly assigned SLA has a future deadline, `exceeded_hours` starts as negative (AKA <0), so the ticket is immediately flagged as `sla_reached = True` before any progress has been made. Conversely, a ticket that reaches its target stage after the deadline has `exceeded_hours >= 0`, so it's incorrectly flagged as `sla_reached = False` even though the SLA target was genuinely reached (it was just late).

**Solution:** Change the domain in `_compute_sla_reached` to check `reached_datetime != False` instead of `exceeded_hours < 0`, matching the field already listed in the method's `@api.depends` and the same field `_sla_reach()` sets when a ticket enters its target stage. This makes `sla_reached` reflect actual stage progression rather than a time-remaining calculation.

### Current behavior before PR: 
A newly created ticket with a pending SLA shows `sla_reached = True` and `sla_success = True` immediately upon creation, before the ticket has moved to any target stage. SImilarly, a ticket that reaches its target stage after the SLA deadline is incorrectly marked `sla_reached = False`.

### Desired behavior after PR: 
`sla_reached` is False on ticket creation and only becomes True once the ticket actually enters the SLA's target stage. Lateness continues to be tracked separately and correctly via `sla_reached_late`

opw-6361851

Forward-Port-Of: odoo/enterprise#126432

### Steps to Reproduce:
1. Go to Helpdesk and create an SLA
2. Create a new Ticket
3. Use Studio to add the field `sla_reached`
4. Apply the SLA
5. Notice that the field is True

### Description of the issue/feature this PR addresses:
**Issue:** The `_compute_sla_reached` method in on `helpdesk_ticket.py` determines whether an SLA has been reached by checking if `exceeded_hours` is less than 0 on its `helpdesk.sla.status` records. Since every newly assigned SLA has a future deadline, `exceeded_hours` starts as negative (AKA <0), so the ticket is immediately flagged as `sla_reached = True` before any progress has been made. Conversely, a ticket that reaches its target stage after the deadline has `exceeded_hours >= 0`, so it's incorrectly flagged as `sla_reached = False` even though the SLA target was genuinely reached (it was just late).

**Solution:** Change the domain in `_compute_sla_reached` to check `reached_datetime != False` instead of `exceeded_hours < 0`, matching the field already listed in the method's `@api.depends` and the same field `_sla_reach()` sets when a ticket enters its target stage. This makes `sla_reached` reflect actual stage progression rather than a time-remaining calculation.

### Current behavior before PR: 
A newly created ticket with a pending SLA shows `sla_reached = True` and `sla_success = True` immediately upon creation, before the ticket has moved to any target stage. SImilarly, a ticket that reaches its target stage after the SLA deadline is incorrectly marked `sla_reached = False`.

### Desired behavior after PR: 
`sla_reached` is False on ticket creation and only becomes True once the ticket actually enters the SLA's target stage. Lateness continues to be tracked separately and correctly via `sla_reached_late`

opw-6361851

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#126987