Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#235502
Forward-Port-Of: odoo/odoo#225014

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#227643

After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape.

Steps to see the issue:
- Open website and start editing
- Drop a text-image snippet onto the page.
- Then add a hover effect to the snippet image.
- Open the image shape selector and hover over the shapes.

=> Bug: the preview is broken; when the mouse leaves a shape, the original shape is not reset.
Same issue with other options when there is a hover effect on an image (e.g. "image Filter").

Current flow is:
We are previewing shape -> img src is changed -> `originalImgSrc` in `ImageShapeHoverEffect` interaction is changed -> we revert preview -> img src is reverted, but MutationObserver doesn't change `originalImgSrc` immediately, and when reverting a step, we stop the interaction -> destroy is called and image source is set to `originalImgSrc`, but it is the old one with a shape. We want to update the `src` only if it is currently the one that we set as hovering.

[commit]: https://github.com/odoo/odoo/commit/80b5db99a3c26c3dd4fb5c55e04b8813dddb5b8d

task-5207382

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Forward-Port-Of: odoo/enterprise#99855
Forward-Port-Of: odoo/enterprise#93841

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

During the rework of the follow-up report, we removed the
"No Follow-Up" field from journal items, making it impossible to exclude
individual journal items from triggering a follow-up.

In this commit we do the following:
-  Re-introduce a field for that, since it is a common
   requirement to be able to exclude individual items from the follow-up
   reports.
   The field is stored on the journal item, but can also be toggled from
   the journal entry. In case of multiple installments on the invoice,
   toggling the field on one installment will toggle it for all
   installments.
-  Adapt the Follow-Up Report and Customer Statement variants of the
   Partner Ledger to add a toggle for the "No Follow-Up" field on each
   report line, that toggles the field on the corresponding journal
   item(s).
-  Prevent the follow-up status on the partner to change when all of the
   overdue journal items are marked as "No Follow-Up".
-  Make sure users can toggle the "No Follow-Up" setting on the invoice
   level when opening the "Overdue Invoices" view from the partner's
   "Accounting" tab.
-  Make sure all receivable/payable lines without a due date (either
   from a manual miscellaneous entry or a PoS entry) are put under the
   "Due" section in the Follow-Up Report instead of the "Overdue"
   section. Since there is no due date, they can't be overdue.
-  Make sure the PDF and XLSX exports of the Follow-Up Report don't
   include the "No Follow-Up" lines, and the customer follow up email
   only includes the amount of the other lines.

Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9
and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615
Task: 5138378

Upgrade PR → https://github.com/odoo/upgrade/pull/8864

Forward-Port-Of: odoo/enterprise#96627

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

Steps to reproduce:
===================
1- Website app > Open any page in Edit mode.
2- Drag a Video block into the page.
3- Paste a Vimeo video URL in the dialog and save. 
4- Save the page, then re-open it in Edit mode.
-> traceback

Cause:
======
The Wysiwyg "openMediaDialog" passes the selected media DOM node as "media" to the MediaDialog.
The MediaDialog forwards that value as "media" prop to VideoSelector. VideoSelector declared "media" as "{ type: Object, optional: true }". Owl validates "type: Object" as a plain object, not as any "typeof object".
DOM elements such as HTMLImageElement do not pass this plain object check, so Owl raises an error.

Solution:
=========
Relax the "media" prop type in VideoSelector so DOM nodes are accepted. In web_editor VideoSelector, change the "media" prop to "{ optional: true }".
In html_editor VideoSelector, also keep "media" declared as "{ optional: true }".

opw-5239889

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

Forward-Port-Of: odoo/odoo#236296

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#235502
Forward-Port-Of: odoo/odoo#225014

Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key.

BEFORE:
Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC)

NOW:
Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour.  

Note:
I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4
as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different)

task#4629641

Forward-Port-Of: odoo/enterprise#99855
Forward-Port-Of: odoo/enterprise#93841

### Issue

Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).

### Analysis

Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.

### Solution

Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.

For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.

### Benchmarks

Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types

| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |

### References

opw-5130725

Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions:
- sign.template with signature/initials fields and more than one role
- more than one sign user (internal user)

```
  File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 341, in _compute_only_autofill_readonly
    not (item.type_id.name == 'Signature' and request._get_user_signature(user, 'sign_signature')) and
                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 323, in _get_user_signature
    return user[signature_type]
           ~~~~^^^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 6680, in __getitem__
    return self._fields[key].__get__(self)
           ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/fields.py", line 1646, in __get__
    record._check_field_access(self, 'read')
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 3426, in _check_field_access
    raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
```
This commit ensure that we don't try to access the signature/initial field of another user when it is not necessary.

task-5271648

Steps to reproduce:
--------------------
1. Install helpdesk_timesheet
2. Create a new team with timesheets enabled
3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours)
4. Open the team’s settings and observe the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the team’s settings and observe the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
------
After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed.

Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36

For ex:
Consider unit_amount = 20 minutes:

**Before**
Case 1: Encoding method = Hours/Minutes
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 1 = 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
(unit_amount_sum / product_uom.factor) * uom_team.factor
(20 / 1) * 8 = 160 Days --> INCORRECT

**After**
Encoding method = Days/Half-days
(unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor
(20 * 1) / 8 = 2.5 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

**NOTE:** 
Before this change, when the user opened the timesheet sublist view in debug mode 
and clicked the View button, it opened the default form view of the `account.analytic.line` 
model instead of the intended timesheet form view. 
This allowed editing of the Unit of Measure (product_uom_id) field also.

To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41).

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related community PR: https://github.com/odoo/odoo/pull/233803

Forward-Port-Of: odoo/enterprise#98545

