Version:
--------
- saas-19.1+

Step to reproduce:
----------------------
* Install *sale_management* and *stock* modules.
* Create a Sale Order with at least two order lines.
  * Set different *Customer Lead Time* (it is optional hide by default)
 on each line:
    * Line A: 5 days
    * Line B: 10 days
* Confirm the Sale Order.
* Open the generated Delivery Order.
* Enable the *Deadline* field on stock moves (it is optional hide by default).
* Check the *Deadline* value for each move

issue:
-----
 * Both stock moves have the same *Deadline*, corresponding to the minimum
  lead time (earliest date), instead of their respective values.
 
Root cause:
-----------
1. User confirms a Sale Order with two lines:
     - Line A: customer_lead = 5  → _expected_date() = order_date + 5
     - Line B: customer_lead = 10 → _expected_date() = order_date + 10

2. sale.order.action_confirm()
   └─ Before calling `_action_confirm()`, the method set:
        `order.commitment_date = order.expected_date`
      where `expected_date = min(all line._expected_date()) = order_date + 5`

3. sale.order._action_confirm()
   └─ calls order_line._action_launch_stock_rule()
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order.py#L209

4. sale.order.line._action_launch_stock_rule()
   └─ per line: calls line._prepare_procurement_values()

5. sale.order.line._prepare_procurement_values()
   └─ date_deadline = self.order_id.commitment_date or self._expected_date()
      Because commitment_date was force-set in step 2, BOTH lines resolve to
      order_date + 5 instead of their individual values.

https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/sale_stock/models/sale_order_line.py#L281

NOTE:
------

This issue originates from changes introduced in task: https://www.odoo.com/odoo/project/966/tasks/4687135
That task aimed to add the Promise Date to Purchase Order Lines and, during 
confirmation, assign it as the expected arrival date.

* This behavior works correctly in Purchase Orders because the Promise Date is
 applied at the purchase order line level and aligned with each 
line’s expected arrival date.  It does not participate in the computation of 
date_deadline.

- In the purchase flow:
The incoming stock move date_deadline is directly derived from each line’s 
expected arrival date.
https://github.com/odoo/odoo/blob/00edcf55380431c454857b2749f2fe4930b1e758/addons/purchase_stock/models/purchase_order_line.py#L308
There is no dependency on a promise date.
As a result, deadlines remain per-line and accurate.

However, in the Sale Order flow, the same approach introduces an issue.

Here:
The Promise Date (commitment_date) exists at the order level, not at line level.
During confirmation, it is set using the minimum of all line expected dates.
The delivery stock move date_deadline depends on this commitment_date.

As a consequence:

Setting a single order-level promise date overrides all per-line expected dates.
All stock moves receive the same (minimum) deadline.

Additionally, this is not aligned with the business logic:

Example:
Line A → lead time = 5 days
Line B → lead time = 10 days
Current behavior sets deadline = min(5, 10) = 5 days for all moves,
which incorrectly forces later deliveries to be scheduled earlier than intended.

Solution:
---------
* Remove the automatic assignment of commitment_date = expected_date in action_confirm().
commitment_date is a user-defined promised delivery date and should not be
 implicitly set during confirmation. By leaving it unset, procurement values
correctly fall back to line._expected_date(), restoring per-line deadline
computation.

---

opw-6106045

Forward-Port-Of: odoo/odoo#258911

The `partner_pages_tree_view` was attempting to modify `activity_ids` field attributes, but this field is added by the mail module in a sibling inheritance branch ([mail.res_partner_view_tree_inherit_mail]), making it unreachable from the [`partnership.view_res_partner_grade_tree`] ancestry chain:
```py
  base.view_partner_tree → partnership.view_res_partner_grade_tree → partner_pages_tree_view
  base.view_partner_tree → mail.res_partner_view_tree_inherit_mail ← activity_ids lives here
```
This caused a ParseError during base module upgrade:
```py
  File "/home/odoo/odoo/odoo/odoo/tools/convert.py", line 639, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml:13
Error while parsing or validating view:
Element '<field name="activity_ids">' cannot be located in parent view
View error context:
{'file': '/home/odoo/odoo/odoo/odoo/addons/base/views/res_partner_views.xml',
 'line': 1,
 'name': 'Partner Pages List',
 'view': ir.ui.view(2148,),
 'view.model': 'res.partner',
 'view.parent': ir.ui.view(2108,),
 'xmlid': 'website_crm_partner_assign.partner_pages_tree_view'}
```

