Steps to reproduce:
-------------------------
1. Install the Accounting module.
2. Create and confirm a Vendor Bill.
3. Click on Pay and create a payment for the bill.
4. Open the created payment using the smart button.
5. Delete the payment or click on Reset to Draft.


Observation:
-------------------------
1. On deleting the payment:
The Vendor Bill still shows the "In Payment" status even after the payment is
deleted.
2. On resetting the payment to draft:
The Vendor Bill also remains in the "In Payment" status instead of reverting to
"Not Paid".

This behavior is not observed for customer invoices, where the payment state
updates correctly in both cases.


Issue:
-------------------------
1. Delete case:
In the `unlink` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945
the `linked_invoices` variable only includes invoices that are reconciled
(i.e., their journal items are matched). Since the Vendor Bill is not yet
reconciled, it is excluded from recomputation. Hence, its `payment_state`
remains unchanged.

2. Reset to draft case:
In the `_compute_payment_state` method,
https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163
the compute depends on the state of reconciled payments. However, since these
payments are not reconciled, the compute method is not triggered, and the
payment state remains outdated.


Solution:
-------------------------
Added `matched_payment_ids.state` in the depends of the
`_compute_reconciled_payment_ids` method to ensure it recomputes correctly when
payment state changes on setting payment to draft or deleting payment

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

Forward-Port-Of: odoo/odoo#234725

Steps to reproduce:
-------------------
1. Install `base_automation` and `project`
2. Create a new task with a deadline set to today
3. Create a new automation rule using the operator "today"
4. Set the trigger to "Based on datetime field" using the `deadline` field
5. Add a filter domain based on the same operator
6. Run the related scheduled action (cron) for automation rules

Issue:
-------
During cron execution, the automation silently fails with the error:
```python
NameError: name 'context_today' is not defined
```

Cause
-----
Most of the Time-based domain operators are [introduced from SaaS-18.3 ](1c7c31a)onwards
and include values such as [context_today()](https://github.com/odoo/odoo/blob/0a6155ac25aae138bdaa5e2e8a6d39c42acd2fe3/addons/web/static/src/core/tree_editor/condition_tree.js#L84) and `.to_utc()`, which are not present in the Python evaluation context.
As a result, safe_eval raises NameError, and the automation rule is never triggered.

Solution
--------
Prepare the evaluation context with time-based operators and remove
unsupported JS-only `.to_utc()` before evaluating the domain in Python's safe_eval, to prevent traceback.

opw-5237215





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

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#93378

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

Forward-Port-Of: odoo/odoo#237333
Forward-Port-Of: odoo/odoo#236454

A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.

So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.

Steps:

1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`


We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.  

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

Forward-Port-Of: odoo/odoo#234987
Forward-Port-Of: odoo/odoo#231981