Steps to reproduce:
--------------------
1. Install hr_timesheet
2. Create a new project and a task
3. On the task, add a timesheet line with some time (e.g., 20 hours)
4. Open the project dashboard and check the Timesheets stat button
5. Go to Timesheets > Configuration > Settings
6. Set "Encoding method" to "Days/Half-days"
7. Reopen the project dashboard and check the Timesheets stat button again

Issue:
------
Incorrect value displayed in the Timesheets stat button.
(e.g., 160 Days instead of 2.5 Days)

Cause:
-------
After this 28b69da, UoM model got restructured and the conversion logic between hours and days changed.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143

The `total_timesheet_time` value is now already stored in the final unit (e.g., days). The subsequent division in `_get_stat_buttons()` was a redundant **double conversion**, resulting in incorrect display.
https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L231-L234


**Before**
Case 1: Encoding method = Hours/Minutes
Consider allocated_hours = 80 Hours,
total_timesheet_time = 20 Hours

Then:
uom_ratio = 1/1 => 1
allocated = 80/1 => 80 Hours
effective = 20/1 => 20 Hours --> CORRECT

Case 2: Encoding method = Days/Half-days
Consider allocated_hours = 80 Hours,
total_timesheet_time = 2 Days (already in days — no conversion needed, but the system incorrectly tries to convert it)

Then:
uom_ratio = 1/8 => 0.125
allocated = 80/.125 => 640 Days
effective = 2/0.125 => 16 Days --> INCORRECT

**After**
Consider allocated_hours = 80 Hours (needs conversion to days as per encoding method)
and total_timesheet_time = 2 Days (already in days, no conversion).

Then:
uom_ratio = 1/8 => 0.125
allocated = 80*.125 => 10 Days
effective = 2 => 2 Days --> CORRECT

Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed.

Solution:
----------
This commit ensures accurate conversion of timesheet values between hours and days

opw-5184077

Related enterprise PR: https://github.com/odoo/enterprise/pull/98545





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

Forward-Port-Of: odoo/odoo#233803

This PR consolidates multiple fixes and improvements across **account**, **sale_management**, and **sale** to make the section widget more internally consistent.
It addresses visibility rules, optional section logic, resequencing behavior, and some configurator quirks.

---

### **1. Section Widget: Hide Prices / Hide Composition Logic**

* Subsections under a hidden section now correctly disable both *Hide Prices* and *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices, but may still hide composition.
* Mutually exclusive states: a section cannot have *Hide Prices* and *Hide Composition* active at the same time.
* Resequencing a subsection under a *Hide Composition* section resets all its state flags.
* Removed confusing buttons:

  * “Add a Section” inside a section
  * “Add a Subsection” inside a subsection

---

### **2. Optional Section Behavior (sale_management)**

* Optional sections and subsections cannot activate *Hide Prices* or *Hide Composition*.
* Subsections under a *Hide Prices* section cannot hide prices or become optional (but can hide composition).
* Resequencing into a section with *Hide Composition* resets all child states to `false`.
* New lines inside optional sections default to quantity **0**.
* Setting a section as optional resets all nested `collapse_*` states.

---

### **3. Resequencing Logic for Optional Sections**

Improved behavior when moving sections and lines:

* **Quantity rules**

  * Moving a line **into** an optional section → qty → `0`
  * Moving a line **out** of an optional section → qty → `1`
  * Same logic applies when moving entire sections that change which lines fall under them.

* **Recalculation rules**

  * Moving a section **up**:

    * Recompute all lines under the moved section.
    * Recompute all lines between old/new positions.
  * Moving a section **down**:

    * Recompute all lines under crossed sections.
    * Recompute all lines between old/new positions (excluding overlaps).

---

### **4. Combo Line Move Fix (sale)**

* Unsaved combo lines were missing *Move Up/Down* due to `virtual_id` not being considered.
* Updated logic to include `linked_virtual_id` so combos can be moved even when unsaved.

---

### **5. Other Fixes**

* Made dynamic conditional labels translatable (Hide/Show Prices, Hide/Show Composition, Set/Unset Optional).
* Updated the relevant XPath introduced in earlier commits.
* Removed an archived product from quotation template demo data.
* Added mobile UI controls for section toggles (`collapse_prices`, `collapse_composition`, `optional`).
* Configurator adjustments for optional-section products:

  * Hide quantity controls, price, and total.
  * Added products default to qty `0` inside optional sections.


See Also:
- https://github.com/odoo/enterprise/pull/99188

task-5082193

### Issue:

Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.

### Steps to reproduce:
- Create a kit product with a kit BOM:
    - 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation

### Cause of the issue:

Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does,  the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921

### Fix:

In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.

opw-5100026

Forward-Port-Of: odoo/enterprise#99845
Forward-Port-Of: odoo/enterprise#98589

Problem
--------

In v18.0, the day billing period was removed from the sale.subscription.plan model.

For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance.

However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value.

- Screenshot Order with plan Daily: 
<img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" />

- Screenshot when trying to get in order on the website: 
<img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" />


Proposed Solution
--------

This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list.

The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection).

This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance.

- 
<img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" />

Issue
-----
Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored.

E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.

Steps to reproduce
-----
- Have 2 products
- Create a MO for product 1 with a WO at work center 1, plan it
- Create a MO for product 2 with a WO at work center 2, plan it
- Got to Manufacturing, Planning, Planning by Work Center
- Add a custom group (by product)
- Drag the WO of WC2 and drop it on top of the other WO

> Both the WC and the product of the second WO change

Cause
-----
The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored.

https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34

While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored.

More broadly, gantt views should not ignore the `readonly` attribute of fields.

Solution
-----
Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly.

When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop.

-----
Ticket:
opw-4875366

Forward-Port-Of: odoo/enterprise#94166

### 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

**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