## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#122740
Forward-Port-Of: odoo/enterprise#120740

## Current behavior:
In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable argument`` is empty when calling end_date = max(candidates.mapped(stop_date_field_name)).

## Steps to reproduce:
1. In version 19.0 and above, install Project app
2. Create a project and only 1 single task
3. Switch to Gantt chart view
4. Try changing the deadline of a task by dragging its right edge
5. Observe that extending the task's deadline by dragging to the right works fine, but shrinking the deadline by dragging to the left will cause server to throw RPC_ERROR: Odoo Server Error and ValueError: max() iterable argument is empty.

## Cause of the issue:
- A task with NO successors will cause candidates gathered via dependency_inverted_field_name to be empty.
- The empty candidates recordset then get called by max(candidates.mapped(stop_date_field_name)), which is the reason causing error message ValueError: max() iterable argument is empty.

opw-6283566

Forward-Port-Of: odoo/enterprise#121517
Forward-Port-Of: odoo/enterprise#120375

### Steps to reproduce

1. Configure UrbanPiper and start a POS session.
2. Receive an order from the delivery provider.
3. Accept the order and mark it as **Ready**.
4. Cancel the order from the delivery provider.
5. Reopen the running POS session.

### Current behavior

When a delivery provider cancels an order, the `delivery_status` is updated to `cancelled`, while the POS order state remains (`draft`, `paid`, or `done`).

As a result:

* Cancelled deliveries are still included in the active delivery order count.
* `_get_urbanpiper_order_count()` attempts to map the `cancelled` status, which is not present in `status_map`, raising a `KeyError`.
* The POS UI fails to load, preventing users from reopening the running session.

### Expected behavior

Cancelled delivery orders should not be considered active delivery orders and should not be included in the delivery status count, allowing the POS session to open normally.

### Solution

Exclude orders with `delivery_status = 'cancelled'` from the active delivery order count computation. This prevents the `KeyError` and ensures cancelled delivery orders are ignored when computing active delivery statistics.

[Video reproducing the issue](https://drive.google.com/file/d/1XdiylekWV-q6LTbvhCgbyd_KDKlG2imz/view?usp=sharing)

---

**opw-6353861**

Version: 19.0

`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.

- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.

- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.

- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.

taskid- 6329037

Forward-Port-Of: odoo/enterprise#121878

Currently an error occurs when user tries to audit a cell when Balance Sheet is grouped by an analytic acccount.

Steps to replicate:
- Install accountant with demo data and turn on Analytic Accounting.
- Open Balance Sheet Report > Group By an Analytic Account > Click on Any Value under an Analytic Account Column.

Error:
```
File '/home/odoo/src/enterprise/saas-19.3/account_reports/models/account_report.py', line 2876, in dispatch_report_action
    return report_method(model, *args)
File '/home/odoo/src/enterprise/saas-19.3/account_reports/models/balance_sheet.py', line 28, in action_audit_cell
    action['context'].update({
AttributeError: 'str' object has no attribute 'update'
```

Cause:

- When clicking on a report cell, `dispatch_report_action()` calls `action_audit_cell()` of the corresponding report (Balance Sheet in this case) which in turn calls `action_audit_cell()` of `account.analytic.report`.

- When the flow reaches [1], the window action for analytic items is fetched, where its [context] is returned as a string instead of a dictionary.

- This action is then received [here] with `context` as a string, and attempting to update it results in an error.

Solution:
- Converted the string to dict using `literal_eval()`.

[1]: https://github.com/odoo/enterprise/blob/a26981667361839ad38f45da5a6f23ae8e6478f1/account_reports/models/account_analytic_report.py#L208

[context]: https://github.com/odoo/odoo/blob/824446b65cbe3850f88f56090f0473f0e94bf4f3/addons/account/views/account_analytic_line_views.xml#L88-L91

[here]: https://github.com/odoo/enterprise/blob/b5f884a49344aa097c20fc128e9d290b97970f1a/account_reports/models/balance_sheet.py#L28

opw-6311673
sentry-7513784149

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#122157
Forward-Port-Of: odoo/enterprise#120219

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

Forward-Port-Of: odoo/enterprise#122747
Forward-Port-Of: odoo/enterprise#117743

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

Forward-Port-Of: odoo/odoo#273002

Issue:
Replacing an icon removes style classes applied to the original icon,
such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`.

This issue was introduced by [commit], which stopped preserving
image-specific classes when replacing an image with an icon. This
behavior is appropriate in the backend editor, where icons do not
support these styling options. However, the same logic also affected the
website builder, where icons support the same styling options as images.
As a result, these classes were unnecessarily removed when replacing an
icon.

Steps to reproduce:
1. Add an icon with style classes such as `rounded`, `rounded-circle`,
   `shadow`, or `img-thumbnail`.
2. Replace the icon.
3. Notice that the style classes are removed from the new icon.

Fix:
Preserve these style classes when replacing icons in the website
builder, allowing the newly selected icon to retain the existing visual
styling.

[commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab
task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832)

Forward-Port-Of: odoo/odoo#273598
Forward-Port-Of: odoo/odoo#265496

**Description of the issue/feature this PR addresses:**
When branch companies are involved, currency conversion goes through the branch instead of its root company. Because currency rates in Odoo only ever live on the root company, resolving a rate through a branch is incorrect. Furthermore, when two sibling branches are active at the same time, it makes the computed company a multi-record set, breaking the reconciliation process with an "Expected singleton" error.

This is grounded in how the rest of res.currency already behaves by design:

res.currency._get_rates() looks up rates with company_id in (False, company.root_id.id).

res.currency.rate._check_company_id() forbids setting a rate on a company that has a parent_id.

Therefore, rates are, by design, only ever meant to live on the root company. The only place that still passed the raw company (branch included) into with_company() was res.currency._get_conversion_rate().

**Current behavior before PR:**
_get_conversion_rate() forwarded the received company untouched to from_currency.with_company(company). As a result, Odoo looked up the conversion rate through the branch rather than its parent.

When more than one branch of the same parent is active at the same time (resulting in a recordset of 2+ branches), company.currency_id inside _compute_current_rate() was no longer a singleton, causing the code to crash with ValueError: Expected singleton: res.company(...) — even though every branch shares the exact same currency and rate defined on their common root company.

**Steps to reproduce:**
1) Enable multi-company and branches.
2) Create a parent company P (e.g., using ARS as main currency).
3) Create two branches under P: B1 and B2 (branches inherit P's currency).
4) On the parent company P, define a currency rate for a foreign currency, e.g., USD (Accounting > Configuration > Currencies > USD > Rates).
5) Log in with a user that has P, B1, and B2 all selected as active companies (all three checked in the top-right company switcher).
6) In branch B1, create a customer invoice in USD.
7) In branch B2, register a customer payment in USD.
8) Open the Auto-reconcile tool or try to reconcile the journal items directly.

