When a tax affects the base of the subsequent ones — `include_base_amount`,
which is how the ISC is set up in Peru — Odoo links the tax line it generates
to those subsequent taxes, so the ISC tax line ends up carrying the IGV in its
`tax_ids`.

The PLE ledgers build their base columns by summing every move line related to
a given tax group, so that ISC tax line was added to `base_igv` as well and the
ISC ended up reported twice: once inside the taxable base and once in its own
column. A line of 1000.00 with 100.00 of ISC and 198.00 of IGV was declared
with a base of 1100.00 instead of 1000.00.

`l10n_pe_edi` already subtracts the ISC from the `cbc:TaxableAmount` of the CPE
sent to SUNAT, so the electronic invoice and the ledger disagreed on the very
same document.

### What changed

The base taxes are now joined only for base lines, instead of repeating the
condition on each of the twelve `base_*` columns. Besides keeping tax lines out
of the base columns, this also stops a tax line from being counted once per
subsequent tax: an ISC followed by both the IGV and the ICBPER produced two rows
in the join, and its own column was reported twice.

### Scope

`_get_ple_report_data` is shared, so this covers the sales ledger 14.1 and the
purchase ledgers 8.1 and 8.2. A configuration where no tax affects the base of
a later one is unaffected: the standard Peruvian chart template has no purchase
ISC, so ordinary IGV-only purchases report exactly the same values as before.

### Tests

- `test_sale_report_isc_base`: an ISC preceding the IGV, on an invoice and on a
  credit note; the base column excludes the ISC.
- `test_sale_report_isc_reported_once`: an ISC followed by the IGV and the
  ICBPER is reported once.

Both fail without the fix.

Supersedes odoo/enterprise#128300, which targeted 19.0.

Forward-Port-Of: odoo/enterprise#132106
Forward-Port-Of: odoo/enterprise#131475

## Description

Law no. 30-26 of June 18, 2026 updates Dominican ISR withholdings effective **July 1, 2026**:

- **Professional services, fees, commissions, and rentals paid to individuals:** 10% to 15%.
- **Specific foreign-payment categories:** 15% for royalties or rights, software licenses, online advertising, and the use or storage of data.
- **General remittances abroad:** remain at 27% when they are outside those specific categories.

The DGII's current **IR-17-2026 (July 2026 onward)** also confirms that the concepts discussed in review are three distinct reporting rows:

- **Row 4 — Transfers of titles and properties:** 2%.
- **Row 17 — Other income under Decree 139-98, Article 70(a)/(b):** 3%.
- **Row 18 — Other withholdings under General Rule 07-2007, as amended by Law 30-26:** 3%.

The two 3% rows must not be conflated with each other or with the separate 2% transfer withholding.

## Implementation

The changed-rate template entries use new, rate-explicit XML IDs, as recommended in review:

- `ret_15_income_person`: new -15% fee withholding, replacing `ret_10_income_person` in the template; posts to `21030301`.
- `ret_15_income_rent`: new -15% rental withholding, replacing `ret_10_income_rent` in the template; posts to `21030302`.
- `ret_3_income_person`: new -3% General Rule 07-2007 withholding, replacing `ret_2_income_person` in the template; posts to `21030308`.
- `tax_group_person_services_15`: new grouped tax using `ret_15_income_person`.
- `tax_group_person_construction_3`: new grouped tax using `ret_3_income_person`.
- `position_person_services_15`: new physical-services fiscal position mapped only to the current 15% grouped tax.

The remaining legal concepts stay separate:

- `ret_3_income_article_70`: new -3% tax for Decree 139-98, Article 70(a)/(b), posted to `21030309`.
- `ret_2_income_transfer`: remains at -2% on `21030306`; its misleading “Materials” source metadata is corrected to transfers of titles and properties.
- `ret_27_income_remittance`: remains active at -27% on `21030307`, with the general foreign-services fiscal position unchanged.
- `ret_15_income_foreign_royalties_technology`: new -15% tax only for the foreign categories covered by Law 30-26. It posts to the new `21030310` Law 30-26 payable account rather than the L253-12 remittance account.
- `position_exterior_royalties_technology`: new fiscal position mapping purchases only to that specific 15% tax.

