Currently, an error occurs when a user includes an XML encoding declaration in the view architecture.

**Steps to reproduce:**
- Enable **developer mode**.
- Under `Settings > Technical > User Interface > Views` Create or edit any view.
- Enter the `view name` and select `view type`.
- In the Architecture field, declare encoding as: `<?xml version='1.0' encoding='utf-8'?>`.
- Attempt to save the view.

**Error:**
`ValueError: Unicode strings with encoding declaration are not supported.
Please use bytes input or XML fragments without declaration.`

**Root Cause:**
The [1] call raises a ValueError when the XML declaration
includes an encoding attribute. This low-level error is not handled and results
in an ungraceful failure.

[1]- https://github.com/odoo/odoo/blob/bf4ccb21f6c9c8bcda9c6f94d844c89296523954/odoo/tools/translate.py#L281

This commit ensures raising an UserError, improving the error message clarity.

sentry-6505918596

Forward-Port-Of: odoo/odoo#226396
Forward-Port-Of: odoo/odoo#205324

**Description of the issue this PR addresses:**
When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch attempt succeeds, the flag is not reset. As a result, the UI may continue to show an error state even though the data has successfully loaded.

**Steps to Reproduce:**
- Open a thread with many messages.
- Go offline.
- Scroll up to load older messages → failure message appears.
- <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" />
- Go back online and click Retry → messages load successfully.
- Scroll again → failure message still appears, even though you’re online.
 - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" />


**Current behavior before PR:**
After a failed attempt to fetch messages in a thread, the `hasLoadingFailed` flag remains set to `true`. Even if the user goes back online and the subsequent fetch succeeds, the UI continues to show a failure state.

**Desired behavior after PR is merged:**
After a successful fetch of a thread’s messages, the `hasLoadingFailed` flag is reset to `false`, ensuring the UI no longer shows a failure state once the data has been correctly loaded.



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

Forward-Port-Of: odoo/odoo#226145
Forward-Port-Of: odoo/odoo#222001

**Steps to reproduce:**
1. Install the module `quality_control`.
2. Go to **Products → select any product → Quality Points (smart button)**.
   * Create a new Quality Point that applies to *all products*.
3. Open any product form.
   * Verify that the *Quality Points* smart button shows the created point and the correct count.
4. Archive the Quality Point.
5. Reopen the same product form and check the *Quality Points* smart button again.

**Observed behavior:**
- The archived Quality Point is still counted and shown in the smart button.

**Root cause:**
- During the refactor from raw SQL (`get_sql` + `cr.execute`) to the ORM query builder (`query.add_where(SQL(...))`), one outer bracket was dropped. [ref](https://github.com/odoo/enterprise/pull/66290/commits/a6362bc07eac7640f68d145a0f6a14a81f499913#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L542-R561)
- This changed the operator precedence, causing the `active = true` condition to no longer properly apply when combined with the OR block.
- As a result, archived Quality Points bypass the filter and are still counted.

**Solution:**
- Fix the missing bracket in the `query.add_where` SQL expression so that the `active` condition is always enforced before evaluating the OR block.

opw-5046289

Forward-Port-Of: odoo/enterprise#94173

It's not rare to have databases with a huge number of svls for some products. For instance, the database of opw-4326597, which is currently on 17.0 and hosted on Odoo.sh, has 166 000 svls for the same product. Because of that, the current code in `svl_empty_stock` is likely to raise a MemoryError in those databases. The reason for that
is the `__get__` call on `stock_valuation_layer_ids` along with a call to `filtered`. After expanding the singleton
with the `prefetch_ids` and fetching all the fields of the related svls, the cache will probably raise a MemoryError.

We are preempting this issue by changing this part of the code with a call to `_read_group` to get the correct lots directly.

Thanks to @mwath for pointing this out.

#### speedup

Benchmark of the `_svl_empty_stock` method, with a product
with 200 000 svls with a lot.

| Before PR  | After PR  |
|:----------:|:---------:|
| 15.03s     |  198.64ms |

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

Forward-Port-Of: odoo/odoo#188285