Bug reproduction:

1 - Install hr module
2 - Create some user in the settings, create an employee for it.
3 - Give contract to the employee make it 1 January 2020.
4 - Press to invited button in the top -> Deactivate
5 - Press to discard or X button in the opened pop-up.
6 - The button in the top converts to archived and user is archived.

Bug cause:

1 - In function: action_toggle_user_active, the active field of the user is toggled first
2 - If employee has a contract, we open the departure pop-up.
    - 2.1 - But in pop-up, we can select discard or press to X to cancel it.

Bug solution:

1 - If the user is active and employee has a contract, I open the pop-up.
2 - Otherwise, I'm toggling the active field of the user. By that way, if discard or X is pressed, the active does not toggled.

task-6535464

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with 6 decimals while the SAT expects the amounts to be expressed with the number of decimals supported by the currency of the payment ('MonedaP'), as published in the 'c_Moneda' catalog, for example 2 decimals for MXN.

Steps to reproduce:

- Have an MX Company setup with Quadrum as PAC.
- Create and sign a customer invoice in MXN with a 16% IVA tax.
- Register a full payment and send the payment complement to the PAC.

Issue:

Payment will be rejected
```
Code : CRPER654
Message : El importe del campo BaseP que corresponde a Traslado, no tiene la cantidad de decimales que soporta la moneda (MonedaP)
```

Analysis:

Quadrum recently aligned its validation on that rule and now rejects the document having fields with too much decimals and, currently, fields like BaseP, ImporteP are pinned to 6 decimals in the template.

Reporting them with the decimals of the payment currency is not enough when the payment settles a document expressed in another currency: those amounts are also compared with the ones of the related documents converted with 'EquivalenciaDR', and the PAC expects the values truncated or rounded

```
Code : CRP20274
Extra Info : Traslados: La sumatoria de ImporteDR es mayor al ImporteP 1.30.
             Valores minimos permitidos: Truncado: 1.29 o redondeado: 1.3
```

opw-6561617

Forward-Port-Of: odoo/enterprise#131343
Forward-Port-Of: odoo/enterprise#131267

A props validation error happens when the component is rendered due to the wrong props definition.
```
> UncaughtPromiseError > TypeError
> 
> Uncaught Promise > type is not a function
> 
> Occurred on 125085990-master-all.runbot132.odoo.com on 14/Sep/2026 05:43:28
> 
> TypeError: type is not a function
>     validate@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:647:291
>     validateObject@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:691:34
>     validateLooseObject@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:695:108
>     validateType@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:648:67
>     assertType@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:645:109
>     makeProps@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1192:48
>     __exports.AddRecordToCampaign<@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:39471:954
>     AddRecordToCampaign@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:39471:812
>     ComponentNode@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1035:999
>     createComponent/owl@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1123:6
>     slot1@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js line 1511 > Function:13:12
>     callSlot@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1089:25
>     __template__14@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js line 1511 > Function:30:10
>     render@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1026:199
>     initiateRender@https://125085990-master-all.runbot132.odoo.com/web/assets/31cc50d/web.assets_web.min.js:1041:56
```

*: base,partner_autocomplete

Description of the issue/feature this PR addresses:
Pull Request #283584 added a dependency between l10n_fr_account and partner_autocomplete. Some comments on that PR proposed to not add dependency (cf https://github.com/odoo/odoo/pull/283584#discussion_r3822664753).

Adding this dependency does not allow anymore to deactivate partner_autocomplete on an Odoo instance.
Tested on runbot on both Community and Enterprise Edition, if you install French localization and then you want to untick "Partner autocomplete" option in General Settings, it would try to remove French localization.

In addition, on most Community Edition integration, this module partner_autocomplete is not installed (nor is IAP) and this change would force installation and usage of partner_autocomplete.
<img width="1164" height="596" alt="image" src="https://github.com/user-attachments/assets/d4378241-ffea-4236-8d2f-d75adedae1df" />


Current behavior before PR:
With French localization installed you cannot deactivate Partner autocomplete option.

Desired behavior after PR is merged:
French localization does not depend on partner_autocomplete and the function to retrieve identifiers to enrich is moved to base module (since the other default field retrieved, vat is part of base module).

The method may need to be renamed though, but I did not want to change too much the existing signatures.



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

Current behavior:
--
Sending a B2B invoice that deducts a down payment is rejected by ECPay with
"(item tax discrepancy exceeds 1 NT$)", so the invoice
cannot be issued at all. When it is accepted, the tax on the e-invoice can
still differ from the tax the invoice books.

Expected behavior:
--
The invoice is accepted, and the tax reported on the e-invoice is the one the
invoice booked.

Steps to reproduce:
--
- Set a company up in Taiwan (TWD) with the ECPay credentials filled in
- Create a sale order of 190,630 for a customer with a VAT number
- Invoice a 50% down payment through the down payment wizard, then a 30% one, and post both
- Invoice the remainder and post it
- Send the final invoice to ECPay

Cause of the issue:
--
_l10n_tw_edi_prepare_item_list rebuilt the tax from the raw amount of every
line and rounded that total once. Both steps also disagree with the invoice. 
Negative lines resulting from downpayments seem to be more strictly checked
on ECPay and taxes cannot be re-derived easily by ECPay's system.

There is a also a relevant but slightly different issue where the invoice amount is calculated
differently but the ECPay page will show a different value.

e.g. the invoice rounds each
computation key on its own: 50.00 - 16.50 = 33.50 rounds to 34 where the invoice books
50 - 17 = 33.

No issue was detected for purely positive lines (a transaction with
different products but no downpayment)

