Issue --> Using the 'product.product.name' field in loyalty.reward.discount_product_domain that is not added via the `_loader_params_product_product` loader causes an error in the matchCondition function https://github.com/odoo/odoo/blob/9b0f528aa02743372934df8e64d1cc0ad74903b6/addons/web/static/src/core/domain.js#L331 where variable fieldValue is undefined if the field is not available. Solution --> Adding the `name` field search parameters in the `_loader_params_product_product` simi

Issue -->

Using the 'product.product.name' field in loyalty.reward.discount_product_domain that is not added via the `_loader_params_product_product` loader causes an error in the matchCondition function
https://github.com/odoo/odoo/blob/9b0f528aa02743372934df8e64d1cc0ad74903b6/addons/web/static/src/core/domain.js#L331 where variable fieldValue is undefined if the field is not available.

Solution -->

Adding the `name` field search parameters in the `_loader_params_product_product` similar to https://github.com/odoo/odoo/pull/186804

opw-4410460

Forward-Port-Of: odoo/odoo#194688
Forward-Port-Of: odoo/odoo#194637

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#194426 Forward-Port-Of: odoo/odoo#192048

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#194426
Forward-Port-Of: odoo/odoo#192048

Steps to reproduce: - Add a "Call To Action" block on the homepage > Save it as a custom snippet. - Add a new page > Drop the saved custom block on it > Drop Also another "Title" block. - Translate the custom block in the new page > At this point, the translation is fine. - Go to "Edit" mode > Edit the other block ("Title") > Save. - The translations for the custom "Call To Action" is lost. Starting from [1], the translation of custom snippets was supported and when dropping a save

Steps to reproduce:

- Add a "Call To Action" block on the homepage > Save it as a custom
snippet.
- Add a new page > Drop the saved custom block on it > Drop Also
another "Title" block.
- Translate the custom block in the new page > At this point, the
translation is fine.
- Go to "Edit" mode > Edit the other block ("Title") > Save.
- The translations for the custom "Call To Action" is lost.

Starting from [1], the translation of custom snippets was supported and
when dropping a saved custom snippet in a page/view, the snippet will
copy its translation from the saved view (see:
`_copy_custom_snippet_translations()`). This code will always update the
terms in the translation dictionary, even when the page has its custom
translation for them.

The goal of this commit is to fix this behavior by only allowing the
update of a term translation when the page has no custom translation
for it.

[1]: https://github.com/odoo/odoo/commit/d3426b7714012e833caae10281cfb8433223299a

opw-3930862
opw-4141290

Forward-Port-Of: odoo/odoo#194234
Forward-Port-Of: odoo/odoo#177960

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead 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:

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead

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

The Issue: Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest. The Fix: To resolve this, we ensure the function selects the correct website by explicitly passing it in the context. runbot-64729 Forward-Port-Of: odoo/odoo#189705

The Issue:
Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest.

The Fix:
To resolve this, we ensure the function selects the correct website by explicitly passing it in the context.

runbot-64729

Forward-Port-Of: odoo/odoo#189705

### Issue: The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically: The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the si

### Issue:

The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically:

The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the situation.

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

Forward-Port-Of: odoo/odoo#193587
Forward-Port-Of: odoo/odoo#190867

Description of the issue/feature this PR addresses: Current behavior before PR: The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed. Desired behavior after PR is merged: The "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 --- I confirm I have si

Description of the issue/feature this PR addresses:

Current behavior before PR:
The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed.

Desired behavior after PR is merged:
The  "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 
 



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

Forward-Port-Of: odoo/odoo#184840

When the pos was loading only a part of the products, the request should follow those rules order: - product is a favorite - product is a service - product had stock moves soon - product update But this request didn't take into account consumables products and if there was no stock move, the value was null and postgres consider null values first when ordering desc. Now with that changes, the order is correctly set based on the rules above. --- I confirm I have signed the CLA and read

When the pos was loading only a part of the products, the request should follow those rules order:
- product is a favorite
- product is a service
- product had stock moves soon
- product update

But this request didn't take into account consumables products and if there was no stock move, the value was null and postgres consider null values first when ordering desc. Now with that changes, the order is correctly set based on the rules above.

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

Forward-Port-Of: odoo/odoo#158193
Forward-Port-Of: odoo/odoo#124223

Steps to reproduce: ----- - Create a MO - Duplicate it - Change the scheduled date - Confirm Issue: --- This [changes](https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44), is trying to timedelta between str and datetime leading to an error. Fix: --- To fix this the date_start is set as a datetime and removing the conversion later in the code. opw-4489618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
-----

