### Issue:
When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction

Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected

### Cause:
In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array

This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it
There is no reason to block the sum of lines with the same currency

When there is no selectedLines, the function returns early and doesn't unhide the balance

### Steps to reproduce:
- Install `account_accountant` with demo data
- Enable a foreign currency like EUR
- Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€)
- Go to the Dashboard, and select Bank
- Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$)
- Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency`
- Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$)
- Switch to the Kanban View and Reconcile the line Multi-currencies
- Select your 2 invoices one by one
Before the fix, after selecting the second invoice, the balance is displayed as `/`

For the additional case:
- Unselect all lines
- Select a line in another currency (e.g., USD), then unselect it
The balance remains hidden

opw-6063366

Forward-Port-Of: odoo/enterprise#115101

## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
    - *Billing Period*: 6 Months
    - *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
    - Any Customer
    - Recurring Plan RP
    - Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**

## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382

This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.

## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.

**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.

opw-6151530

Forward-Port-Of: odoo/enterprise#115830

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/odoo#260518
Forward-Port-Of: odoo/odoo#257258

Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription

Steps to reproduce:
1. Install Subscriptions
2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago
3. Confirm the subscription
4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token"
5. Go back to the previously created subscription (see that a reminder email has been added in the chatter)
6. Duplicate the subscription and confirm the duplicate
7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again
8. There are no reminder for the duplicate subscription

Issue:
The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here
https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120

Solution:
Set `copy=False` on the field `last_reminder_date`

opw-6167356

Forward-Port-Of: odoo/enterprise#116335
Forward-Port-Of: odoo/enterprise#115509

## Fix 1

Steps to reproduce:
- create a time off type
- create a leave for that type and validate it
- go on the time off type record and try to change the request unit
- an error related to the leave is raised

Before this PR, it was not prevented to change the request unit
for time off types once leaves of that time off type were already taken,
leading to an error.

After this PR, `request_unit` now can be changed in the settings with
existing validated leaves without having an error raised. The leaves that
were previously created will not have their value recomputed based on the
new granularity for historical purposes.

This PR also removes an unused depends on
`_compute_dashboard_warning_message`.

## Fix 2

Before this PR, it was possible to have overlapping leaves:
(For time types that do not allow requests on top)
- Create a leave A and refuse it
- Create another leave B
- Validate B
- Validate A

This overlap should be caught and prevented by a constraint but currently isn't.

This PR adds the state to the dependencies to exclude the check on
refused/cancelled leaves but ensure that they cannot be validated if they overlap
other non-refused/cancelled leaves.

task-6153055

**Steps to reproduce:**

- Download the German language
- Set the restaurant to QR + Ordering
- Set the Service at Table, pay after each order
- Set the language to German
- Go to the Self and order something while the language is German
- Chose table 12
- Go to the kitchen display
- The title is truncated, meaning we can't see the table number

**Why the fix:**

If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in 
ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display.

We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number.

Before:
<img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" />

Afer:
<img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" />


opw-6096111

Forward-Port-Of: odoo/enterprise#114859

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#115693
Forward-Port-Of: odoo/enterprise#112879

Issue:
---
In `tax included` companies, the down payment section is not correctly calculated.

Steps to reproduce:
- Configure selected company's field account_price_include to be "tax_included"
- Create a sales order
- Create 1 or more down payment invoices for the SO and confirm
- Create a final invoice that pays for the rest of it
- On this final invoice where the down payment(s) are also listed, click on the preview button

Current behavior:
- The down payment section's total is the sum of the subtotal

Expected behavior:
- The down payment section's total should be the sum of the totals

Justification:
---
The amounts included in the invoice report are dependent on the
`company_price_include` field in `res.partner`. If tax_excluded,
subtotals are listed. If `tax_included`, totals are listed.
There was a mismatch between the entries and the section total;
the section entries could have the total as the amount while
the section's sum would be in terms of subtotals.

Fix:
---
On stable we can still rely on `section_subtotal` but set its
amount to total instead of subtotal in case of `tax_included`.

However, this fix is not stable as there is a xpath on `t-set`
expression in `l10n_ar`.
To avoid breaking the views, we can re-set the `section_subtotal`
in the next lines.
This would still cause issues as it will replace the overridden
logic in the `l10n_ar` implementation.
To prevent that issue, we can re-set the `section_subtotal` only
if the value is the same as `get_section_subtotal`, which means
we are in the main implementation and it's safe to re-set the value.

opw-6127615

Forward-Port-Of: odoo/odoo#262364
Forward-Port-Of: odoo/odoo#261372

On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from.

Steps to reproduce:
===================
1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains.
2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2).
3. From W2, submit a ticket on /helpdesk/helpdesk2.
4. In the ticket, send email from the chatter.
5. Inspect the outgoing notification email.

=> "View Ticket" button points to W1's domain.

Root cause:
============
`helpdesk.ticket` has no `website_id`, so `Base.get_base_url`
 falls through to `company_id.website_id.domain`, i.e. the first
website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in.

Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from.

=> "View Ticket" button points to W2's domain (the site the
   customer is browsing).

opw-6071999

Forward-Port-Of: odoo/enterprise#116034
Forward-Port-Of: odoo/enterprise#114693

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/85d358ab17 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132)
https://github.com/odoo/o-spreadsheet/commit/ae110a1c6d [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300)
https://github.com/odoo/o-spreadsheet/commit/3741f7e88c [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335)
https://github.com/odoo/o-spreadsheet/commit/1c7f0ba4c8 [FIX] pivot: fix design panel layout [Task: 6148708](https://www.odoo.com/odoo/2328/tasks/6148708)
https://github.com/odoo/o-spreadsheet/commit/c1c24906ae [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820)
https://github.com/odoo/o-spreadsheet/commit/56ecc18dcb [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696)
https://github.com/odoo/o-spreadsheet/commit/cd30b0abc8 [FIX] zoom: scorecard chart rendering with zoom [Task: 6072348](https://www.odoo.com/odoo/2328/tasks/6072348)
https://github.com/odoo/o-spreadsheet/commit/cbc62c46f1 [FIX] format: don't humanize scientific format [Task: 6068353](https://www.odoo.com/odoo/2328/tasks/6068353)
https://github.com/odoo/o-spreadsheet/commit/7c130fa8ce [FIX] Data filter : clear/select all button [Task: 6075166](https://www.odoo.com/odoo/2328/tasks/6075166)
https://github.com/odoo/o-spreadsheet/commit/3d332c32b4 [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098)
https://github.com/odoo/o-spreadsheet/commit/ba6f59978d [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`work_entry_type_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#262716
Forward-Port-Of: odoo/odoo#249793