**Steps to reproduce:**
- In a v19.1 db install `website_crm_partner_assign`
- Go to apps and search base module and click upgrade

**Fix:**
Make the partner view from partnership inherit from the one defined in mail instead of the one defined in base. 

opw-6186684

[mail.res_partner_view_tree_inherit_mail]: https://github.com/odoo/odoo/blob/saas-19.3/addons/mail/views/res_partner_views.xml#L58C21-L67
[`partnership.view_res_partner_grade_tree`]: https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/partnership/views/res_partner_views.xml#L48-L57





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

Forward-Port-Of: odoo/odoo#264639

**Steps to reproduce in runbot:**
1. Install hr_holidays_attendance.
2. Create an employee with a contract start date (e.g., April 1st).
3. Set the timezone(for both user and emp working schedule) to Europe/Brussels.
4. Create an attendance record (e.g., April 15th).
5. Go to Reporting > Time Off Ledger and remove all filters.
 -> Attendance is correctly shown for all dates from April 1st
6. Create a public holiday on April 16th starting at 00:00.
7. Check the Time Off Ledger again.

**Issue:**
The attendance entry for April 15th disappears after adding the public holiday.

**Cause:**
Calendar leave datetime fields (date_from/date_to) are stored in UTC but compared against attendance dates without converting to the employee's resource calendar timezone, causing date boundaries to shift and records to be incorrectly excluded.
https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L133-L144

**Solution:**
Convert calendar leave datetimes to the employee timezone before casting to date, ensuring comparisons reflect the correct local boundaries.

**NOTE:**
This issue is mainly reproducible on runbot since its server timezone is
GMT. On local machines configured with UTC, the stored datetime values
already align with the expected conversions, so the date shift does not occur.


opw-6118043




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

Forward-Port-Of: odoo/odoo#262179

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#117115
Forward-Port-Of: odoo/enterprise#111304

# How to reproduce
- Create 2 MO's A & B, both having the same product_id & bom_id
- Split MO A into two MO's A1 & A2
- Merge MO's A1 & B

# The issue
MO A2 no longer has a production group (visible via Studio).
If the user tries to partially produce the MO and create a backorder, a traceback popup appears with :

"ValueError: max() iterable argument is empty"

# Cause
The traceback is triggered because we use the `max()` function on `self.production_group_id.production_ids` when creating the backorder, but `production_ids` is an empty recordset since `production_group_id` is also empty.

https://github.com/odoo/odoo/blob/0d8eaeeb971f2f670aebb1b72ed03f4a2d5e0105/addons/mrp/models/mrp_production.py#L1936

The production group is empty because when merging two MO's we delete it without paying attention to other remaining links.

https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/mrp/models/mrp_production.py#L2555

Note : the production groups were introduced by this commit (https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a)

# Proposed solution
When merging, we unlink the original MO's from their production group.
Then, we check every altered production group : if they are not linked to any MO anymore, we delete them.

opw-6055376

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

Forward-Port-Of: odoo/odoo#256600

### Description of the issue/feature this PR addresses: 
**Issue**: During KSeF authentication, some foreign qualified certificates causes a crash with error _"Failed to authenticate with XAdES: 400 Client Error: Bad Request for url: https://api.ksef.mf.gov.pl/v2/auth/xades-signature"_ This is due to Odoo not handling different `SubjectIdentifierType`

**Solution**: Implement a try/except block to safely check for the NIP in the certificate's subject string, defaulting the identifier type to `certificateFingerprint` when the NIP is missing or a ValueError is caught.

### Current behavior before PR:
The `SubjectIdentifierType` is hardcoded as `certificateSubject`, and does not handle `certificateFingerprint` at all. This causes there to be an error when trying to authenticate with the KSeF server using XAdES signature.

### Desired behavior after PR is merged:

The sign_authentication_challenge method will now safely evaluate the subject string. It assigns `certificateSubject` only if the NIP is verified to be in the subject string. If the NIP is absent or a ValueError occurs during parsing, the system safely falls back to using `certificateFingerprint`. This prevents tracebacks and ensures the correct XML payload is sent to the KSeF server.

