When viewing sale report for POS orders, the gross weight number will
be off by a factor of how much larger/smaller the UOM ratio is
compared to the base. For example, if we sell 1 qty of product with a
weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field
will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or
25kg. This fix removes the UOM factor from being taken into account
when calculating gross weight for POS orders. This is a valid solution
because if we treat 'SUM(p.weight * l.product_uom_qty / u.factor *
u2.factor)' as the ground truth from sale report for sale orders, the
'/ u.factor * u2.factor' portion of the calculation will cancel out
to 1 for POS orders. This is because the only time 'u2.factor/u.factor'
is not 1 for sale orders is when the product template's UOM factor is
different from the sale order line's UOM factor. Since we can not
change the UOM of pos order lines, the pos order line's factor will
always be the same as the product template's therefore
'u2.factor / u.factor' for pos orders will always be 1 and can be
ignored.

To reproduce error on blank DB:
1) For a product, change its UOM to a UOM with a ratio not equal to 1
2) For the same product, change its weight in the inventory tab to
a number not equal to 0
3) In POS make a sale with this product and confirm the order
4) Check the gross weight of the product just sold through POS by
going to sales->reporting->list view and adding gross weight to the
view through studio

opw-4452892

Forward-Port-Of: odoo/odoo#203700
Forward-Port-Of: odoo/odoo#203144

[FIX] web_editor: translate paragraph links as a whole.

Steps to reproduce:

1. Enable a second language in the website (e.g., French).

2. Add a "Text" block (in edit mode) > Save the page.

3. Translate a text paragraph to french > Save.

4. In edit mode again, add a link to a word in the paragraph > Save.

5. The translation in French is lost, and sometimes the whole French
   translation is used for the text before or after the link.

This is actually a limitation in the translation implementation. If we
initially have `text_1_en text_2_en text_3_en` translated to French this
way:

