### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Processing the backorder wizard will create and confirm moves for the backorder picking:
https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1916-L1919 However, as these moves are `make_to_order` they are planned to create and run procurements in their respective `_action_confirm`'s: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1379-L1388

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

Forward-Port-Of: odoo/odoo#209924
Forward-Port-Of: odoo/odoo#209442

The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary.

Steps to reproduce:
---
- Install `Gamification` and `hr_appraisal` modules
- Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `Appraisal Goal`, `Field to Sum` -> `Created on (Appraisal Goal)`, `Filter Domain` -> `[]`
- `Start Challenge` in Gamification Challenge

Traceback:
---
```
UndefinedFunction
function sum(timestamp without time zone) does not exist LINE 1: SELECT SUM("hr_appraisal_goal"."create_date") FROM "hr_appra...
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
```

To fix this, we now check the field type before applying aggregation. If the computation mode is set to `sum` but the field is not numeric, we gracefully fallback to using `count` instead. This prevents SQL errors and ensures that goal computations remain reliable even with misconfigured definitions.

sentry-6575130734

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

Forward-Port-Of: odoo/odoo#208077

### Steps to reproduce:
	- Navigate to Recruitment > Job Position > Any job position > Job applications (smart button)
	- Create an applicant
	- Set a Recruiter for the applicant
	- Move the stage to 'Contract Signed'
	- Click on 'Create Employee'
	- Notice a validation error that the opertion cannot be completed

### Cause:
This is happening as the 'Job applications' smart button has default value for the user_id in context

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr_recruitment/views/hr_job_views.xml#L207-L211

so when creating an employee it will add the missing fields from defaults and it will get the default value in the context which for an existing user so when creating the employee with this user_id it will trigger the sql constraint

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr/models/hr_employee.py#L145-L148

### Fix:
clean the context before creating the partner and the employee corresponding to this applicant

opw-4629219

Forward-Port-Of: odoo/odoo#210806
Forward-Port-Of: odoo/odoo#204997

**Steps to reproduce:**
1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` .
2. install website module.

**Issue:**
Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload.

**Reason:**
The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.act_url, which triggered a full page reload, ensuring the server route executed.
From Odoo 16 onwards, this action is removed, and a direct client action is attached. Within `configurator.js`, navigation is now handled using the `history.pushState` method which replace the current url and does not trigger a reload. As a result, even when navigating to the configurator route, the server route is not executed, leading to incorrect redirection.

**Fix:**
Added a check in configurator.js to verify the configurator status. If it is true, the user is redirected to the website page instead of the configurator. Otherwise, the normal configurator flow continues.

**Key Changes:**
1. In configurator_init, added a check: if configurator_done is True, set the default theme using button_choose_theme and store its result (a dict containing the next action to execute) as redirect_url.
2. In the Configurator component, added redirect_url to the store, and inside the onWillStart method, checked if redirect_url exists. If it does, redirect to the home screen using doAction.

This PR ensures the correct redirection behavior when users follow the Industries installation flow.

task-4555467

Forward-Port-Of: odoo/odoo#197593

Scenario:
- create an object_write (Update the Record) action
- update a field with equation evaluation (Python expression) with an
  expression like "record.id"
- click on "Create contextual action"
- go to a list view of the model, execute the action for several records

Result: the value of the field of all records are computed based on the
first selected record.

Issue: we don't change the "record" in the evaluation context and just
keep the first record.

Fix: changing the record.

Note: without the fix, the added test fails because the city of the
second record is set to the value of the ID of the first record.

opw-4491099

__PR code note__:

I did the change in "run" but this could be done in `_run_action_object_write`, I chose run because we are already changing the action_id in it.

The "`if eval_context.get('record') is not None`" is to not change an hypothetical case where `self.model_id` doesn't match the `context.action_model`.

__PR note__:

If it was too risky, we could probably merge in an higher version, the ticket is in 17.0 and this is still happening in master.

I've not heard of this issue before so this must not be very frequent or urgent, but I guess this is because people either use a python constant or they just use a python action with a for loop in general.

Forward-Port-Of: odoo/odoo#211122
Forward-Port-Of: odoo/odoo#210855

Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand.

### Steps to reproduce:

- Create a storable product. Put 5 units in stock.
- Create a delivery order for 5 units and mark as to do.
- Go to the barcode app and edit your delivery order.
- Click on the pencil and set a qty of 1 > Confirm
- Click back on the pencil and reset the quantity to 0 > confirm
#### > On the picking, the demand of the line was edited from 5 to 1.

### Cause of the issue:

Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive):
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045

### Fix:

Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed.

opw-4700996

Forward-Port-Of: odoo/enterprise#85003
Forward-Port-Of: odoo/enterprise#83623