Result: A ValueError: Expected singleton is raised during the reconciliation because the conversion rate is resolved against the multi-company recordset B1 + B2 instead of P.

**Desired behavior after PR is merged:**
_get_conversion_rate() now resolves the company to its root_id before computing the rate. Branches will correctly fallback to their parent company, and multiple active sibling branches will collapse to a single root company, ensuring that company.currency_id remains a singleton.

With the same steps described above, the invoice and the payment now reconcile normally, safely using the single USD rate defined on the parent root company. Non-branch (standalone) companies remain unaffected since a root company's root_id is itself.

**video**
https://drive.google.com/file/d/14NGTTzP28CgSiYFQdFZ6juHSsib_MDd9/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#273758

### Issue:
When creating a website through the configurator and selecting the
website type 'an eCommerce', the shop feature is not preselected as
expected.

### Steps to reproduce:
- Ensure that the eCommerce module is not installed.
- Navigate to Website > Configuration > Settings.
- Click on the "New Website" button to create a new website.
- Select the "eCommerce" option as the website type and proceed to the
  next step.
- On the "Add Pages and Features" screen, observe that the "Shop" option
  is not selected by default.

### Reason:
0cb45457 renamed the website type from `online_store` to `eCommerce`,
but the related feature was not updated and still references the old
name. As a result, the preselection is not triggered.

### Fix:
Restore the eCommerce website type's internal name to `online_store` in
the configurator. This matches the value already stored in the database
for existing installations, allowing the shop feature preselection to
work for existing users as well, without requiring a data update.

task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263)

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

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

Forward-Port-Of: odoo/odoo#268829

similar fix: https://github.com/odoo/odoo/pull/181220

- On a kanban view, click "New" to open a quick create record;
- On a many2one field, type a value and click "Create and edit...";
- A dialog opens to create the related record;
- From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one;
- Change tab in the browser.

Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user.

This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed.

opw-6357255

Forward-Port-Of: odoo/odoo#274054

### Commit 1:

[FIX] website: prevent CSRF error by blocking duplicate form submission

Before this commit: Clicking the logout button from the website
preview triggered two simultaneous logout requests:

1. The browser performed the default form submission with a valid
   `csrf_token`, destroying the session afterward.
2. During the same click event, `setupClickListener()` intercepted
   the click using `closest('[action]')`, found the parent
   `/web/session/logout` form, and triggered a second POST request
   using `odoo.csrf_token`.

Since the session was already destroyed by the first request, the
second request resulted in a "CSRF validation failed" error.