terms en_US: `["text_1_en text_2_en text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

After adding a link: `text_1_en<a...>text_2_en</a>text_3_en`, and since
the links are not translated as a whole, we should get:

terms en_US: `["text_1_en", "text_2_en", "text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

Which means the current translation will be lost, and the result will
depend on the outcome of `get_close_matches()`. Which explains why when
the link is added to the first words of the paragraph, the system still
maps the rest of the paragraph to its "full old translation".

The goal of this commit is to make this behavior less aggressive by
forcing the links added in paragraphs [1] to be translated as a whole.
This way, the `get_close_matches()` will map the new content with a link
to its old translation (without a link), and then, the user can set the
link in the "the most meaningful part of the translation" in the
translate mode.

[1]: We should use the "translate as a whole" feature carefully with
links, since there are already some situations where it's causing
issues (see the fix in [2]). So we only force them inside paragraphs.

[2]: https://github.com/odoo/odoo/commit/9bd60ca93510e410a0136b8b433f596330900593

opw-3984439

Forward-Port-Of: odoo/odoo#179167

Versions
--------
- 17.0+

Steps
-----
1. Have a rental product with a minimum rental duration of 1 day;
2. open its eCommerce page;
3. select two days in the rental period datepicker;
4. go to cart;
5. go back to the product page and refresh.

Issue
-----
The product is displayed with a rental period of 3 days.

Cause
-----
Commit 0573ad5 attempted to add a timezone correction when retrieving DateTime values from the server. When duration isn't with hours, it gets the `startOf` of the start datetime, and the `endOf` of the end datetime as a means of converting datetimes to dates.

This only works correctly if the parses datetime value was serialized with a timezone value. This was already done for the default start dates passed to `combination_info`, but not when retrieving date fields from a current sale order.

Solution
--------
Use the `_get_localized_renting_dates` method in the template to get the relevant date values with the correct timezone offset.

opw-4583312

Forward-Port-Of: odoo/enterprise#82353

## How to reproduce the issue:

- In the Gantt view of the **All Tasks** view in **Project**, create a new task with allocated hours.

- Set the task to last **at least two days** and set its **end date** between **12:00 AM and 3:00 AM** (or its **start date** between **9:00 PM and 12:00 AM**).

Instead of displaying the **task name**, the **display name** shows the **start and end times**.

This happens because if a task **spans across days** but its start/end time is within **3 hours of midnight**, the display name includes the **start and end time** in the **week and month scale view**.

Commit https://github.com/odoo/enterprise/commit/1713de228c772e43d756f068dc8b7258e3299af0 introduced a fix via `spanAccrossDays` to display the **start and end times** for tasks (shifts) where the **startDate** or **endDate** falls within **3 hours of midnight**. If `spanAccrossDays` is **false**, then the pill display name is the **start and end time** in the **week and month scale view**. However, this behavior also applied to tasks spanning more than two days.

After this commit, if the pill **spans more than two days**, the pill name will only be the **task name**:

- **Example 1:**

**Start:** *01/01/2025, 4 PM*, **End:** *02/01/2025, 1 AM* → **Display name: Start/End Time - Task name** (since the end time is before 3 AM).

- **Example 2:**

**Start:** *01/01/2025, 4 PM*, **End:** *03/01/2025* → **Display name: Task Name** (since the task spans more than two days).

opw-4474991

Forward-Port-Of: odoo/enterprise#80485
Forward-Port-Of: odoo/enterprise#78174

Currently, an exception is generated when the system tries to find the 'Out of Contract'  work_entry_type after it has been deleted.

Steps to Reproduce:

1 - Install hr_payroll module without demo data
2 - Navigate to hr payroll -> configuration -> work entry types 
3 - delete the 'Out of contract' work entry type
4 - Navigate to hr payroll -> Contracts -> Contract 
5 - Create a contract with a start date next to the current. 
6 - Navigate to hr payroll -> payslips ->  To pay
7 - Try to create Payslips To Pay for created contract 
8 - an error occurs

Error:
```ValueError
External ID not found in the system: hr_payroll.hr_work_entry_type_out_of_contract
```
This issue[1] occurs because when the system tries to reference the missing 'Out of Contract' work entry type it results in a ValueError due to a missing required record. The same issue [2] occurs in the `l10n_hk_hr_payroll` module.

[1] - 
https://github.com/odoo/enterprise/blob/265177dfd281f3aa1d61db6587ddfa37790570fe/hr_payroll/models/hr_payslip.py#L597

[2] -https://github.com/odoo/enterprise/blob/31e56779f8e0011ddc5c1a2821f68c8f041efbe4/l10n_hk_hr_payroll/models/hr_payslip.py#L180

This fix resolves the issue by ensuring that if the `Out of Contract` work entry type is missing, it returns a false value. A similar fix has been applied in `l10n_hk_hr_payroll`. Additionally, code has been added to prevent the deletion of any work entry type using @api.ondelete.

sentry-6277939517

Forward-Port-Of: odoo/enterprise#80798
Forward-Port-Of: odoo/enterprise#79053

Steps to reproduce the bug:
- Create a quality point:
    - Operations: Receipt
    - Control per: Product
    - Control frequency: All
    - Type: Worksheet
    - Template: Select any one
    - Success conditions: Match all the following rules
    - Created by: Is set

- Create a receipt order:
    - Product: Select any product
    - Confirm the receipt → A quality check is created

- Click on the "Quality Check" smart button
- Open the Worksheet"
- Complete the worksheet

Problem:
The quality check is not being automatically marked as passed or failed.

When accessing the worksheet through the quality check view, the
function “action_quality_worksheet” is called instead of
“action_open_quality_check_wizard” , which means that the key
“quality_wizard_id” is not added to the context:

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L64

However, when clicking on save, the function “action_worksheet_check”
is triggered:

https://github.com/odoo/enterprise/blob/b51da60213232ccbc537c399e1c007d6051e40ae/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L19

At this point, the system checks whether “quality_wizard_id” is present
in the context to proceed with the quality check; otherwise, it simply
closes the wizard:

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L95-L97

https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L98-L100


Opw-4652268

Forward-Port-Of: odoo/enterprise#82225