**Steps to reproduce:**
* Install the **Manufacturing** module with **Work Orders** enabled.
* Create and confirm a Manufacturing Order with at least one Work Order.
* Open the **Shop Floor** view.
* On a work order card, click the **gear** icon to open the menu dialog.
* Click **Open Manufacturing Order** on a slow network connection.
* Before the MO form view finishes loading, quickly click the **gear** icon again and open another dialog (e.g. Log Note).
* The MO form view loads, destroying the shop floor component.
* Close the Log Note dialog.

**Observed behavior:**
* An `UncaughtPromiseError: Component is destroyed` error is thrown because the dialog tries to interact with the shop floor component that has already been destroyed by the navigation to the MO form view.

**Cause:**
* When the user clicks "Open Manufacturing Order", `doAction` is called to navigate to the MO form view, and `props.close()` immediately closes the menu dialog. However, the shop floor component is still visible while the new view is loading.
* During this gap, the gear button remains clickable. If the user opens another dialog (e.g. Log Note), that dialog holds a reference to the shop floor component. When the MO form view finishes mounting, the shop floor is destroyed, and closing the stale dialog triggers operations on the destroyed component.

**Fix:**
* Add an `actionPending` state flag to `MrpDisplayRecord`. When the user selects "Open Manufacturing Order" from the menu dialog, an `onSelect` callback sets `actionPending` to `true`, which disables the gear button and prevents any new dialog from being opened.
* The flag is only set for `openMO` (which navigates away and destroys the component), not for other menu actions like Scrap, Add Component, or Log Note which open wizard dialogs and return to the shop floor.

opw-6107579

This reverts commit 77280860a3a3557619ac13c853c37a66e9d19f2e.

The reverted commit removed the second cac:TaxTotal node (in company currency, without tax subtotals) whenever the invoice currency matched the company currency (SAR), based on the assumption that it was an optional node only needed for foreign-currency invoices.

This is wrong. Business rule BR-KSA-EN16931-09 is currency-agnostic: it requires exactly one TaxTotal without subtotals whenever cbc:TaxCurrencyCode is present in the document, regardless of whether the document and tax currencies match. Since l10n_sa_edi always sets TaxCurrencyCode, the second TaxTotal node is always required, even when both TaxTotal amounts end up identical (which is normal and expected for a same-currency invoice).

ZATCA's own official "Standard Invoice" sample confirms this: a plain SAR invoice (DocumentCurrencyCode = TaxCurrencyCode = SAR) contains two TaxTotal nodes with the same TaxAmount.

After the reverted commit was deployed, ZATCA started returning:

[202] BR-KSA-EN16931-09 : Only one tax total (BG-22) without tax subtotals (BG-23) must be provided when tax currency code is provided.

opw-6409881

Forward-Port-Of: odoo/odoo#284676

On a virtual keyboard the editor handles typing as a composition and only commits its history step on a later interaction. The html field marks itself dirty from that step, so right after typing the field is not dirty. On save the form calls commitChanges, but it only writes the value when the field is dirty, or on an urgent or inline-style save. None of those hold for a plain sanitized html field, so the typed content is not written to the record.

Finalize the pending composition in commitChanges by calling the editor _compositionStep() before that check. commitChanges is the single point every save path goes through, so committing the pending step there marks the field dirty and the content is saved. It does nothing on a physical keyboard, where the composition flag is cleared after each keystroke.

Steps to reproduce:
1. Open the Sales app and a quotation.
2. In the chatter, click Activities then Schedule Activity.
3. On a phone, or a browser with a virtual keyboard, fill Summary, tap the note field and type a note.
4. Tap Schedule while the note field still has focus.
5. Open the created activity.

=> the note is empty

Ticket [link](https://www.odoo.com/odoo/project.task/6331719)
opw-6331719

Forward-Port-Of: odoo/odoo#274465

**Problem:**
Creating an accrual allocation for a whole company, a department or an employee category, with a plan that started in the past, does not grant the employees the days they should already have accrued. Doing the same allocation employee by employee works.

**Steps to reproduce:**
1. Create a monthly accrual plan (e.g. 2 days, gained at the end of the period)
2. Create an accrual allocation for a whole company/department with a start date a few months in the past, and validate it
3. Observe each employee only gets the current period

**Current behavior:**
The child allocations only get the current period; the backlog between the start date and today is lost.

**Expected behavior:**
Each employee is back-filled for every elapsed period, exactly like a single-employee allocation.

**Cause of the issue:**
The single-employee flow runs `_onchange_date_from`, which resets `lastcall` to the allocation start date so `_process_accrual_plans` back-fills every elapsed period. That onchange returns early when there is no `employee_id`, which is always the case for company/department/category allocations, so the parent's `number_of_days` preview stays 0. The per-employee children are then created through `create`, where `_add_lastcalls` sets `lastcall` to the current period; the subsequent accrual run therefore only grants the current period and drops the whole backlog.

**Fix:**
Restart the child accrual from the allocation's start date before processing it, the same way the single-employee onchange does, so the plan is evaluated period by period for every employee. This is scoped to company/department/ category modes because employee-mode multi allocations already carry the value computed on the parent and must keep it.

opw-6308064

Forward-Port-Of: odoo/odoo#272152

Current behavior:
--
With an active automation rule (base_automation) whose action creates an activity (e.g. a "Time Off Approval" activity) on hr.leave creation, every newly created time off request has a duration of 0 days / 0 hours, regardless of the requested dates.

Expected behavior:
--
The leave duration is computed from the requested dates, unaffected by the presence of an activity-creating automation rule.

Steps to reproduce:
--
- Create an automation rule on hr.leave, trigger "On Creation & Update".
- Add an action that creates an activity (type "Time Off Approval").
- Create any time off request for an employee with a working schedule.
- The request shows a duration of "0 days" (or "0 hours").

Cause of the issue:
--
When an automation with a "Create Activity" action runs on leave creation, base_automation schedules the activity after the record is created. Creating the activity reads the leave record, forcing an early flush of its pending computes. At that point date_from/date_to are not yet settled, so the duration compute (number_of_days/number_of_hours) reads empty dates and stores (0, 0). As these are stored fields, they are marked done and never recompute.

Fix:
--
In create(), after the record is created and its dates are settled, recompute the duration explicitly so any zero stored by an early flush is overwritten with the correct value.

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