This commit prevents the default form submission before triggering
the manual POST request, ensuring that only one request is sent.

Runbot-940403

--------------------------------------------------------------------------------------------------------------------------------

### Commit 2:

[FIX] website: enable free sign up setting in test_auth_forms_warning

Steps to reproduce:
1. Install any website related module (e.g. `website`, `website_event`).
2. Keep the default configuration and do not manually enable
   'Free sign up' in Settings.
3. Run `test_auth_forms_warning`.

Before this commit: The test did not programmatically enable the
'Free sign up' setting. As a result, it failed unless a developer
manually navigated to the setting and enabled it beforehand.

After this commit: This commit explicitly enables the "Free sign up"
configuration during test execution, allowing public access to the
`/web/signup` page and ensuring the test passes without any manual
setup.

runbot-940394

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

Forward-Port-Of: odoo/odoo#272020

after commit [1] we are not able to open pos session, if we have installed only
point_of_sale

[1] https://github.com/odoo/odoo/commit/f20b2d22dbec2e6a5e682539489ab94d9c96fb21

Traceback

```py
File "odoo/saas-19.3/addons/point_of_sale/models/pos_session.py", line 161, in load_data
    response[model] = self.env[model]._load_pos_data_search_read(response, self.config_id)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/addons/point_of_sale/models/pos_load_mixin.py", line 24, in _load_pos_data_search_read
    return self._load_pos_data_read(records, config)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/addons/point_of_sale/models/pos_load_mixin.py", line 55, in _load_pos_data_read
    records = records._filtered_access("read").read(fields, load=False)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 2760, in read
    self._origin.fetch(fields)
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 3062, in fetch
    fields_to_fetch = self._determine_fields_to_fetch(field_names, ignore_when_in_cache=True)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/codebase/odoo/saas-19.3/odoo/orm/models.py", line 3141, in _determine_fields_to_fetch
    raise ValueError(f"Invalid field {field_name!r} on {self._name!r}") from e
ValueError: Invalid field 'removal_strategy_id' on 'product.category'

```

cause:
- field `removal_strategy_id` comes from stock and from saas-19.3 point_of_sale
is not dependent on stock.

FIx:
- correct module should be `pos_stock`

opw-6364126

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

The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty.

Steps to reproduce:
1. Create and pay a POS order with a product that has taxes
2. Go to the backend (Point of Sale > Orders) and open that order
3. Initiate a return for the order
4. In the return order, add a new product (exchange scenario)
5. Observe that taxes are correctly shown on the new line
6. Click Save
7. The taxes disappear from the order line

The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views.


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

Forward-Port-Of: odoo/odoo#261672
Forward-Port-Of: odoo/odoo#253680

**Problem:**
On a planned work order, changing only the start date (e.g. in the planning gantt edit dialog) corrupts the expected duration instead of just shifting the end date. The duration drifts to a wrong value, and in some cases (e.g. dependent work orders) collapses to 0.

**Steps to reproduce:**
1. Plan a work order on a workcenter (start, end, expected duration).
2. Open it and change only the start date to a time that is not on a working-hours boundary.
3. The end date updates, but the expected duration is now wrong.

**Expected behavior:**
Changing the start date replans the work order: the duration is kept and the end date is recomputed from it. This is how 19.0 behaves and how dragging the pill in the gantt already behaves.

**Cause of the issue:**
Changing date_start triggers _onchange_date_start, which recomputes date_finished from start + duration via plan_hours. That cascades into _onchange_date_finished, which recomputes duration_expected from the dates via get_work_duration_data. Since the resource calendar refactor in 19.2, plan_hours and get_work_duration_data are no longer exact inverses around the work order's own planned slot, so the round trip drifts the duration.

**Fix:**
Only recompute the duration when the end date was edited on its own. When date_finished already matches the planned end for the current duration, it was merely derived from the start change, so the duration is kept. This keeps the duration authoritative when moving the work order while still recomputing it on a genuine end-date resize.

opw-6231569

Forward-Port-Of: odoo/odoo#271508

The below test sometimes fail for an incorrect reason and leads to a false 
positive:
https://github.com/odoo/odoo/blob/6dbeac3a42f46b42c638c05aea8285452c944c3f/addons/stock_dropshipping/tests/test_purchase_order.py#L21

