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

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

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

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

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