Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Forward-Port-Of: odoo/enterprise#100734

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

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Forward-Port-Of: odoo/odoo#235656

Currently, when the product specification is shown in an accordion, single-value attributes are displayed twice, causing duplicate information to appear.

**Steps to replicate:**
* Install `website_sale` with demo data.
* Open Products, pick any product, and add an attribute with a single value.
* Edit that product’s website page and set Specification → In accordion.

**Observed Behavior:**
* Specifications for single valued attributes are shown twice.

**Root cause:**
* This happens because [1] always shows single attribute values, regardless of the specification display style.

**Solution:**
* Hide the extra table when accordion is active.

**Before:**
<img width="1851" height="928" alt="image" src="https://github.com/user-attachments/assets/dbaccc28-dbbb-41df-9a04-b0330479e480" />
**After:**
<img width="1858" height="927" alt="image" src="https://github.com/user-attachments/assets/09317662-3d40-4128-a6d3-9f9c0af618c4" />

[1]:
https://github.com/odoo/odoo/blob/ac6960dc553088894e688bcc0f4a49245aa02d6c/addons/website_sale/views/templates.xml#L2175-L2195

opw-5382484

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

Issue
-----
Procurement quantities are computed wrong (for non-dropshipped sales) when the dropship module is installed.

Steps to reproduce
-----
- Enable dropshipping & multi step route
- Set delivery rule as MTSO
- Create a product
    - Stock of 5
    - Add a vendor
- Create a SO
- Sell 6 of the product
- Confirm SO
- Open linked PO and confirm it
- Go back to the SO and change quantity of the product to 8
- Open the second linked PO

> Quantity is 7 instead of 2

Cause
-----
Writing the new quantity triggers `action_launch_stock_rule`

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L255

in which we call `_get_qty_procurement` to get the 'already handled' quantity

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/sale_stock/models/sale_order_line.py#L384

The problem is that this function is overriden in `stock_dropshipping`

https://github.com/odoo/odoo/blob/3ce8e3e4e8049eb009ed05bdc3a33275c9eec0d6/addons/stock_dropshipping/models/sale.py#L42-L52

Because the condition is true, we use the purchase line's `po_line.product_qty` instead of calling `super()`. Since `po_line.product_qty == 1`, we simply return 1.

With this, we end up creating a procurement of 8 - 1 = 7 units as if we were doing a dropship, instead of the expected 2 units.

-----
Ticket:
opw-5121035

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

### Steps to reproduce:

- Create a rentable, storable product
- Create and confirm a rental order for 1 unit of this product
- Click on pickup
- Inventory > Reporting > Moves History
#### > Your pickup move appears without any reference

### Cause of the issue:

The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was:
https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 
And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257

### Fix:

Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference.

opw-5385004

Forward-Port-Of: odoo/enterprise#101670

Before this commit, deleting a thread in a group chat could lead to the following crash:

```
Cannot read properties of undefined (reading '_proxy')
```

Steps to reproduce:
- install mail and im_livechat modules
- create a group chat (3 users minimum)
- create a subthread
- delete the subthread

This happens because when deleting the thread of group, there are the following side-effects:
- it deletes relation `parent_channel_id`
- deletion of `parent_channel_id` side-effects to delete subthread again (because deletion in relation may come from parent)
- deletion of subthread triggers deletion of members
- deletion of member deletes subthread.correspondent since this is being used.

While the subthread is being deleted, it's not technically deleted yet, as fields.onDelete() may still need to refer to this record. This is intentional design [1].

However there was a typo in code: code of deletion of record in relation this is being used assumes that the record using it is a proxyInternal, therefore the `proxyInternal[one] = undefined` was expected to work properly. However the deleting records were stored as raw record, and this mistakenly and actually assigned `undefined` instead of clearing the internal record list.

Because of this problem, any `Proxy.get()` on this relational field would trigger the crash above.

We could fix the PR with `_proxy` on deleting record, but to keep code as fast as possible, this commit instead retrieve the raw record in usingRecord instead, and apply the deletion on internal record list on the raw record. This works with reactivity because even when operations are done on raw record, the function `.delete()` and `clear()` on record list have dedicated implementation to properly make writes on `_proxy` thus notifying reactive change as expected.

[1]: https://github.com/odoo/odoo/pull/224912

Before this commit, when downgrading from 19.1 to 19.0 with chat hub data from 19.1, i.e. chat windows or bubbles that are open, loading web client would crash with following error:

```
KeyError: 'thread_model'
```

This happens because of mismatch of format of chat hub data in 19.0 and 19.1:

- 19.0 identifies channels with model "discuss.channel" and id
- 19.1 identifies channels with just id

When downgrading from 19.1 to 19.0, it attempts to getOrFetch a thread to server by providing channel id but without passing a model. The getOrFetch of 19.0 looks at thread level, so it cannot guess providing just id means a channel, therefore it crashes due to missing model to provide.

This commit fixes the issue by dropping the chathub local storage data if the format of chathub data in local storage is invalid, i.e. the identifying data of opened / closed should necessarily have id and model. If no model is provided like with downgrade from 19.1 to 19.0, then it drops local storage and assumes no chat window or bubbles is open.

Task-5223650

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101275
Forward-Port-Of: odoo/enterprise#99871

When importing a bank statements xlsx in a bank journal, the wizard would
not match the "Cumulative Balance", not even proposing it for manual setup.

Steps to reproduce:
- Go to the accounting dashboard
- On a bank journal tile, in the right corner menu "New > Import File"
- Upload a file (there is one attached to the ticket)
- Cumulative Balance is not matched

This commit adds module.init() that is skipped in the "onWillStart"
override (it's present in the parent onWillStart). This has for consequence
that the "bank_stmt_import" key is now present in the context when
get_fields_tree() from Base_ImportImport is called, allowing the addition
of missing field.
See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18

This commit also adds a check to only add debit & credit in the added
field list if they are not actual field on the bst line model (see:
https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd)
This commit also checks that those fields are only added when the model
is account bank statement line (only useful in this case).

opw-5222326