The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle more complex use cases.

This commit introduces two changes:

### 1. Removal of `drop_not_null` during auto column conversion
Before https://github.com/odoo/odoo/commit/50767ef90eadeca2ed05b9400238af8bdbe77fb3 We dropped the not_null constraint because the original column would be renamed. After that commit, we actually don't need to drop the not_null constraint since the `convert_column` will neither convert a not-null value to `null` nor convert 'null' to a not-null value. Keeping the not_null constraint shouldn't block the column convert.

### 2. Removal of `column.clear()` 
When a computed/related Float field is changed from `digits=None` to `digits='xxx'`, the `column.clear()` will trigger ORM recomputation during upgrade which is useless since `double precision` to `numeric` is lossless. The recomputation in ORM is slow and should be avoided. If the rerounding is really needed, a sql script is required for upgrade or installation.

The `column.clear()` was originally introduced to avoid `Missing not-null constraint` warnings in specific scenarios:
Case 1 (Upgrade Warning): from saas-18.4 to 19.0
old database: Selection field `l10n_be.export.sdworx.leaves.wizard.reference_year` upgrade: pre-migrate `util.rename_model(cr, "l10n_be.export.sdworx.leaves.wizard", "l10n.be.hr.payroll.export.sdworx")` new database: Integer field `l10n.be.hr.payroll.export.sdworx.reference_year` The column value which was a required stringified integer is auto-converted to an integer.
Case 2 (Installation Warning):
In pos_urban_piper, the required field `pos.config.name` is overridden from `translate=False` to `translate=True`. The column value which was a required text is auto-converted to `'{"en_US": "text"}'::jsonb`

The not_null constraint was previously lost by the `sql.drop_not_null` in `update_db_column` and is not restored by `update_db_notnull` because of the inconsistency between the variable `column['is_nullable']` and the actual not_null constraint in the database.

Thanks to change 1, we will no longer lose the not_null constraint in `update_db_column`. The constraint can be kept even without `column.clear()`.

By removing the `column.clear()`, we also revert the meaning of the `column` variable, which is the column's configuration (dict) before `update_db` if it exists, or `None`

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#236299

**Steps to reproduce:**
- In the config, click the ePos Printer checkbox
- Also check Automatic Receipt Printing and Skip Preview Screen
- Put a default preset with Name as it's identification
- Go in the restaurant and make a sale, pay for it
- When going back to the floor plan, a traceback appears

**Why the fix:**
This current problem arises because we are trying to access the current order, but we are on the floor plan, so there is no current order yet. The order is undefined, so we try to access *undefined.floating_order_name* and a traceback appears.

But the root issue is deeper than this. In the restaurant, the order is initialized when clicking a table, or when we create a floating order. But when the Skip Preview Screen option is enabled, we try to initialize the order right after the last order has been validated, like we do it in the normal PoS.

Doing this, we will try to handle the preset selection way too early, as the order is not fully initialized yet, and we will try to access data that have not been set yet.
The current error is not the only one we have with this setup, as other errors also arise if we bypass this specific error.

To fix this, we are now only initilizing the new order when we click on a table that has no order or when making a floating order. We do not create a new order after the validation of the last one, even if the Skip Preview Screen option is enabled. This is only true in the restaurant, as we keep on initializing a new order after the validation in the regular PoS.

Before this commit, we also tried to create a new order when opening the restaurant from the frontend (see image below), which resulted in a traceback.
We now only create a new order if the default screen is different from the Floor Screen.
<img width="375" height="249" alt="image" src="https://github.com/user-attachments/assets/e38520f6-81e2-471e-a987-98d9426a6493" />

Starting in version 19.0, there is another waiting screen after paying and before going back to the floor plan, which handles things, so the bug is not present anymore. But the traceback we get when opening the register from the frontend is still present in future versions.

opw-5131309

### Steps to reproduce:

- Create a storable product
- Create a receipt for 100 units of that product
- Mark as to do, set the quantity to 50 and validate without backorder
- Go to your product form > Forecast
#### > The forecast displays a quantity of -50 for every date in the past

### Cause of the issue:

The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant.

#### Note:

The same issue happen if you receive more than the demand. That is:
- Mark as to do, set the quantity to 150 and validate without backorder
- Go to your product form > Forecast
#### > The forecast displays a quantity of 50 for every date in the past

The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would:
- in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand.
- in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move.

This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact.

opw-5152570

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

Forward-Port-Of: odoo/odoo#234576

__Before this commit:__
1. Add a 2nd language to your site
2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page)
3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state.

__Cause:__
Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A.

__The fix:__
Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead.

NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway.

[1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33
[2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54

task-5125700

**Steps to reproduce:**

1- Install the purchase_stock module.
2- Create a new PO with a new vendor.
3- Add new one product in the purchase order line with quantity > 1.
4- Confirm the PO and go to the generated receipt.
5- Validate the receipt with less than the ordered quantity, by choosing no
   backorder.
6- Duplicate the receipt for the remaining quantity and validate it.
7- In vendor form view, the On-time Rate value shown in the smart button differs
   from the value in the graph.

**Issue:**
https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42

- The On-time Rate shown in the smart button does not match the graph.

**Example:**

- PO Line ordered qty: 10  
- First receipt validated: 6 (no backorder)  
- Duplicated receipt validated: 4  
- In vendor form view inside On-time Rate Smart button
- Total quantity coming: 14 (incorrect)  
- Expected total qty for calculation: 10 (from PO line)  
- On-time delivery rate calculated: **71.43%**  
- Expected On-time delivery rate: **100%**

**Cause:**

- The report uses `product_qty` from the stock move.  
- When a receipt is duplicated and the demand quantity is manually set, 
`product_qty` is recomputed from this demand value.  
This leads to a mismatch between the PO line quantity and the aggregated stock 
move quantities.

**NOTE:**
In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line::
`purchase_order.order_line.flush_recordset()`

- Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field.
- The computed value first lives in Odoo’s cache.
- It is not written to the database until a flush occurs.
- If we immediately call something like _read_group() (which queries the database directly), 
it won’t see the cached value — only what is persisted in the DB.

**Solution:**

- Use the purchase order line quantity instead of the stock move’s `product_qty` 
to ensure consistent and accurate On-time Rate calculation.

opw-4991367

Forward-Port-Of: odoo/odoo#236779
Forward-Port-Of: odoo/odoo#225529