The specific foreign tax keeps the short invoice label `-15% ISR (L30-26)` to avoid wrapping in vendor-bill PDFs.

The original manifest author entry is unchanged, as requested. The Git history and corporate CLA record this contribution by Grupo de Consultoria Henca.

### Existing-company reload behavior

The superseded 10%/2% tax, grouped-tax, and physical-services fiscal-position rows are removed from the template rather than shipped as obsolete entries to new companies.

On an existing company, Odoo's chart reload keeps those historical records and generated XML IDs unchanged, then creates the new current-rate records under the new XML IDs. On a newly loaded chart, only the current template entries are created.

The physical-services fiscal position also has a new XML ID intentionally. Reload preserves existing fiscal-position mappings as user-configurable data and only appends mappings involving new taxes; reusing `position_person` could therefore leave both the historical and current destinations on one position. `position_person_services_15` keeps the current mapping isolated while the old position remains available for historical operations.

`ret_2_income_transfer` keeps its existing XML ID because its legal rate, concept, and account remain 2% / transfers / `21030306`. The corrected label is present for new charts; backfilling label-only metadata on already-loaded charts would require an explicit upgrade migration because standard chart reload does not rewrite that user-visible metadata.

## Official references

- DGII, current IR-17-2026 download page (July 2026 onward): https://dgii.gov.do/herramientas/formularios/formularioDeclaraciones/Paginas/impuestosRetencionesyRetribuciones.aspx
- Law 30-26: https://www.consultoria.gov.do/Consulta/Home/FileManagement?documentId=3405887&managementType=1
- DGII implementation calendar, notice 10-26: https://dgii.gov.do/publicacionesOficiales/avisosInformativos/Documents/2026/10-26.pdf
- DGII CA59, calculation for professional and technical services: https://ayuda.dgii.gov.do/conversations/retenciones-y-retribuciones-complementarias/ca59-qu-porcentaje-del-isr-deben-retener-las-personas-jurdicas-a-las-personas-fsicas-en-la-prestacin-de-servicios/5f3c175f8cd858ce879a130f
- DGII clarification for General Rule 07-2007 and the construction sector: https://ayuda.dgii.gov.do/conversations/discusiones/aplicacin-de-la-ley-nm-3026-respecto-a-la-retencin-prevista-en-el-artculo-3-de-la-norma-general-072007-sector-construccin/6a45792cde3c6003da189ff1
- DGII legal basis for the 2% transfer withholding: https://ayuda.dgii.gov.do/conversations/discusiones/base-legal-retencion-2-transferencia-de-titulos-y-propiedades/5f6355928cd858ce872bb35a
- Ministry clarification on the specific foreign technology and royalty categories: https://www.hacienda.gob.do/ley-30-26-no-dispone-impuestos-por-suscripciones-de-ciudadanos-a-plataformas-digitales-reduce-de-27-a-15-la-retencion-a-empresas-que-contratan-servicios-tecnologicos-en-el-exterior/

Legal basis cited by DGII: Law 11-92, article 309, as amended by Law 30-26, article 17; Regulation of Title II of the Tax Code, article 70.

## Validation

- The branch is rebased on the current 17.0 head and contains one squashed commit.
- The account, tax-template, and fiscal-position CSV files have consistent column counts, unique IDs, and valid child/account references.
- A fresh Dominican chart contains only the new current-rate IDs; the superseded template IDs are absent.
- The fresh chart was verified with fees/rentals at 15%; General Rule 07-2007 at 3% on `21030308`; Article 70(a)/(b) at 3% on `21030309`; transfers at 2% on `21030306`; general remittances at 27% on `21030307`; and the covered foreign categories at 15% on `21030310`.
- The 15% services and 3% construction groups contain exactly the current tax children, and the new services fiscal position maps each purchase tax to only the 15% group.
- An existing company loaded from the pre-law template was reloaded twice. Its historical 10%/10%/2% taxes, historical groups, and historical fiscal position retained their original record IDs and configuration; all current records were created once; the old and new positions each retained exactly two isolated mappings; and the second reload was idempotent.
- `/account:TestChartTemplate`: 22 tests passed, 0 failures, 0 errors.

