## Description Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption. We introduce an upper bound on the delegated `_name_sear

## Description
Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption.

We introduce an upper bound on the delegated `_name_search`. To avoid excessive iterations when there is no limit, the bound is set large enough but not so large that it causes blocking regressions. Each iteration becomes more selective than the previous one, as already found templates are excluded from the search scope.

## Benchmark
On a database with over half-million active products, a non-selective `name_search` that matches 1/3 of the products (For ex: `name='d', args=[('sale_ok', '=', True)]`, which happens during via dropdown of products on a `sale.order`):

|               | Before           | After |
|---------------|------------------|-------|
| Timings (hot) | 15min+ (timeout) | 50ms  |

## Reference
opw-4448182

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

Forward-Port-Of: odoo/odoo#193448
Forward-Port-Of: odoo/odoo#193293

Steps: - Install project_todo - Create a second company - Create a project - Link the project to a company - Setup a default value for task.project_id with your new project (1) - Try to open project_todo Actual result: - Error due to company id - can't adapt type 'res.company' Expected result: - No error - Welcome task is created and project is opened opw-4465277 Caused by https://github.com/odoo/odoo/pull/173625 Forward-Port-Of: odoo/odoo#193359

Steps:
- Install project_todo
- Create a second company
- Create a project
- Link the project to a company
- Setup a default value for task.project_id with your new project (1)
- Try to open project_todo

Actual result:
- Error due to company id
- can't adapt type 'res.company'

Expected result:
- No error
- Welcome task is created and project is opened

opw-4465277

Caused by https://github.com/odoo/odoo/pull/173625

Forward-Port-Of: odoo/odoo#193359

Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<scr

Steps to reproduce:

- Enter website edit mode.
- Drag and drop a "Products" dynamic snippet onto the page.
- Drag and drop a "Search" snippet onto the page.
- Save the page.
- Perform a search for "dynamic" using the search input.
- Bug: The dynamic snippet alert message appears in the results.

The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results.

With this commit, elements like "css_non_editable_mode_hidden" and "<script>" are excluded from search results.

opw-4420622

Forward-Port-Of: odoo/odoo#192029

Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit not

Minimal Configuration:
- Create an account (49999 Great Account) that has a default tax (15%)
- Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss)

Steps to reproduce:
- Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%)
- Confirm -> amount = 108.9
- Duplicate the invoice (in the ticket: Create a Credit Note)

Issue:
=> The credit note is not of the same amount = 106.80. That is, MINUS discount * tax_amount <-> 108.90 MINUS 10% * 21= 106.80

Cause:
When there is a "Separate discount accounts on invoices" that is set, discount line appear on the journal items of the document; moves between the default account for such transaction to the chosen move in the settings.
When iterating through those discount lines, the condition was not strict enough to filter them out and would put a tax on them (as my dear colleague Andrea said: the bomb has been planted)

Therefore, when creating a credit/duplicating,  we copy the data  wrongly (but in a correct a way for a standard flow) which gives incoherent results

opw-4166601

Forward-Port-Of: odoo/odoo#187565

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192463

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice).

This commit aims to give a single and unified way to display them.

ticket-4440711




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

Forward-Port-Of: odoo/odoo#192463

Description of the issue/feature this PR addresses: This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface. Current behavior before PR: Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times. Desired behavior after PR is m

Description of the issue/feature this PR addresses:
This PR addresses the issue where the currency column repeats in view_move_line_payment_tree view when there are multiple active currencies. This can lead to confusion and clutter in the user interface.

Current behavior before PR:
Before this PR, when multiple active currencies are set up, the currency column is duplicated in view_move_line_payment_tree view, displaying the same information multiple times.

Desired behavior after PR is merged:
After merging this PR, the currency column will appear only once when the optional hide setting is enabled, even with multiple active currencies, resulting in a cleaner and more readable report.

[Video](https://drive.google.com/file/d/1bL8L88y81HomX6Q9MkErmOGVDWHdE4_r/view)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#192784

Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759

Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid.

opw-4292231

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

Forward-Port-Of: odoo/odoo#187759

Versions -------- - 16.0+ Steps ----- 1. Have a payment provider like Demo published; 2. create a discount program that expired yesterday; 3. change time of PC to yesterday; 4. go to eCommerce, add product to cart, go to checkout; 5. follow steps until you get to the "Pay Now" button; 6. change time of PC to today; 7. finalize payment. Issue ----- The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards. Cause ----- Whe

Versions
--------
- 16.0+

Steps
-----
1. Have a payment provider like Demo published;
2. create a discount program that expired yesterday;
3. change time of PC to yesterday;
4. go to eCommerce, add product to cart, go to checkout;
5. follow steps until you get to the "Pay Now" button;
6. change time of PC to today;
7. finalize payment.

Issue
-----
The payment transaction proceeds, but doesn't cover the entire amount, as the promotion was removed afterwards.

Cause
-----
When initiating payment, there's check on whether the applied rewards are still valid.

Solution
--------
Add an override for `_validate_transaction_for_order`, which compares the order amount before and after updating programs & rewards.

If they don't match, raise a `ValidationError`, forcing the user reload the order without expired programs & rewards.

opw-4304241

Forward-Port-Of: odoo/odoo#193415
Forward-Port-Of: odoo/odoo#191256

Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453

Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this.

opw-3997339

Forward-Port-Of: odoo/odoo#171453

The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move. Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not bei

The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.

But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).

Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS 
    * Payment method: Cash on journal CSH1
    * Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account) 
