Issue:
---
Due to this issue, generating PDF Quote using Quote Builder with dynamic fields leads to a traceback.

This was partially fixed by: e16edc7b0d9f56cb7769068ecf7d64ff8b0f6359

Steps:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quote builder tab, select a document. This document should have dynamic fields. e.g. you could use`Office Furnitures Header` document.
4- Print -> PDF Quote.

Cause:
---
In previous fix, we fixed the traceback when no dynamic field is set. However, if you have a dynamic field, then inside
`PdfWriter._update_field_annotation()`, the font is get from `DR` dict inside acroform:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L917-L929
Even if we are not setting a font, we need to have an empty `DR` dict inside acroform, in order to avoid calling `get` on a none object, which is leading to the traceback.

Also in previous fix we were losing `NeedAppearances` inside `AcroForm` by creating new dict which wasn't right.

opw-6392001

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