Here is another way to reproduce the issue with a higher probability of 
false positive (and it is actually easier to read and understand what the 
test is doing and what's wrong). It needs to edit the following test:
https://github.com/odoo/odoo/blob/ec58c5e12987401659ea0d75d3be2905ad1d807d/addons/purchase_stock/tests/test_create_picking.py#L953
With the below diff:
```diff
--- a/addons/purchase_stock/tests/test_create_picking.py
+++ b/addons/purchase_stock/tests/test_create_picking.py
@@ -965,6 +965,7 @@ class TestCreatePicking(ProductVariantsCommon):
             'price': 500.0,
             'discount': 10,
         })]
+        self.product_id_1.standard_price = 1.0
         po = self.env['purchase.order'].create(self.po_vals)  # create a PO for 5 units
         po.button_confirm()
         with Form(po) as po_form:
```
It will lead to:
```
Traceback (most recent call last):
  File ".../test_create_picking.py", line 976, in test_average_cost_updated_after_po_with_discount
    self.assertEqual(self.product_id_1.standard_price, 450.0)
AssertionError: 1.0 != 450.0
```

Here are the explanations: when receiving an AVCO product, at some point, we 
recompute its standard price. To do so, among several operations, we take 
the last manual update, and we ignore all previous SM:
https://github.com/odoo/odoo/blob/2dbd88657395da965125c8f085da93e04c9c8f0a/addons/stock_account/models/product.py#L463-L465

This is an issue when things are done too quickly. See the pattern:
```py
self.product_a.standard_price = 5.0 # -> define valuation_from_date
po.confirm() # with another cost
receipt.button_validate() # -> define move.date
``` 
In case of a fast execution, both dates will be equal. We therefore ignore 
the SM and rely on the manual update to define the standard price, which is 
not expected. This explains the above `AssertionError`.

Fixing the codebase is quite tricky since the opposite use case could also
happen, aka first processing a receipt and only then modifiying the standard
price.

Tests side, a more important solution should probably be implemented to ease
their redaction and avoid this basic pattern. Yet, a WIP task is changing
the valo for Odoo 20, so the whole logic may change. Second, the current
issue is impacting a lot of builds, so we need to move forward. For both
reason, the commit only "fixes" the current test.

runbot-939955

Forward-Port-Of: odoo/odoo#273078

## Issue
In the attendance view of an employee, a recap of the current extra hours is displayed, showing four values:
1. Total Extra Hours Worked
2. Total Compensable Extra Hours
3. Time Off Taken from Extra Hours
4. Remaining Extra Hours

Each of the above values can be negative but the last one, which can seem odd as it appears to be calculated from the other values.

<img width="299" height="168" alt="6293174-before" src="https://github.com/user-attachments/assets/4377e2fd-f5f2-41a4-a82b-6f2598378499" />

## Steps to reproduce
1. Install *HR Attendance Holidays* (`hr_holidays_attendance`)
2. In Settings, toggle *Absence Management* and *Display Extra Hours*
3. For an employee E:
    - In the Payroll tab, set the Working Hours to the *Standard 40 hours/week* schedule
    - In the Settings tab, set the Overtime Ruleset to the *Default Ruleset*, and toggle the *Give back as time off* action for the *Employee Schedule Rule* rule
4. Create an attendance for employee E:
    - Any day where they are expected to work 8 hours
    - From 10am to 5pm (6 hours with lunch)
5. In the Employees app, go to employee E and click the *Monthly Hours* smart button
6. __In the *Balance* recap above the list of attendances, the *Remaining Extra Hours* row shows 00:00, which seems wrong compared to the other fields above (*Total Extra Hours Worked* and *Total Compensable Extra Hours*) which appear negative.__

## Cause
The `unspent_overtime` (*Remaining Extra Hours* in the balance recap) is computed by adding positive values, making it strictly positive.

https://github.com/odoo/odoo/blob/30c9e8c5b1e34b94c8aab8681e2c051a3b70f013/addons/hr_holidays_attendance/models/hr_employee.py#L62-L65

This was added by https://github.com/odoo/odoo/commit/2144bcfba1ac53c82fc7f2870a72bb13abee97e4, with no justification on why this value needs to be positive.

## Impact on "Time Off taken from Extra Hours"
Before this change, after following the above steps, a value of `-2:00` would be displayed in the *Time Off Taken from Extra Hours* row. This is no longer the case after this fix, since the `'unspent_compensable_overtime'` (*Remaining Extra Hours*) value is used to compute that row:

https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/hr_holidays_attendance/static/src/views/extra_hours_list_view.js#L39-L42

Instead, a value of `00:00` is shown. Before, we were substracting 0 hour of `unspent_compensable_overtime` to the -2 hours of `compensable_overtime`, now we are subectracting -2 hours of `unspent_compensable_overtime` to the same -2 hours of `compensable_overtime`. This is a side effect that was ignored, as it seems to make at least as much sense as showing `-2:00`.

<img width="321" height="179" alt="6293174-after" src="https://github.com/user-attachments/assets/907d5fb8-0c36-4b2e-bca7-1cec41baf22b" />


opw-6293174

Forward-Port-Of: odoo/odoo#273634
Forward-Port-Of: odoo/odoo#271272