- Create a MO
- Duplicate it
- Change the scheduled date
- Confirm

Issue:
---

This [changes](https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44), is trying to timedelta between str and datetime leading to an error.

Fix:
---
To fix this the date_start is set as a datetime and removing the conversion later in the code.

opw-4489618


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

Forward-Port-Of: odoo/odoo#194376

The event listeners are never removed when the component is unmounted which means to global `env.bus` always keeps a reference to this component and everything that goes with it, including its (child)env. In version 18.0, the spreadsheet client action instantiates its own `BurgerMenu` component and also adds the spreadsheet `model` in the action child env (which can be expensive memory-wise) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

The event listeners are never removed when the component is unmounted which means to global `env.bus` always keeps a reference to this component and everything that goes with it, including its (child)env.

In version 18.0, the spreadsheet client action instantiates its own `BurgerMenu` component and also adds the spreadsheet `model` in the action child env (which can be expensive memory-wise)



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

Forward-Port-Of: odoo/odoo#194587
Forward-Port-Of: odoo/odoo#194485

It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393

It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally.

This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them.

Forward-Port-Of: odoo/odoo#194393

**Problem**: In rare edge cases, the selection can have no ranges, causing a crash when attempting to `getRangeAt(0)`. **Solution**: Ensure there are ranges in the selection before accessing them. **Steps to Reproduce**: 1. Split the window, with Odoo on one side and any other application on the other. 2. Navigate to a sales order in Odoo. 3. From the sales order, navigate to the partner. 4. Maximize the window. 5. Return to the sales order. 6. Split the window again. 7. Scroll do

**Problem**:
In rare edge cases, the selection can have no ranges, causing a crash when attempting to `getRangeAt(0)`.

**Solution**:
Ensure there are ranges in the selection before accessing them.

**Steps to Reproduce**:
1. Split the window, with Odoo on one side and any other application on the other.
2. Navigate to a sales order in Odoo.
3. From the sales order, navigate to the partner.
4. Maximize the window.
5. Return to the sales order.
6. Split the window again.
7. Scroll down.

opw-4279813

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

Forward-Port-Of: odoo/odoo#194385

Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount

Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded.

Steps to reproduce:
-------------------
* Create a new customer, make a sale order and invoice it. This will set an amount due for that customer
* Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group
* Open customer list
> Observation: You can see the amount due for multiple customers
* Search for the customer created
* Select search more
> You can't see the amount due for that customer

Why the fix:
------------
Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load.

Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4

When loading the pos session `_loader_params_res_partner` is called first and later is called `_get_pos_ui_res_partner`. It is in the function `_get_pos_ui_res_partner` that the amount due is compted if the user does not belong to the group `account.group_account_readonly`.

https://github.com/odoo/enterprise/blob/a35a4755cdf86bcfeda0aca6c06397748ba27362/pos_settle_due/models/pos_session.py#L22-L28

However when we load a customer that wasn't previously loaded, only `_loader_params_res_partner` is loaded. And since the users does not belong to the group `account.group_account_readonly`, the field witll not get loaded.

We now compute the amount due with the same logic as in `_get_pos_ui_res_partner`.

opw-4141955

Forward-Port-Of: odoo/enterprise#73916
Forward-Port-Of: odoo/enterprise#73671

### Steps to reproduce: - Create a Vendor Bill in a foreign currency, leave "Payment Reference" blank - In the Accounting Dashboard click on the three dots of the "Bank" block and click on "Operations" - Create a new transaction - Under "Foreign currency" select the one from the bill - Under "Amount in currency" select the one from the bill - Under "Amount" select a different amount - Click "Match" on the right - Select the bill in the entries list - Under the line "Foreign Change Gain"

### Steps to reproduce:
- Create a Vendor Bill in a foreign currency, leave "Payment Reference" blank
- In the Accounting Dashboard click on the three dots of the "Bank" block and click on "Operations"
- Create a new transaction
- Under "Foreign currency" select the one from the bill
- Under "Amount in currency" select the one from the bill
- Under "Amount" select a different amount
- Click "Match" on the right
- Select the bill in the entries list
- Under the line "Foreign Change Gain" is "Exchange Difference: False"