```
* 1 entry in the POS journal (order)
       base:       | - 100.0 $
       tax:        | -  16.0 $
       receivable: | + 116.0 $
     * 1 entry in the CSH1 journal (cash / payment)
       cash:       | + 116.0 $
       receivable: | - 116.0 $
     * 1 entry in the CBMX journal (caba)
       base:       | - 100.0 $
       base:       | + 100.0 $
       tax:        | -  16.0 $
       tax:        | +  16.0 $
     * 1 entry in the EXCH journal (exchange difference)
       for the cash basis rounding difference
       tax:        | -  16.0 $
       tax:        | +  16.0 $
```

This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.

opw-4355124

Forward-Port-Of: odoo/odoo#193375
Forward-Port-Of: odoo/odoo#193195

**Affects** 16.0+ **Steps to reproduce:** - Render the Contact qweb widget with fields ["phone", "website"] ```py Contact = self.env["ir.qweb.field.contact"] partner = self.env["res.partner"].create( { "name": "Test Partner", "phone": "1234567890", "website": "https://www.example.com", } ) result = Contact.value_to_html(partner, {"fields": ["phone", "website"]}) ``` **Result:** - The website is not shown --- This is a regression int

**Affects**
16.0+

**Steps to reproduce:**

- Render the Contact qweb widget with fields ["phone", "website"]

```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
    {
        "name": "Test Partner",
        "phone": "1234567890",
        "website": "https://www.example.com",
    }
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```

**Result:**

- The website is not shown

---

This is a regression introduced in 9e53aea9, in combination with some buggy behavior in the qweb compilation.

Somehow the `t-elif` condition is applying on the next element instead on itself, hiding the website item. I did not investigate this further.


ping @lvsz @ryv-odoo

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

Forward-Port-Of: odoo/odoo#192460
Forward-Port-Of: odoo/odoo#191201

Description of the issue this commit addresses: The Italian annual tax report lacks an integer rounding feature. --- Desired behavior after this commit is merged: The Italian annual tax report uses the HALF-UP rounding method. --- Community PR: https://github.com/odoo/odoo/pull/164064 Task-3479785 Forward-Port-Of: odoo/enterprise#76756 Forward-Port-Of: odoo/enterprise#62405

Description of the issue this commit addresses:

The Italian annual tax report lacks an integer rounding feature.

---

Desired behavior after this commit is merged:

The Italian annual tax report uses the HALF-UP rounding method.

---

Community PR: https://github.com/odoo/odoo/pull/164064
Task-3479785

Forward-Port-Of: odoo/enterprise#76756
Forward-Port-Of: odoo/enterprise#62405

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#76522

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice).

This commit aims to give a single and unified way to display them.

ticket-4440711

Forward-Port-Of: odoo/enterprise#76522

Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-P

Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket.
This seems to only be an issue with PyPDF2 2.12.1.

This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages.

opw-4293390

Forward-Port-Of: odoo/enterprise#76072

Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#77043 Forward-Port-Of: odoo/enterprise#75881

Before this commit:
When the user clicks on the studio icon just after opening any app before its 
view gets loaded, the traceback will occur because the `get_view` method has not 
yet loaded.

After this commit:
Traceback will not occur.

Task-4348166

Forward-Port-Of: odoo/enterprise#77043
Forward-Port-Of: odoo/enterprise#75881

An error occurs when the system tries to access single values from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/social_youtube/models/res_config_settings.py#L19 Traceback On Sentry: ``` ValueError: Expected singleton: res.config.settings(105, 106) File "odoo/http.py", line 2366, in __call__ response = request._serve_db() File "odoo/http.py", line 1894, in _serve_db return self._transactioning( Fil

An error occurs when the system tries to access single values from multiple records at [1].

Link [1]: https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/social_youtube/models/res_config_settings.py#L19

Traceback On Sentry:

```
ValueError: Expected singleton: res.config.settings(105, 106)
  File "odoo/http.py", line 2366, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1894, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1957, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1924, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2171, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 727, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "odoo/models.py", line 6090, in search_read
    return records._read_format(fnames=fields, **read_kwargs)
  File "odoo/models.py", line 4032, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
  File "odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 110, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/18.0/social_youtube/models/res_config_settings.py", line 19, in _compute_youtube_oauth_client_id
    if self.env.user.has_group('social.group_social_manager') and self.youtube_use_own_account:
  File "odoo/fields.py", line 1232, in __get__
    record.ensure_one()
  File "odoo/models.py", line 6212, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

To resolve this issue, Use an iteration(for loop) to iterate records one by one.

Sentry-6200420369

Forward-Port-Of: odoo/enterprise#76588

Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong. The freeze time is instead removed, and the few places which were dependant of the current date (where the batch creation date matters) are changed to dynamically expect today's date. backport of https://github.com/odoo/enterprise/commit/3d827b6c2d7f5c83785ecb6821092f349fca922f Forward-Port-Of: odoo/enterprise#77010

Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong.

The freeze time is instead removed, and the few
places which were dependant of the current date
(where the batch creation date matters) are
changed to dynamically expect today's date.

backport of https://github.com/odoo/enterprise/commit/3d827b6c2d7f5c83785ecb6821092f349fca922f

Forward-Port-Of: odoo/enterprise#77010