- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula.

see https://github.com/odoo/odoo/pull/193106

```python3
Opération invalide

Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance",
Le format de l'expression de rapport croisé est invalide.

Format attendu : cross_report(<report_id>|<xml_id>)
Exemple : cross_report(my_module.my_report) ou cross_report(123)
```

opw-6103170
upg-4166654(lu)
upg-4163103(it)
upg-4175631(ug)
upg-4177165(es)

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#258826

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

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
The `_compute_template_id` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96


Solution:
-----------
- Update `_compute_template_id` to ensure only active templates are
  automatically assigned.


opw-5974244




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

Forward-Port-Of: odoo/odoo#257580
Forward-Port-Of: odoo/odoo#251186

**[FIX] handle Turkey timezone when tzdata-legacy not installed**

In #236660 we switched from pytz to zoneinfo.

The library `pytz` has `Turkey` in **pytz.all_timezones_set**. 
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy. 

If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`

Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.

For fixing the issue we added fallback for `Turkey`. 
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.


###

**[FIX] handle America/{Catamarca,Godthab} timezones**

As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab

We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.

Turkey:
```
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
    event_values = event._get_recurrence_params()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
    event_date = self._get_start_date()
                 ^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
    return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
                                                ^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```

Catamarca:
```
Traceback (most recent call last):
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
    self._origin.fetch(fields)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
    fetched.mapped(field_name)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
    return [getter(record) for record in records]
            ^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
    user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```

tbg-2529

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

### 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**:
Making a product a kit could prevent confirming deliveries.

**Steps to reproduce**:
- Make sure the account application is installed
- Create a product P without kit
- Create a SO and confirm it
- Make the product P a kit
- Validate the delivery associated to the SO
-> A traceback occurs: the record does not exist anymore

**Cause**:
While confirming the delivery:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown

**Aditionnal information**
Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation.
Therefore, no stock valuation errors will be created.

opw-6063602

Forward-Port-Of: odoo/odoo#258403

### Issue before this commit:
When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax
3. Try to upload an XML for vendor bills with a TC08 tax
4. The tax is not associated

### Cause of the issue:
The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process.

### Reason to introduce the fix:
The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior.

opw-6093352

Forward-Port-Of: odoo/odoo#258341

Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415

Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.

opw-5895622

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414

### Description of the issue/feature this PR addresses:
Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process.

### Current behavior before PR:
When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes.

### Desired behavior after PR is merged:
The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically:
- The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration.
- The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries.

### Benchmark:
The model is iterating through ~1.1M journal items when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 1.4GB| 202 MB |
| ~32,000 journal items | MemoryError | 278 MB |
| ~141,500 journal items | MemoryError | 760 MB |
| ~1.1M journal items | MemoryError | 1.4 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 2 min | 1.5s |
| ~32,000 journal items | MemoryError | 4s |
| ~141,500 journal items | MemoryError | 12s |
| ~1.1M journal items | MemoryError | 56s |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#112230