**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
 Traceback (most recent call last):
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
    return _compute_field_value.origin(self, field)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
    partner_tickets.fetch(['stage_id'])  # prevent over-fetching fields, leading to potential out-of-memory error
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
    self.check_access('read')
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
    if not self.env.su and (result := self._check_access(operation)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
    if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
    data = record.mapped(key)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
    recs = recs._fields[name].mapped(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
    self.__get__(first(remaining))
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
    return super().__get__(records, owner)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
    recs._fetch_field(self)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
    self.fetch(fnames)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
   File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
    return [] if self.cr.description is None else self.cr.fetchall()
 MemoryError
 ```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`

Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance

upg-2707381
opw-4653413

Forward-Port-Of: odoo/enterprise#83280

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

Steps
-----
1. Enable Paypal as payment provider;
2. have a US-based partner;
3. sent them a payment link;
4. pay using Paypal;
5. open transaction on Paypal backend.

Issue
-----
No delivery address is registered, making the merchant ineligible for seller protection.

Cause
-----
Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is that it doesn't even register the address provided with the transaction.

Solution (16.0 up to saas-17.4)
-------------------------------
Use the `address_override: '1'` value instead, which prevents buyers from changing the address while still registering the address on the transaction.

In stable, keep the `no_shipping: '1'` value in the rendering values so that user's cannot suddenly change the address again if template hasn't been updated yet.

Solution (18.0+)
----------------
Change the `shipping_preference` value from `NO_SHIPPING` to `SET_PROVIDED_ADDRESS`[^1].

opw-4681336

[^1]: https://developer.paypal.com/docs/checkout/standard/customize/shipping-module/#:~:text=Configuring%20shipping%20preferences

Forward-Port-Of: odoo/odoo#205972
Forward-Port-Of: odoo/odoo#205686

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

Steps
-----
1. Create a product with 3 attributes;
2. add a never-create multi-select attribute;
3. archive the first two variants;
4. publish the product to eCommerce;
5. open /shop.

Issue
-----
> 500: Internal Server Error

Cause
-----
Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination.

Issue is when continuing after the `yield`, it attempts to get the `current_ptav_index` from the `current_line_values` recordset, which is empty for `multi`-type attributes. This causes an `IndexError`.

Solution
--------
Only assign the `current_ptav` variable if `current_line_values` is not falsey, i.e. isn't on a `multi` attribute line.

Because `current_ptav_index` will always be `-1` in this scenario, it will skip over the conditional branches where `current_ptav` gets used, and instead go to either `continue` or `break`.

opw-4653696

Forward-Port-Of: odoo/odoo#203093

### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their `procure_method` during the `_action_confirm`:
https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513 In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call:
https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075 It will therefore also automatically create and run a procurment that will in turn modify the current PO.

opw-4633920

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

Forward-Port-Of: odoo/odoo#205192