Steps to reproduce:
1. Install `account_reports` and set fiscal year beginning date for Tax returns.
2. Open Tax Report from the button on Kanban view of account return.
3. Try to refresh from the report page. Without debug mode, it will return to returns kanban view and with debug mode, it will go back and a traceback will appear.

Cause:
The report from kanban view is opened via a python action method, which returns a `ir.actions.client` of `account_report`. In the controller for report, it tries to fetch the `report_id` from `context` [[1]] set during the python method call.
But when we refresh page, this action context is wiped out, so when it tries to get the report options in controller via orm call [[2]], the report_id is lost, and it causes traceback.

Solution:
This commit tries to get the `report_id` from `action stack` which is prepared based on the url. so it fetches the correct report via ORM call.

[1]: https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/static/src/components/account_report/controller.js#L23
[2]: https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/static/src/components/account_report/controller.js#L167

task-6240800

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Description of the issue/feature this PR addresses:

This error occurs when a model has properties and a `computed` field or `onchange` method depends on them.

`record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211

However, `PropertiesField` is rendered before the `update` is completed. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86

As a result, the property labels are not yet available and the following traceback is raised:

`TypeError: Cannot read properties of undefined (reading 'getRootNode')
`
After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available.

**Steps to reproduce:**

1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip)
2. Open or create a project task.
3. From the Action menu, click `Add Properties`.

The error is raised.

<img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" />


TT63331
@Tecnativa @pedrobaeza

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

Forward-Port-Of: odoo/odoo#271894
Forward-Port-Of: odoo/odoo#271082

**Step to Reproduce:**

1. Open the POS.
2. Add any product to the order.
3. Proceed to the payment screen and select `Pine Labs` as the payment method.
4. Observe that the Pine Labs terminal does not respond and no payment popup appears on the device.
5. Wait until the payment request is cancelled (either manually or due to timeout).
6. Click the `Force Cancel` button.
7. Observe that the POS throws a traceback.

**Video:**
https://drive.google.com/file/d/1A3QPdby-J12IWgOX_SfCLrauQ_QnbqvG/view

**Issue:**

When a Pine Labs payment request is cancelled (either through a cancel request or by timeout), clicking the `Force Cancel` button results in a traceback in
 the POS.

**Reason:**

During the cancellation flow, the payment line status is updated to `retry` so that the transaction can be marked as cancelled and retried if necessary.

Later, when the user clicks `Force Cancel`, `_paymentCancelRequestHandler()` attempts to retrieve the pending Pine Labs payment line using:

```javascript
const line = this.pendingPineLabsPaymentLine();
```

However, `pendingPineLabsPaymentLine()` only returns payment lines whose status is not `retry`, as defined here:

https://github.com/odoo/odoo/blob/19.0/addons/point_of_sale/static/src/app/services/pos_store.js#L1820

Since the payment line was already transitioned to the `retry` state during the cancellation flow, no `payment line` is found and `line` becomes `undefined`.

The handler subsequently attempts to update the status of this `undefined` `payment line`, resulting in the traceback when `Force Cancel` is executed.

**Solution:**

Add a condition in `_paymentCancelRequestHandler()` to verify that a payment line is available before attempting to update its status.

If no payment line is found, it indicates that the payment line has already been
 moved to the `retry` state during a previous cancellation attempt. In such
cases we clear `pollingTimeout`, `inactivityTimeout` and reset `this.payment_stopped` to `false`.

This prevents the traceback while ensuring that the `Force Cancel` flow properly cleans up the pending payment state.

opw-6297135

Forward-Port-Of: odoo/odoo#271397
Forward-Port-Of: odoo/odoo#271241

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

Description of the issue/feature this PR addresses:

The actual XML extraction hardcoded the double-zipped case by reading only
   the first entry of the outer zip (`zip_file.infolist()[0]`), assuming it
   was always a nested zip containing the XML.

This made it fail when:
- The XML was directly in the outer zip (single-zipped).
- The zip contained multiple files and the first nested zip didn't hold the XML.

Current behavior before PR:
After sending an Invoice to Viettel S-Invoice, the e-Invoicing platform would return a ZIP containing one XML file.
The XML File being double-unzipped, a traceback is raised.

Desired behavior after PR is merged:

The fix rewrites _recursive_zip_xml_file_data to actually be recursive. Invoices can be sent to Viettel S-Invoice without raising a traceback.

opw-[6249929](https://www.odoo.com/odoo/project.task/6249929?debug=1)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272121
Forward-Port-Of: odoo/odoo#268482