Ticket [link](https://www.odoo.com/odoo/project.task/6125243)
opw-6125243

Forward-Port-Of: odoo/odoo#264851

### Description of the issue/feature this PR addresses:

The business premises label on Croatian invoices can legitimately contain alphanumeric characters (e.g., "v1"), as noted in the field's tooltip.

However, the regex pattern inside `_get_l10n_hr_fiscalization_number` used to extract the sequence parts strictly expected digits (`\d+`) for the premises label segment. Because of this, if an invoice was generated with an alphanumeric sequence like `INV-2026-0001/v1/1`, the regex failed to match and returned `False`, leading to a traceback when the system attempted to process the fiscalization number.

This commit updates the regex to correctly accept alphanumeric characters for the premises label, ensuring the sequence parses successfully.

opw-6129009

### Steps to reproduce:

- Settings > Users & Companies > Companies > New > set Address country to Croatia
- Select the newly created Croatian company
- Apps > Activate l10n_hr_edi module
- Accounting > Configuration > Accounting > Journals > click Sales journal > change “Business premises label” to “v1”
- Contacts > New > set Address country to Croatia
- Accounting > Customers > Invoices > New > select the newly created contact and choose any product > Confirm

### Current behavior before PR:

Traceback error when attempting to confirm an invoice when both the company and the customer have their country code set to 'HR'. This is because `_get_l10n_hr_fiscalization_number` does not accept alphabet characters in the premises label section of the regex.

### Desired behavior after PR is merged:

- No traceback error when confirming the invoice
- `_get_l10n_hr_fiscalization_number` correctly parses the fiscalization number

Forward-Port-Of: odoo/odoo#263650

Issue:
------
`l10n_br.address_form_fields` inherits from `portal.address_form_fields` but targets a `<select>` element that was moved to `portal_address_extended.address_extended_form_fields` in [saas~19.2].

Traceback:
----------
```py
Error while parsing or validating view:

Element '<xpath expr="//select[@name=&#39;city_id&#39;]/option[not(@value=&#39;&#39;)]">' cannot be located in parent view
```

Steps to reproduce:
-------------------
1. Install `l10n_br` in v19
2. Upgrade to v19.2
3. Upgrade the `l10n_br` module →  Traceback

Root cause:
-----------
The view is adapting an element owned by a sibling view, making the inheritance hierarchy conceptually wrong and fragile.

Solution:
---------
Update the `inherit_id` of `l10n_br.address_form_fields` to `portal_address_extended.address_extended_form_fields` so it correctly inherits from the view that owns the targeted element.

opw: [6125901]

[saas~19.2]: https://github.com/odoo/odoo/commit/026c6f9f2a388ee509a135c53e38f5bb3d08ff73
[6125901]: https://www.odoo.com/odoo/70/tasks/6125901?debug=1

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

Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions.

**Steps to Reproduce:**
 - Install `l10n_au_hr_payroll_account` with demo data.
 - Switch to an `Australian` company.
 - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`.
 - Open an existing record or create a new one.
 - Remove the `Source Entity Id Type` value and click anywhere.

`ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id`

After [change] in the selection field behavior, when the user removes the Source Entity Id 
Type, the compute method is triggered to compute the Source Entity ID. However, the 
condition in the compute method is not match, so no value is assigned. As a result, 
the method fails and raises an error.

This commit ensures that if the condition is not match, the Source Entity ID is explicitly 
set to False.

[1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

Forward-Port-Of: odoo/enterprise#115466

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

Forward-Port-Of: odoo/odoo#265071
Forward-Port-Of: odoo/odoo#245905

The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10`

This shifts the max aml.id 40 bits to the left.

Example:
Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number.

1 << 20 = 1048576
1048576 | 1 = 1048577
1048577 << 10 = 1099512676352
1099512676352 | 1 = 1099512676353
1099512676353 << 10 = 1152922604119523328

With this format, the highest guaranteed AML ID this query can handle is under 838,861.

The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher.

`MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id`

|  | AML Max | RULES.ID Max |RULES.USER_ID Max|
| --------------------- | ------ | ------ |  ------ | 
| Before | 838,861  | 1,048,576 | 1,024 |
| After | 858,993,459 |1,048,576 | 1,024|

opw-6124026

Forward-Port-Of: odoo/enterprise#114711

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#117490
Forward-Port-Of: odoo/enterprise#115285