Fix:
--
Use the tax amount the line carries when it has one, and fall back to the raw
amount otherwise, so the payload reports what the invoice booked. Send the tax
of each line in the ItemTax field. Let ECPay derive its own per-item tax and checks
it against the declared total for purely positive lines, and recalculate them for negative
so the rounding difference between them is spread one unit at a time across the lines,
the way ECPay distributes it.

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

Forward-Port-Of: odoo/odoo#281928

Since the introduction of `read_grouping_sets` for Pivot views, opening the Pivot view from a saved favorite filter can crash.

### **Steps to reproduce:**
- Install Project.
- Open My Tasks.
- Save the current filter as a favorite.
- Switch to the Pivot view.

### **Error:**
```
ValueError: Cannot convert project.task.personal_stage_id to SQL
because it is not stored.
```

### **Root Cause:**
Since [commit](https://github.com/odoo/odoo/pull/194413/changes/166a546ec52784c413f5b5d7d29af89d618d6519), Pivot views use `_read_grouping_sets` instead of
`_read_group`. `project.task` only remaps `personal_stage_type_id` to the stored `personal_stage_type_ids` in [_read_group](https://github.com/odoo/odoo/blob/5f6fb63d5d7585805642c702d096b2f882e73761/addons/project/models/project_task.py#L2169-L2179), so the remapping is bypassed for Pivot views. The ORM then attempts to group by the non-stored `personal_stage_type_id` relation, leading to the SQL conversion error.

### **Fix:**
Mirror the remapping logic in `_read_grouping_sets` so Pivot views use `personal_stage_type_ids` before the ORM generates the SQL query.

**opw-6306389**

Forward-Port-Of: odoo/odoo#272985

Steps to reproduce
------------------
- Install `website_sale_stock` and `sale_management` module.
- Create a product.
- Create a rule-based delivery method with:
- In Pricing tab click add a line
  - condition: `Quantity >= 0`
  - variable factor: `weight`
  - price per unit: 2
- Create a quotation containing the product.
- Open the delivery method wizard by clicking into `Add Shipping`
- Select the rule-based delivery method.
- Change the total weight from 0 to 10.
- Add the delivery method.

Issue
-----
- Changing the total weight does not recompute the delivery price.
- The delivery line is added with a price of 0 instead of 20.

Cause
-----

The delivery wizard defines `_onchange_carrier_id` for both `carrier_id` and `total_weight`

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/wizard/choose_delivery_carrier.py#L41-L50

The call flow is expected to be:

`total_weight` change
-> `_onchange_carrier_id`
-> `_get_delivery_rate`
-> `rate_shipment`

`_get_delivery_rate` passes the manually entered weight through the `order_weight` context key:

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/wizard/choose_delivery_carrier.py#L87-L90

The rule-based carrier gives this context value priority over the saved order weight and the weight computed from order lines:

https://github.com/odoo/odoo/blob/9860ba5a593c5e7723494674b62890d16ae1a9a8/addons/delivery/models/delivery_carrier.py#L588-L594

For example, with `total_weight = 10` and a price factor of 2, the expected calculation is:
`delivery_price = 0 + 2 * 10 = 20`

However, the pickup-location implementation added an override in `website_sale_stock` that declared only `carrier_id` as an onchange trigger:

https://github.com/odoo/odoo/blob/0da3259034ff3b2b79f417df53969fe017207195/addons/website_sale_stock/wizard/choose_delivery_carrier.py#L13-L16

Since the override uses the same method name, its decorator replaces the base onchange specification. Therefore, changing `total_weight` does not call the method and the initial `delivery_price = 0` is kept.

This does not occur in saas-19.2. because `website_sale_stock` does not override the delivery wizard there. The base method remains registered for both `carrier_id` and `total_weight`:

The conflicting override was introduced later in this [commit](https://github.com/odoo/odoo/commit/0da3259034ff3b2b79f417df53969fe017207195) from saas-19.3

Fix
---

Add `total_weight` to the `website_sale_stock` onchange decorator 
so the inherited delivery-rate computation runs when the user edits the weight.

---

opw-6516301

---

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

Forward-Port-Of: odoo/odoo#285864

Currently on creating  new helpdesk team everytime a new website menu is created.

### **Steps to Reproduce:**
1) Install website_helpdesk
2) Navigate to `Helpdesk>Configuration>Helpdesk Team`. 
3) Create 2 helpdesk team with `Website Form` option enable. 
4) Navigate to Website.

### **Observed Behavior:**
Two Help menus are created.

### **Expected Behavior:**
Multiple menus should not be created.

### **Root Cause:**
The menu creation logic relies on the following [condition](https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/website_helpdesk/models/helpdesk.py#L111-L112)
`team_count_by_website` is built from `_read_group(..., ['website_id'], ...)`,
which keys its result by the `website_id` *recordset*, not its id. Looking it
up with `team_count_by_website.get(website.id, 0)` therefore always misses and
falls back to `0`, so `team_count <= 1` is always `True` regardless of how
many teams already exist for that website. The only thing left guarding menu
creation is `any(team.website_menu_id for team in teams)`, which only looks at
the teams in the current create/write call, not every team on that website.
So saving a second team in a separate call always creates another menu.

### Fix:
Make the website menu a resource shared by every team with the website form
enabled on a given website, instead of "owned" by whichever team created it:
- Before creating a new menu, look up other teams (active or archived) that
  already point to a menu, matched through the `website_menu_id` relation
  between teams rather than a hardcoded `/helpdesk` URL, so a customized menu
  URL doesn't cause a duplicate to be created. Reuse that menu when found.
- Only delete a menu once no team (active or archived) still references it,
  checked before removing a team's own reference.

**opw-6303846**

Forward-Port-Of: odoo/enterprise#130401
Forward-Port-Of: odoo/enterprise#121120