This is the first contribution by Grupo de Consultoria Henca (https://www.consultoriahenca.com); the corporate CLA signature is included in `doc/cla/corporate/consultoriahenca.md` as instructed by `doc/cla/sign-cla.md`.

Forward-Port-Of: odoo/odoo#287568
Forward-Port-Of: odoo/odoo#275986

Issue Before this Commit:
========================
The maintenance request state is displayed as a rounded pill in the kanban view
instead of a circular indicator.

<img width="500" height="150" alt="image" src="https://github.com/user-attachments/assets/84fe84ef-ff58-4873-bb73-1f375774f149" />

Steps to reproduce
========================
1. Open the Maintenance app.
2. Open Maintenance Requests.
3. Observe the maintenance request state.
The state is displayed as a rounded pill instead of a circular indicator.

Cause of the issue:
========================
In the [PR](https://github.com/odoo/odoo/pull/260098), the view type of maintenance requests was changed from `kanban`
to `cards`, but the `MaintenanceRequestStateSelection` component still checks
for `kanban` in its `isKanbanOrMobileView` method. As a result, it uses the
`rounded-pill` styling instead of the circular styling.

After this Commit:
========================
Update the condition to correctly check `card` as the view type, so the
maintenance request state is displayed as a circular indicator.

<img width="500" height="150" alt="image" src="https://github.com/user-attachments/assets/e01b5898-2ec3-45b3-aa79-f7ed7c8e9e9f" />

Issue Before This Commit:
=========================
Currently, the Purchase Order Line field on the vendor bill line allows users to 
select purchase order lines regardless of the purchase order state. As a result,
lines from purchase orders that are not confirmed can also be selected and 
linked to vendor bill lines.

Steps to Reproduce:
===================
- Install Purchase and create an RFQ.
- Create a vendor bill for the same vendor.
- Add a bill line and enable the Purchase Order column.
- Open the dropdown of the Purchase Order Line field.
- Observe that lines from unconfirmed purchase orders are available
  for selection.

Cause of the Issue:
====================
This [PR](https://github.com/odoo/odoo/pull/266003) made Purchase Order lines selectable directly on bill lines, 
but the selection domain did not restrict the lines to confirmed purchase orders. 
Therefore, lines from unconfirmed purchase orders remained available for selection.

After This Commit:
==================
Only Purchase Order lines from confirmed purchase orders are selectable
on vendor bill lines.

**Steps to reproduce:**
- Receive a mail with an embedded code block
- Open a chatter containing this message
- Error: "Cannot mount a component on a detached dom node"

**Issue:**
Mail message are rendered with a shadow dom body and isolated from surrounding styling.
```xml
<div class="o-mail-Message-shadowBody overflow-x-auto" t-if="this.message.message_type and this.message.message_type.includes('email')" t-custom-ref="shadowBody"/>
```
Then in `useLayoutEffect` parent element is created for the shadow root and the message body is created:
```js
const bodyEl = createElementWithContent(
    "span",
    this.message.showTranslation
        ? this.message.richTranslationValue
        : this.props.messageSearch?.highlight(this.message.richBody) ??
                this.message.richBody
);
const roots = this.prepareMessageBody(bodyEl) ?? [];
this.shadowRoot.appendChild(bodyEl);
```
But after [1] we have `return this.renderEmbeddedCodeBlocks(bodyEl);` which calls:
```js
const { root, mountPromise } = mountComponent(...);
```
And root creation fails as the element is not on the shadow root yet (due to `validateTarget` and `isAttachedToDocument`).
```js
const root = app.createRoot(Component, { props, env });
```

But even if we have the element directly added on the `shadowRoot` the highlighting styling won't be applied properly without all the needed assets.

**Fix:**
Prevent `ReadonlySyntaxHighlightingComponent` for incoming email body.

Doesn't seem worth to try to load the needed css/style elements in the shadow root.

[1] https://github.com/odoo/odoo/commit/8fa3cc31e8b81645d40b5d09c925b57d2c0558ab

opw-6463735

Forward-Port-Of: odoo/odoo#287977

Step to reproduce:
------------------
- Install `pos_sale_stock` and `mrp` module.
- Go to the setting enable "Replenish on Order (MTO)"
- Create a storable product with the MTO route
- Create a Bill of Materials for the product with a storable component
- Now Create Sale order for the Product and confirm it.
- Open POS Store and settel Created sale order.
- Process toward payment and try to validate it.

Issue:
------

`AssertionError: Invalid falsy real id`

Cause:
------
When an MTO product with a manufacturing Bill of Materials is added to a Sale Order and the SO is confirmed, Odoo creates two distinct sets of stock.move records that share the same stock.reference group:

1. **Delivery moves** (picking_id → stock.picking) Created by the outgoing stock rule triggered by the MTO route. These moves are assigned to a delivery picking and have a valid picking_id.

2. **Manufacturing component moves** (picking_id = False) Created by the Manufacture route's procurement rule, which spawns an mrp.production. The raw-material moves inside an MO belong to the production order, not to any stock.picking. Their picking_id field is intentionally False by design.

Both sets of moves are linked to the same stock.reference record through the stock_reference_move_rel many2many table. This means that traversing:

    so_line.move_ids          → delivery move(s)
    .reference_ids            → shared stock.reference
    .move_ids                 → ALL moves in the group (delivery + MRP)

every move in the reference group, including MRP component moves whose picking_id is False.

- Then In PosOrder.sync_from_ui(), the code collected the IDs of all related pickings into a set for later cancellation:

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L111

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L130-L133

        waiting_picking_ids.add(move.picking_id.id)   # ← adds False for MRP moves

Because MRP moves pass the state filter ('confirmed') but have picking_id = False, `move.picking_id.id` evaluates to False (the empty recordset's falsy id), which was silently added to the waiting_picking_ids set.

Issue occur from this [commit](https://github.com/odoo/odoo/commit/515eb5ba0892a759dde32a9b2923d8ecc1e4bf74?debug=1), the ORM assertion in browse() rejects falsy IDs:

https://github.com/odoo/odoo/blob/a0cdf9c33ed464b4ec8bd520e4d0523afb8dbd28/addons/pos_sale/models/pos_order.py#L139

https://github.com/odoo/odoo/blob/9e02922f821a3b4e891e90bf9bd18448a08e66fa/odoo/orm/models.py#L5297

Fix:
---
Add guards in `sync_from_ui()`
*Inner filtered() guard* — add `m.picking_id` as the first condition so
   that MRP component moves (picking_id = False) are never iterated, preventing
   `False` from ever entering the set

---

opw-6486681

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

Forward-Port-Of: odoo/odoo#289680
Forward-Port-Of: odoo/odoo#284103

### Steps to reproduce

Set a credit limit of 1.000 on a customer, then:

1. Create a Sale Order for a product with Invoice Policy on **Delivered Quantities**, over that amount → the warning shows. Good.
2. Confirm it, and deliver nothing.
3. Create a second order for the same customer → the warning never shows, even though the customer is already over the limit.

### Solution

The ordered quantity is what the customer committed to, delivered or not. Using `qty_to_invoice` instead of `uom_qty_to_consider` or `qty_delivered`

Introducing invoice_status in sales domain for `_compute_credit_to_invoice`: `untaxed_amount_to_invoice` still follows the invoicing policy, while `amount_to_invoice` no longer does. On a confirmed order for a delivery-based product with nothing delivered:

```
    line.untaxed_amount_to_invoice = 0       # still gated by qty_delivered
    line.invoice_status            = 'no'
    order.amount_to_invoice        = 2000    # fixed by this PR
```

The domain filters on the first one, so the order is dropped from the search before its amount is ever read and `credit_to_invoice` stays at 0.`'no'` is the stored marker for a confirmed line that is not invoiceable yet, which is exactly what the first clause misses.

ticket: [6480211](https://www.odoo.com/odoo/project/967/tasks/6480211)

Forward-Port-Of: odoo/odoo#289305
Forward-Port-Of: odoo/odoo#285578

Currently, when the user tries to produce a Manufacturing Order after generating a lot and increasing the quantity, they get a user error stating that a lot must be assigned.

## Steps to produce:
- Install Manufacturing
- Go to the setting enable Lots & Serial Numbers and Storage Locations
- Create a product 'Soda can' which is tracked by lots
- Create a bill of material for Soda can with component as 'Metal sheet'
- Create a storage location called 'Fridge' with parent location WH/Stock
- Create a Putaway rule for the Soda can to be stored in the fridge when it arrives in WH/Stock.
- Create and confirm a Manufacturing Order for soda can
- Click 'Generate Lot'
- Increase the total quantity to be produced from 1 -> 2
- Click 'Produce All'

## Observed Behaviour:
```
Invalid Operation:
You need to supply a Lot/Serial Number for product:
- Soda can
```
## Root cause:
When the user confirms the Manufacturing Order, `_apply_putaway_strategy` is called through:
``action_confirm -> _action_assign -> _apply_putaway_strategy``

This happens for both finished-product move lines and component-product move lines.

It updates the finished product move lines' destination location to `WH/Stock/Fridge` at:
https://github.com/odoo/odoo/blob/fd06c4df5889e23cfb701c12d743b5652141a111/addons/stock/models/stock_move_line.py#L288-L292

However, the `move_finished_ids` destination location remains` WH/Stock`.

After the user generates a lot and increases the production quantity using the wizard, `change_prod_qty()` updates the finished move's demand and re-reserves it through `_update_finished_moves()`:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L77

This calls `_action_assign` on the finished move:
https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/wizard/change_production_qty.py#L49

Within `_action_assign` because finished moves originate from the production location, they bypass the normal reservation logic at: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2086

So `_action_assign() `then tries to reuse an existing move line. However, it only searches for move lines whose `location_dest_id` matches the move's destination location
(WH/Stock):
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2108-L2117

The existing move line has `WH/Stock/Fridge` as its destination, so it does not match. As a result, a new move line is created for the finished move: https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/stock/models/stock_move.py#L2182

The new move line gets the lot value from the Manufacturing Order: https://github.com/odoo/odoo/blob/f586c1dad0b9a7653c45d1f82a9c3989a287c641/addons/mrp/models/stock_move.py#L557

Later, when Produce All is triggered,` button_mark_done()` calls` _post_inventory()`:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L2236

Because the finished move already has a `lot_id`, the condition below is not satisfied:
https://github.com/odoo/odoo/blob/708e5ebcd8b3338d3ce2c092aafadfe0f941aa56/addons/mrp/models/mrp_production.py#L1929-L1933

Therefore, the `lot_id` is not assigned to the move line that was created earlier.

When `button_mark_done()` validates the finished move lines, it finds that one move line has no lot assigned and raises an 'Invalid Operation' error.

## Solution:
Allow the user to produce the Manufacturing Order after changing the quantity. Increasing the quantity is a valid operation, so the user should not be blocked from completing the production afterward.

opw-6563498

Forward-Port-Of: odoo/odoo#289725
Forward-Port-Of: odoo/odoo#289171

Steps to reproduce:
- Apply a theme on a website, for example Bistro
- Enter website edit mode and open the Theme tab
- Click Switch Theme
- Hover the card of Bistro (the theme currently in use)
- "Use this theme" button appears like every other card
- It should show "Update theme" and "Remove theme" instead

Since [1], `self.env.website` only reads `website_id` from the context, and that key is stripped on a non-website route, where the resolved website is moved to `host_id` instead. The theme kanban is read through a plain ORM call, so `_compute_is_installed_on_current_website` resolved no website and no card was ever flagged as the one in use.

This commit falls back on `host_id` to resolve the current website. `button_refresh_theme` and `button_remove_theme` get the same fallback: they resolved the website the same way and acted on an empty one, which went unnoticed only because the buttons triggering them were never displayed.

task-6575727

[1]: https://github.com/odoo/odoo/commit/9d97e0e919a953e4f86e42e32ca24d9790840f68

Steps to reproduce:
------------------------------------
1. Install Time off module
2. Create New Fully Flexible Employee
3. Click on the Time off smart button
4. Create time off for multiple days (eg. Mon - Friday)

Observation:
------------------------------------
Number of days still shows 1 Days.

Issue:
------------------------------------
Issue occurs because `work_time_per_day_mapped` returns one interval per day for
standard and flexible schedules in multi-day time off requests, so the interval
count correctly matches the number of leave days.
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/hr_holidays/models/hr_leave.py#L460-L461

However, for fully flexible schedules, it returns a single interval
containing the total hours across all days, causing the leave duration to
always be computed as 1 day regardless of the actual number of days requested.

Solution:
------------------------------------
For fully flexible employees, count the actual calendar days and subtract public
holidays when applicable.

opw-6060552

Forward-Port-Of: odoo/odoo#255826

**Steps to Reproduce**

- Install the `Documents` and `Project` modules.
- Create two companies.
- Create a project using the `Kanban quick create` option, without setting a company.
- A related workspace is automatically created without a company.
- Set a company on the project from the form view.
- The company of the related workspace remains unset.

**Observation**
- Projects created through the Kanban quick-create flow do not have a company assigned at creation time, so their related workspace is also created without a company.
- When the project's company is subsequently changed from the form view, the workspace company  was not updated. As a result, the workspace and its documents remained without a company.

**Solution**
When a project's company is changed, all projects linked to the same workspace are checked:
* If all projects belong to the same company, the workspace company is updated accordingly.
* If the linked projects belong to different companies and the workspace has no company, the workspace remain unchanged and accessible to all companies.
* If the linked projects belong to different companies and the workspace already has a company, an error is raised, preserving the existing behavior.

Backport of https://github.com/odoo/enterprise/pull/111760

OPW-6487090

Forward-Port-Of: odoo/enterprise#129315

Steps to reproduce:
1. Go to Settings > Technical > Email Templates.
2. Open any email template.
3. In the Body editor, either paste a YouTube URL and select Embed YouTube Video from the popup, or type `/media` and open the 'Videos' tab in the Media dialog.
4. Select a video or embed a YouTube video.
5. Save the email template.

Issue:
- The YT URL is converted into an `<iframe>` video element in the email template. However, the `<iframe>` element is removed when the template is saved because it is not supported by the email HTML sanitization.

- This leaves the surrounding content empty and can result in broken HTML in the email template. The `body_html` field was configured with `allowCommandVideo: false` to prevent video embedding, but this option is not recognized by the HTML field and is therefore ignored.

Solution
- Use the supported `allowVideo: false` option on the `body_html` field
of email templates to disable video embedding in the editor as [this PR](https://github.com/odoo/odoo/pull/219288) has changed the html_field components's attribute.

Expected behavior
- Video embedding should be disabled in email templates, preventing users from inserting YouTube videos and avoiding `<iframe>` elements that are later removed by HTML sanitization.

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

Forward-Port-Of: odoo/odoo#286133

A user configured with "Officer: Manage all attendances" but no access to the Employees app can see the "Employees" entry under Attendances > Overview, since that menu only requires Attendance rights. Opening it, however, raises an access error naming the "Current Time Off Type" field.

Steps to reproduce:
-------------------
* Go to Settings > Users, open a user and set their access rights to: Employees app: no access, Attendances app: "Officer: Manage all attendances"
* Log in as that user
* Go to Attendances > Overview > Employees

> Observation:
Error:
"You do not have enough rights to access the field "current_leave_id" on Employee (hr.employee). Please contact your system administrator."

Why the fix:
------------
The "Employees" menu pointed to `hr.open_view_employee_list_my`, the full HR Employees action (model `hr.employee`, no view_id override), which resolves to the same default kanban view used by the Employees app. That view is extended by hr_holidays to embed `current_leave_id` (and other Time Off fields), declared with `groups="hr.group_hr_user"` on the model. That group restriction is enforced by the ORM on read, independently of whether the field is actually shown in the view, so any attendance-only officer opening the menu had that read rejected outright.

The menu now points to `hr_employee_attendance_action_kanban`, an attendance-scoped action already shipped in the module for this exact purpose: it uses the `hr.employee.public` model with a minimal kanban view (name, avatar, job, work location, check-in state), none of which require HR app access, restoring the ability to browse employees from the Attendance app without needing `hr.group_hr_user`.

opw-6488582

Forward-Port-Of: odoo/odoo#287140

Description of the issue/feature this PR addresses:
The Factur-X Refactoring (https://github.com/odoo/odoo/pull/284123) introduced an error that can result in the generated XMLs not being compliant due to the partner name being missing (BT-44)

Current behavior before PR:
When a contact has an invoicing address without a name set, then the new Factur-X generation does not fall back to the parent name, leaving the corresponding XML entry empty, which is therefore pruned, leaving the Factur-X without a BT-44 and thus failing BR-07

Desired behavior after PR is merged:
The new generation method uses the same data source and fallback method as the old Factur-X generator, pulling the `display_name` of the `commercial_partner_id` if the address doesn't have a `name`. This greatly reduces the chance of a generated Factur-X failing BR-07.



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

Forward-Port-Of: odoo/odoo#289661
Forward-Port-Of: odoo/odoo#289498

**Steps to reproduce:**
- Install Appointment app
- Create an appointment type based on resources, auto-assigned, with two shareable resources linked together
- Set the first resource's capacity to 3 and the second resource's capacity to 4
- From the backend Gantt view, create a booking for 2 people on the first resource
- Create a second booking for 2 people on the same resource, at the same date and time
- First resource is now overbooked with reserved capacity of 4 out of 3
- Try to create an appointment from the website
- Error: "The capacity reserved should be positive."

**Issue:**
When bookings are created from the backend gantt view, the selected resource can be overbooked even if another linked resource still has available capacity.

Then when trying to book an appointment the new booking lines will trigger this constraint:
```py
_check_capacity_reserved = models.Constraint(
    'CHECK(capacity_reserved >= 0)',
    "The capacity reserved should be positive.",
)
```
This is caused by the negative values in:
```py
booking_line_values = []
if appointment_type.schedule_based_on == 'resources':
    capacity_to_assign = asked_capacity
    for resource in resources:
        resource_remaining_capacity = resources_remaining_capacity.get(resource)
        new_capacity_reserved = min(resource_remaining_capacity, capacity_to_assign, resource.capacity)
        capacity_to_assign -= new_capacity_reserved
        booking_line_values.append({
            'appointment_resource_id': resource.id,
            'capacity_reserved': new_capacity_reserved,
            'capacity_used': new_capacity_reserved if resource.shareable and appointment_type.resource_manage_capacity else resource.capacity,
        })
```

**Fix:**
Avoid negative remaining value in resource booking when computing available slots.

Note: Tried to take the capacity already used by overlapping bookings into account when assigning resource booking lines from the backend gantt view. And also force linked_resources booking when trying to book more
than the total capacity to properly dispatch as many slots as possible. But it was breaking `appointment_google_reserve` tests.

opw-6503147

Forward-Port-Of: odoo/enterprise#132265
Forward-Port-Of: odoo/enterprise#130520

There was a difference between the actual and expected NET.

**Causes**
- rules existed for both SOCSO Act 800 and EIS, but Act 800 seems to be the official name of the Employment Insurance System (source: https://www.perkeso.gov.my/images/dokumen/Rate_of_Contribution_ACT_800.pdf). Keep the ACT 800 one as its matches the expected amount.
- there was a double counting of the SOCSO employee contributions (4 and 800) , as `l10n_my_rule_socso_employee` (the sum of both) was added to the total deductions.

**Change**
Before: 3500/month wage results in a 3108 NET.
<img width="1181" height="533" alt="before" src="https://github.com/user-attachments/assets/cdf4420f-e2cf-4dc7-9488-6bde3f1f9961" />
After: 3500/month wage results in a 3090.85 NET:
	- 6.90 SOCSO Act 800 Employee
	- 6.90 SOCSO Act 800 Employer
	- 17.25 SOCSO Act 4 Employee
	- 60.35 SOCSO Act 4 Employer Which seems consistent with online sources (https://payroll.my/)
<img width="1181" height="425" alt="after" src="https://github.com/user-attachments/assets/7fb41186-dbb4-4d7a-ac9a-14fb56efc4bc" />

Other fix: while not affecting the calculation, 'SOCSO Employer Share' appeared as incorrect, the two rules SOCSO_800_EMPLR and SOCSO_4_EMPLR should have the same sign.

opw-5976362

Forward-Port-Of: odoo/enterprise#131153
Forward-Port-Of: odoo/enterprise#118138

# How to reproduce
- Go to Settings > Default Terms & Conditions > Preview
- Open the editor
- Add a Content Block
- Add an Accordion in that Block
- Save

# The issue
The accordion gets messed up and trying to add a new item to that accordion raises a traceback

# Cause
`invoice_terms_html` is an html field with some sanitization enabled : https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/account/models/company.py#L172

This sanitization will remove the accordion snippet's buttons that controls the functionality of the snippet :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website/views/snippets/s_accordion.xml#L9

This issue was already addressed by :
https://github.com/odoo/odoo/commit/b6b4db5fb5690436a4284f6a22abf9f3b346a324

But it is not enough in the case of the accordion. The buttons will be removed by the lxml clean.Cleaner :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/odoo/tools/mail.py#L364

# Proposed Solution
Disable sanitization entirely, like for blog's content, which can also be edited in the website editor :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website_blog/models/website_blog.py#L29

opw-6500378

Forward-Port-Of: odoo/odoo#285255

Issue: 
-
Public holidays from other companies were incorrectly included in the Timesheet Grid view of the current company. As a result, days corresponding to those holidays appeared greyed out.

Cause:
-
The `grid_unavailability` method relies on the `_get_valid_work_intervals` function to fetch all unavailability data at once. When fetching data for multiple employees, this function also retrieves public holidays from all companies.

Fix:
-
The method no longer uses the data returned by `_get_valid_work_intervals` for company unavailable days. Instead, it now always makes a separate, direct call via the `get_company_unavailable_dates()` function. This ensures that only holidays relevant to the current company are considered in the grid view.
The company is also passed in the domain of `_work_intervals_batch`, which otherwise returns the leaves of every company when no resource is given.

Steps to reproduce:
-
1. Create Company A and Company B.
2. In Company B, create a public holiday on Tuesday.
3. Switch back to Company A.
4. Open the All Timesheets Grid view from Company A.

Expected behavior:
-
- The grid column for Tuesday should not be grey for Company A users.

Current behavior:
-
- The grid column for Tuesday is grey, incorrectly showing it as a time-off day.

task:4492966

Forward-Port-Of: odoo/enterprise#132332
Forward-Port-Of: odoo/enterprise#88495

Currently, an error occurs when a user clicks on a cell in the aged partner balance report.

**Steps to Reproduce:**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Reporting` > `Partner Reports` > `Aged Receivable`.
 - Click on the `date filter`, select `Open On`, and set `any date`.
 - Click on any `amount` in the `Total Aged Receivable line`.

`TypeError: the JSON object must be str, bytes or bytearray, not dict`

After the [recent commit] that adds the context to the action, when preparing the action to open 
the journal items corresponding to the selected cell in the aged partner balance report, the 
context is added to the action [1]. When an "Open On" date is set, the code attempts to 
convert the context using json.loads() before adding the search_default_open_on key to 
it [2]. but, the context is already a dictionary, which raises the error [3].

This commit ensures that, since the action context is already a dictionary, the search_default_open_on 
key and its value are added directly to the context.

[recent commit]: https://github.com/odoo/enterprise/commit/9678a1b987a5aa87922b72d972dd7f73a689afee

[1]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L357-L359

[2]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L362

[3]- https://github.com/odoo/enterprise/blob/8fceecea541564a9877babfc31b7e0bf896573a6/account_reports/models/account_aged_partner_balance.py#L361

sentry-7685491449

Forward-Port-Of: odoo/enterprise#129142

Steps to reproduce:
--------------------------------------
1. Install the mail module
2. Allow push notification permissions from the site settings
3. Open Discuss > Go to Channels
4. Click Join on a channel where the current user is not a member

Observation:
--------------------------------------
The current user receives a push notification saying: 'User has invited you to this channel.'

This is incorrect; the user joined voluntarily. Nobody invited them

Issue:
--------------------------------------
The commit https://github.com/odoo/odoo/pull/255052/changes/cddd9491c28e9c949efb24d2330c58e35144af12 Adds a push notification when a user is invited to a channel

`_add_members` creates the new member and sends a push notification to all newly added members' partner IDs without checking whether a member joined by themselves or was invited by someone else.

https://github.com/odoo/odoo/blob/e9cfa0fd65d234bcff8130a2c790cd80ee443595/addons/mail/models/discuss/discuss_channel.py#L830-L853

Interestingly, the bus notification code just a few lines above already makes this distinction using `member.is_self` but the web push block doesn't apply the same filter.

https://github.com/odoo/odoo/blob/e9cfa0fd65d234bcff8130a2c790cd80ee443595/addons/mail/models/discuss/discuss_channel.py#L810-L811

Solution:
--------------------------------------
Filter out self-joined members from the web push notification recipients. The push notification should only target members who were invited.

OPW-6527691