**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#265129
Forward-Port-Of: odoo/odoo#262179

Currently, an error occurs when a user tries to create a helpdesk team record.

**Steps to Reproduce:**

 - Install the `helpdesk` module without demo data.
 - Go to `Settings` > `Technical` > `Email` > `Email Templates` and delete the 
   `Helpdesk: Ticket Received` template record.
 - Go to `Helpdesk` > `Configuration` > `Stages` and remove all records.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams` and click `New` to create a record.

`AttributeError: 'NoneType' object has no attribute 'id'`

When the user deletes all stages, the system attempts to create a new stage and assign the 
"Helpdesk: Ticket Received" mail template to it [1]. However, if this template record does not 
exist, accessing its id raises the error.

This commit ensures that the template record exists before accessing its id, otherwise, None is 
passed as the default value.

[1]: https://github.com/odoo/enterprise/blob/32187f79fb0a595497a5e77db4b22b417b03b8dd/helpdesk/models/helpdesk_team.py#L34

sentry-7482994877

Forward-Port-Of: odoo/enterprise#117446

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

Forward-Port-Of: odoo/odoo#264045

Overview
------

When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up.

How to Reproduce
------

1. Open the Email Marketing app
2. Create a new mailing (or you can use an existing one that has some clicks) and send it
3. Make a click in the email from the recipient's side
4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button)
5. Make a search based on the Link (short_url) field

Expected Behavior
------

Return the list of links that matches the entered search query.

Current Behavior
------

Odoo Server Error.

Cause & Solution
------

The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method.

Task-6131693

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

Forward-Port-Of: odoo/odoo#265293
Forward-Port-Of: odoo/odoo#260146

### Issue before this commit:
In the previous implementation, several Italian taxes, specifically the 4% INPS and the 4% Pension Fund (F.Pens), were not correctly initialized. Although the relevant EDI data was present in the source CSV templates, it was missing from the actual tax records in the database.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi
2. Go to Accounting -> Taxes
3. Open 4% INPS tax and 4% F.Pens and go to Advanced Options tab and see that no Pension Fund Type is associated by default

### Cause of the issue:
While moving the witholding data from l10n_it_edi to l10n_it in this commit https://github.com/odoo/odoo/commit/40e09ca01242 the templates were not correcly rendered and set up.

### Reason to introduce the fix:
For a tax to be correctly recognized from the XML, it is essential that we have the corresponding tax already configured in Odoo, including the specific type. We should have at least these two taxes fully configured so the system can elaborate them correctly when imported from vendor bills.

opw-6093221

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

Forward-Port-Of: odoo/odoo#258947

`_generate_and_send_invoices` raises `KeyError: 'proforma_pdf_attachment'` when `_get_invoice_extra_attachments` returns an empty recordset for a move in the `success` dict.

The `proforma_pdf_attachment` key is only populated in `_generate_invoice_fallback_documents`, which is called exclusively when `allow_fallback_pdf=True`. However, the code at the return step also triggers when `allow_fallback_pdf=False` (normal wizard path), where the key is never set.

Replace the bare dict access `move_data['proforma_pdf_attachment']` with `move_data.get('proforma_pdf_attachment', self.env['ir.attachment'])` so the flow returns an empty attachment recordset instead of raising a `KeyError` when no fallback proforma PDF was generated.

Fixes: KeyError: 'proforma_pdf_attachment' in account.move.send.wizard Steps to reproduce:
  1. Use the Send & Print wizard on a posted invoice
  2. Trigger a condition where _get_invoice_extra_attachments returns an empty recordset (e.g. via l10n_vn_edi_viettel with sinvoice files not yet fetched) despite no error being raised

Forward-Port-Of: odoo/odoo#264564

When updating a mo, if the new component has a multilvl bom, it will only create a mo for the direct child and not the next

Steps to reproduce:
-------------------
* Create a products "Main", "Final", "Semi", "Raw"
* Create a Bom for "Final" with "Semi" as component
* Create a Bom for "Semi" with "Raw as component
* Add MTO on Final and Semi
* Create a MO for Main with no components and confirm it
* Add "Final" to the mo as component as save. -> The MO for "Final" is correctly created with "Semi" as component but there is no MO for "Semi" with "Raw" as component.

Observation:
-------------

When updating de MO, it will write the new SM (Final) to the production, and we will call ```_autoconfirm_production``` with ```no_procurement```: https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/mrp/models/mrp_production.py#L1051 Where we will directly confirm the sm (```_action_confirm```).

From the SM ```_action_confirm``` we will create and run a procurement (manufacture in our case).
From the manufacture we will create the new move line for Semi and go through ```action_confirm``` on the manufacturing order:
https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/stock_rule.py#L116-L118
In the MO ```action_confirm```, we will confirm the move and should create new procurement for the moves that need them, but, since in our case we have ```no_procurement``` in the context, we will set ```create_proc``` to false:
https://github.com/odoo/odoo/blob/9ef76a4d6010191ab7ab1a0d1085972901280dda/addons/mrp/models/mrp_production.py#L1635
Since ```create_proc``` is false we will not create a procurement for those move lines:
https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1557-L1558
https://github.com/odoo/odoo/blob/6fb69b5640743d3bc7bb52c73cb27da428f2451c/addons/stock/models/stock_move.py#L1571-L1580

opw-6005675

Forward-Port-Of: odoo/odoo#258153

Issue
-----
`REF` field of Fedex labels is missing.

Steps to reproduce
-----
- Setup Fedex
- Create a product (set weight)
- Create a delivery for the product
	- Set carrier as Fedex
- Validate delivery
- Opend the label

> REF field is empty

Cause
-----
When filling the `CustomerReferences`, we only specify the SO

https://github.com/odoo/enterprise/blob/aae680f5b86fa87193ba6616e8431eed985b2ee7/delivery_fedex_rest/models/fedex_request.py#L309-L313

The `REF` field is populated using `CUSTOMER_REFERENCE` references, which is not present in this case.

Excerpt of the API DOC
-----
```
"CustomerReference": {
	"type": "object",
	"properties": {
		"customerReferenceType": {
			"type": "string",
			"description": [...],
			"example": "DEPARTMENT_NUMBER",
			"enum": [
				"CUSTOMER_REFERENCE",
				"DEPARTMENT_NUMBER",
				"INVOICE_NUMBER",
				"P_O_NUMBER",
				"INTRACOUNTRY_REGULATORY_REFERENCE",
				"RMA_ASSOCIATION"
			]
		},
		"value": {
			"type": "string",
			"description": [...],
			"example": "3686"
		}
	}
},
```

[...] replaces long description strings, refer to API for full documentation.

Result after fix
-----
<img width="477" height="738" alt="image" src="https://github.com/user-attachments/assets/0d3a0786-5b7d-41cc-8548-2dc7b0f379ab" />

-----
Ticket:
opw-6101620

Forward-Port-Of: odoo/enterprise#116870