### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#257647
Forward-Port-Of: odoo/odoo#248619

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#256658
Forward-Port-Of: odoo/odoo#255780

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#257818
Forward-Port-Of: odoo/odoo#253605

Steps to reproduce:
- Create a storable product "P1"
- Update on-hand quantity to 2 units
- Create a delivery with 2 units of P1 and keep it in draft state

Problem:
The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move.

Explication:
For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty`

In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty`

So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available.

https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31

Solution:
When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available.

opw-5159142

Forward-Port-Of: odoo/odoo#257354

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023

Forward-Port-Of: odoo/odoo#257683
Forward-Port-Of: odoo/odoo#247091