Currently, an error occurs when user tries to open unassigned opportunities assigned to a team.

Steps to replicate:
- Install `crm` with demo.
- Open `CRM > Sales > Teams` and click `Sales` team.
- Remove the `salesperson` from any lead, then return to `Teams` via breadcrumbs.
- On the kanban card for Sales, click “Unassigned Leads”.

Error:
```
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_team.py', line 728, in action_open_unassigned_opportunities
    context = self.env['crm.lead']._evaluate_context_from_action(action)
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_lead.py', line 727, in _evaluate_context_from_action
    return literal_eval(context_str)
  File '/home/odoo/src/odoo/saas-19.2/odoo/_monkeypatches/ast.py', line 28, in literal_eval
    return orig_literal_eval(expr)
  File 'ast.py', line 66, in literal_eval
    node_or_string = parse(node_or_string.lstrip(' \t'), mode='eval')
  File 'ast.py', line 52, in parse
    return compile(source, filename, mode, flags,
IndentationError: unexpected indent (<unknown>, line 8)
```

Cause:
- Error occurs after a recent [PR].
- As we called `literal_eval()` on the context string that we passed on to the `act_window` [1], it tries to parse the string using python like rules, the context is received as this:

```
"{\n 'search_default_team_id': [False],
 \n'default_team_id': False,
 \n'default_type': 'opportunity',
 \n'default_user_id': 2,
 \n'show_lead_gen_button': True
 }\n       "
    ^^^^^^^
```

- The extra whitespace/indentation (coming from the `act_window` context definition) makes the string invalid for strict parsing, causing `literal_eval()` to fail.

- Additionally, in the above given context string the `search_default_team_id` and `default_team_id`are  both `False`  because we called `_evaluate_context_from_action()` method on an empty recordset and when we try to [substitute] `active_id` with `self.id`(which is False because we dont have any record) we get another JS Error that is caused by not receiving any results for the search default on team.

Solution:
- Using `strip()` function removed the extra whitespaces.
- Passed the `team_id` through context (as we cant add new parameters to a function in stable) and assigned it in place of `active_id`.

[1]: https://github.com/odoo/odoo/blob/746ea418da2af2a6d36daea4dc544bdf3bc28495/addons/crm/views/crm_team_views.xml#L41-L48
[PR]: https://github.com/odoo/odoo/pull/240202/changes#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2R724
[substitute]: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/crm/models/crm_lead.py#L726

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

*: timesheet_grid,timesheet_grid_hr_attendance,helpdesk_timesheet

# [FIX] timesheet_grid_hr_attendance: open timesheet systray on check-in
Before this commit, the user had to re-open the systray in order to open the timesheet systray. Now, it is directly showed to the user upon check-in, without having the systray being closed automatically.

# [FIX] web_enterprise: required project is not underlined bolder when hovered
In this commit, we ensure that the border under the project in the timesheet inline form is bolder when hovered.

# [FIX] timesheet_grid,helpdesk_timesheet: prefill timesheets in systray
In this commit, we enable timesheets in the systray to be prefilled with project, tasks, and helpdesk tickets if the user opens the systray from any of these views, provided that the fields were empty.

Further, say a project is already set, then any opened task from that project will also be populated upon opening the systray under the condition that both projects match. The same reasoning applies to helpdek tickets.

# [FIX] sale_timesheet_enterprise: conditionnal class on timesheet timer
After closing the systray, the 'billable' radio button ended up on a new line because the class on the timer was not correctly removed.

With this commit, the button will remain on the same line as the timer, even after closing and re-opening the systray.

# [FIX] sale_timesheet_enterprise: hide assistant button
This commit adds conditions to display the button opening the timesheet assistant. Prior to this, the button was displayed even if the setting is not active on the user.

See odoo/odoo#257930

task-6088779

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

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

### Issue:
If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags

### Cause:
The `_get_payments_vals` method, `InstrId` is based on the payslip ID
When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers
https://knowledge.xmldation.com/support/iso20022/general_rules/instrid

This commit adds a unique suffix with the bank_account.id (slip.id-ba.id) to the `InstrId` for each transaction generated to ensure technical uniqueness

This is the part of the code that use the payment name:
https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299

### Steps to reproduce:
- Install `hr_payroll_account_iso20022` with demo data
- On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number`
- Open the Employee page for Abigail Peterson
- In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any)
- Click on Salary Allocation and Save (You'll have a 50/50 ratio)
- Create a new Pay Run (for Abigail Peterson)
- Open the last PaySlip and Validate
- Create Payment Report (Export Format: SEPA)
- Download the Payment Report and check the <InstrId> tags

opw-6069670

Forward-Port-Of: odoo/enterprise#113113

You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled

Steps to reproduce:
1. Install Inventory and eCommerce
2. Go to Website > eCommerce > Products and create a new product "Combo"
3. Set the Product Type to Combo, create and edit a Combo Choice "test" with two options "test 1" and "test 2". Both have Track Inventory enabled, 5 Quantity On Hand and Sell when Out-of-Stock disabled
4. Publish product "Combo" to the website
5. Click on smart button "Go to Website" to open the shop page of product "Combo"
6. Try to increase the quantity
7. The quantity is limited to 1

Solution:
Always set the quantity input's maximum when `has_max_combo_quantity` is true

Issue:
We only set the quantity input's maximum if `allow_out_of_stock_order` is false
This error was introduced in https://github.com/odoo/odoo/commit/0247538efe788a9ff9a4d58f64470325348a4eaa

opw-6050876

Forward-Port-Of: odoo/odoo#260523
Forward-Port-Of: odoo/odoo#257386

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113521

Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date.

**Steps to Reproduce:**
- Install the MRP module (with demo data).
- Activate "**Custom Work Order Dependencies**".
- Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM.
- Confirm and plan the MO.
- Remove both start and end dates of any dependent operation.
- Manufacturing > Planning > Work Orders > Gantt
- Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1').

**Error:**
`TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'`

**Cause:**
At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2].

Fix:
This commit adds a condition before date comparisons to ensure the dates are defined.

[1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284
[2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491

sentry-7377739830