![image](https://github.com/user-attachments/assets/a8e447cb-2be6-48cc-a1d2-aa75cea44675)

### Cause:
The payment reference is supposed to be displayed here but it is equal to `False` so "False" is displayed.

### Solution:
Fallback on empty string if `new_aml.name` is `False`.

opw-4485887

Forward-Port-Of: odoo/enterprise#77508
Forward-Port-Of: odoo/enterprise#77354

Backport of fix from master to 17.0 to avoid unnecessary installation during upgrades: https://github.com/odoo/enterprise/pull/56794 task-3725031 Forward-Port-Of: odoo/enterprise#69525 Forward-Port-Of: odoo/enterprise#62995

Backport of fix from master to 17.0 to avoid unnecessary installation during upgrades: https://github.com/odoo/enterprise/pull/56794

task-3725031

Forward-Port-Of: odoo/enterprise#69525
Forward-Port-Of: odoo/enterprise#62995

**[IMP] account_reports: hide "Amount Currency" in PL if single currency** Currently, the column "Amount Currency" is displayed in the partner ledger even in a single currency setup. With this commit, it will now be hidden. **[FIX] account_reports: fix isNextLineChild** Currently, `isNextLineChild` method will consider `~account.report~14|~res.partner~10|0~account.move.line~32` being a a child of `~account.report~14|~res.partner~10|0~account.move.line~3` as the first string star

**[IMP] account_reports: hide "Amount Currency" in PL if single currency**

Currently, the column "Amount Currency" is displayed in the partner
ledger even in a single currency setup.

With this commit, it will now be hidden.

**[FIX] account_reports: fix isNextLineChild**

Currently, `isNextLineChild` method will consider
`~account.report~14|~res.partner~10|0~account.move.line~32` being a
a child of
`~account.report~14|~res.partner~10|0~account.move.line~3` as the first
string starts with the second one.
This is wrong, they are siblings.

The fix here is to add a pipe, as done in `isLineChildOf`.

**task-4321032**

Forward-Port-Of: odoo/enterprise#73843

### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mand

### Steps to reproduce:
- Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509)
- Have a contact with a European IBAN
- Have a company bank journal with a European IBAN
- Create a valid Direct Debit Mandate for your contact
- Create an invoice for that contact and register a payment using SEPA
- Now delete that Sepa payment from Accounting > Customers > Payments
- Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mandate although the payment was deleted
- Expected: link between invoice and mandate should not be kept if payment was deleted

### Cause:
The field `sdd_mandate_id` of the invoice is not reset when the payment is reset to draft.

### Solution:
Add an `api.ondelete` method on `account.partial.reconcile` which checks if any of the unreconciled moves is an invoice with `sdd_mandate_id`. In that case, and if the unreconciled payment is the only SEPA payment, set `sdd_mandate_id` to False.

opw-4277982

Forward-Port-Of: odoo/enterprise#75273

The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/enterprise#63598 Forward-Port-Of: odoo/enterprise#58348

The confirmation page wasn't displayed and the order wasn't sent to the
preparation display when confirming an order with a total of 0.

Now the confirmation page is displayed and the order is send to the
preparation display when the order is confirmed regardless of the total
amount.

Forward-Port-Of: odoo/enterprise#63598
Forward-Port-Of: odoo/enterprise#58348

Forward-Port-Of: odoo/enterprise#77503

Forward-Port-Of: odoo/enterprise#77503

In version 16, we upgraded from Bootstrap 4 to Bootstrap 5 [here](https://github.com/odoo/odoo/pull/95450). As a result, the class font-weight-bold is no longer functional and has been replaced with[ fw-bold](https://github.com/odoo/odoo/blob/31d1be3de895d9e6667a35468b4be716127d17b3/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8427). However, when creating a worksheet template, the deprecated Bootstrap class font-weight-bold is still being generated in the arch, causing the label t

In version 16, we upgraded from Bootstrap 4 to Bootstrap 5 [here](https://github.com/odoo/odoo/pull/95450). As a result, the class font-weight-bold is no longer functional and has been replaced with[ fw-bold](https://github.com/odoo/odoo/blob/31d1be3de895d9e6667a35468b4be716127d17b3/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8427).

However, when creating a worksheet template, the deprecated Bootstrap class font-weight-bold is still being generated in the arch, causing the label to not render in bold.

**Steps to reproduce:**
- create demo db in version >= 16.0
- navigate to Field Service > Configurations > Worksheet Template
- Add the field `report_view_id` field to see the auto-generated view for report (using studio)
- set the created template to the task and print the report (Task Report)

![fw-bold-PR-ref](https://github.com/user-attachments/assets/88c3fdca-e74a-473b-8a67-f585a7fd24fc)

more ref: https://github.com/odoo/upgrade/commit/cfd58d145b8bbb99b0ec1dcc70bcfbfa3f9b7e20
- OPW: 4423371

Forward-Port-Of: odoo/enterprise#77203
Forward-Port-Of: odoo/enterprise#76509