Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

Issue
-----
When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages.

Steps to reproduce
-----
- Enable packages
- Create a product with one package in stock
- Operation Types > Delivery Orders, set Move Entire Packages to true
- Create a delivery for a package
- Scan the package barcode
- Exit the delivery
- Re-enter the delivery

> Quantity for the line is 1/false

Cause
-----
The line is picked, so it is considered as not reserved

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289

when doing

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813

This leads to `qtyDemand` returning false instead of 1

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18

-----
Ticket:
opw-5960629

Forward-Port-Of: odoo/enterprise#114451
Forward-Port-Of: odoo/enterprise#113816

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114730
Forward-Port-Of: odoo/enterprise#113083

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/odoo#257539

### Issue:
When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead

For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040`

### Cause:
The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report

### Note:
The example above uses a Belgian fiscal position to reproduce the issue

Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default

A related fix makes the Intervat settings available in that case
Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15

### Steps to reproduce:
- Disable demo data and install `accountant`
- Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040)
- Click the alert to install the Belgian taxes
- Create and confirm an invoice for a Belgian customer:
  - Fiscal Position: Belgium
  - Any product with a Belgian tax
  - Invoice Date: 01/01/2026
- Open the Tax Report and select `VAT Return (BE)` for January
- Click `Returns` and select the full year
- Mark the December return as Completed from the three-dot menu
- Review January and fill the missing company data (TIN: 1111111, phone and email)
- Click `Validate -> Lock -> Submit`

### Before the fix:
The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`).

opw-6076540

Some countries lile Estonia, Nederlands or France apply a rounding from
the tax report by adding a line to the end of the query results representing
the sum of the roundings on each line of the tax report.

When having a company with branches, the rounding is applying in each
closing move (one per company/branch) but the value is coming from the
aggregated report lines, this leads to wrong computation of the closing
entries.

Cause:

In `_generate_tax_closing_entries` we loop over each company, therefore
`_compute_tax_closing_entry` is called one time for each company, but it
uses the report options containing all companies

Fix:

Use options with only the current company in
`_compute_tax_closing_entry`

Steps:

- Install FR localisation
- Select FR company and create two branches
- Create, for last month:
  - 1 bill for parent company (100 with tax 20% G)
  - 1 invoice per branch (200 and 300 with tax 20% G)
- Create a tax return with opining date at the beginning of the current
  month
- Submit the last return and go to the created closing entries
-> See that closing entries are wrong

opw-5976359