- 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

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

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

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

**Steps to Reproduce:**
1. Open Recruitments
2. Find a job position without a recruiter in the kanban view
3. Clicking on the assign recruiter widget produces a traceback

**Bug Cause:**
The `?unique=` cache related parameter was added to the avatar image URL in the `autoCompleteItem` slot of `KanbanMany2OneAvatarEmployeeField`. This parameter relies on `write_date` being available on the autocomplete suggestion record. However, `web_name_search` only returns `id` and `display_name`, so `write_date` is undefined on
autocomplete suggestion records, causing a crash when accessing `autoCompleteItemScope.record.data.write_date.ts`.

**Bug Solution:**
Remove the `?unique=` parameter from the avatar image URL in the `autoCompleteItem` slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction.

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

Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1].

To do so it limits the opacity to the layout actions, but the style was not applied because ActionList has more CSS specificity that requires using `--o-mail-ActionList-Button-opacity` variable for the non-hover opacity value. Since this was not defined, this default to opacity 100%, thus not applying the reduced opacity when not mouse-hovering.

This commit fixes the issue with `--o-mail-ActionList-Button-opacity` of `.75`, so that opacity is slightly reduced when no mouse-hovering.

[1]: https://github.com/odoo/odoo/pull/259866

Before / After (mouse-hover on "Picture-in-Picture", see lack of visual distinction)

<img width="58" height="32" alt="Screenshot 2026-04-22 at 11 21 47" src="https://github.com/user-attachments/assets/e04b0f8c-c754-4ea4-8870-752610418587" />
<img width="57" height="28" alt="Screenshot 2026-04-22 at 11 21 25" src="https://github.com/user-attachments/assets/a5aa9987-ddaf-45f8-9e2a-260fd04dcfb9" />

Forward-Port-Of: odoo/odoo#260599

IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa fa-circle` for online status.

This change introduced an accidental regression in Safari, where position of the offline status is wrong. This comes from a bug in Safari where some CSS inside foreignObject resets the position of the element to position 0, 0 on the global SVG [2] [3].

This affects offline status because this IM status has an `opacity-75`, intended to reduce distraction from the offline, but since this changes opacity this introduce the bug in Safari of mis-position.

This commit fixes the issue by moving the applied CSS to change opacity from `opacity-X` rules inside foreignObject to the parent `g` tag above `foreignObject`. That way, the element inside `foreignObject` has no change of opacity but instead the `g` has it, which is ok for Safari.

Note that this implementation assumes that change of opacity inside `foreignObject` is made only once and with `opacity-X` classnames.

[1]: https://github.com/odoo/odoo/pull/246182
[2]: https://github.com/bkrem/react-d3-tree/issues/284
[3]: https://bugs.webkit.org/show_bug.cgi?id=23113

Task-6143646

Before / After

<img width="308" height="579" alt="Screenshot 2026-04-21 at 12 51 52" src="https://github.com/user-attachments/assets/41596916-f371-407e-acb1-eb097c497360" /> <img width="310" height="584" alt="Screenshot 2026-04-21 at 12 51 20" src="https://github.com/user-attachments/assets/513df1f5-4cde-4cb7-8769-d6264dfb36a0" />

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