Versions
--------
- 18.0+

Steps
-----
1. Have a minimal database with `event_product` installed;
2. run `:TestEventProduct.test_ensure_event_service_tracking`.

Issue
-----
> FAIL: TestEventProduct.test_ensure_event_service_tracking
> AssertionError: ValidationError not raised

Cause
-----
The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30

This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183

As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised.

Solution
--------
Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected.

runbot-234024

Forward-Port-Of: odoo/odoo#236045

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#99831
Forward-Port-Of: odoo/enterprise#98983

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

Forward-Port-Of: odoo/enterprise#99073

# How to reproduce the issue:
- Create two currency rates: one for today and one for the day before.
- Create two invoices with different `amount_total`, both using the rate from yesterday.
- Create a group payment dated today.

Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices.

Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed.

It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`.

In a group payment scenario:
- Two partials are created (one per invoice).
- Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line).
- As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment.

opw-5147281

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

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

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