Currently, when an error occurs during `/ai/generate_response` calls from the
frontend, a `UserError` is logged with its exception stack instead of being
emitted as a logger warning. Additionally, an `UncaughtPromiseError` is
surfaced on the UI.

Error:
```
Error on request:
Traceback (most recent call last):
  File "/home/odoo/src/enterprise/saas-19.1/ai/utils/llm_api_service.py", line 302, in _request
    response.raise_for_status()
  File "/usr/lib/python3/dist-packages/requests/models.py", line 1021, in raise_for_status
```

The issue originates from the `/ai/generate_response` route, which is
defined as a controller `type="http"` to handling POST requests. When
line [1] raises an exception inside this controller, it automatically converts
the unhandled exception into an HTTP response. As a result, the request
returns a `500 Internal Server Error`, which then propagates to the frontend
and appears as an `UncaughtPromiseError`.

This commit fixes the issue by returning internal errors as chat
messages instead of raising exceptions. As a result, the error is
displayed as a message received from the AI agent, rather than
propagating as a server error to internal users.

[1]: https://github.com/odoo/enterprise/blob/423dee8f565a6ca7cd88ec0625a5059920725f50/ai/controllers/thread.py#L83

Sentry-5691330773

Before this commit:
-------------------------
- In the Repair module, when a quality check for a product was marked as failed,
  Even after selecting a failure location, the failure location is not being set
  at the final product move.
- Instead of showing the selected failure location, the system displayed another
  location as the move destination after completing the repair process.

Steps to reproduce:
-------------------------
1. Install the quality_repair module.
2. In Quality, create a Control Point with:
   - Type = Pass-Fail
   - Control Per = Product or Operation
   - Set at least 1 Failure Location
3. Create a Repair Order for any product and start the repair process.
4. Perform a quality check, set it to Fail, and select a failure location.
5. Open the product moves, the destination location does not match the selected
   failure location.

Cause of the issue:
-------------------------
The failure location was not correctly assigned when a quality check failed
during the repair process because _move_to_failure_location determines the
destination location based on a stock picking (for receipts) or a production_id
(for manufacturing). In the Repair module, however, quality checks are linked to
a repair order, so the selected failure location was not set correctly.

After this commit:
-----------------------
- When a quality check fails in a repair order, the product’s destination
  location is correctly set to the failure location selected by the user.
- This ensures that, upon completion of the repair, the product is moved to the
  selected failure location, maintaining accurate inventory tracking and
  management.

Task ID:5254334

Forward-Port-Of: odoo/enterprise#99235

Steps to reproduce:
-----------------------------------------
1. Install `sale_purchase_project` and Accounting modules
2. From settings, enable Budget Management
3. Create a new product with type Service and enable Create a project on order.
4. Create and confirm the sale order with that product (note the name of created project)
5. Create and confirm purchase order as follows:
> In other information page, select the created project in the Project field
> Add the same product in POL, Set price unit price to 100 and remove any tax
6. Create and post a Vendor Bill for the same vendor as the PO as follows:
> Add Bill line with label downpayment
> Set the Analytic Distribution to the created project
> Set amount to 30
7. Go to the created purchase order > Click on bill matching
8. Select the downpayment bill > Add to PO > Select created PO > Add Down Payment
9. Go to the created project and open dashboard

Observation:
-----------------------------------------
In the Costs section:
Expected Cost: 130
To Bill: 100
Billed: 30

Expected values:
-----------------------------------------
Expected Cost: 100
To Bill: 70
Billed: 30

Issue:
----------------------------------------
In the following code:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/project_purchase/models/project_project.py#L186-L190

When an invoice line was posted (billed), the code correctly subtracted the cost from `amount_invoiced` (making it negative, representing actual cost). But the billed amount was NOT removed from `amount_to_invoice`. This caused double counting the same cost appeared in both 'To Bill' and 'Billed'

Solution:
-----------------------------------------
Replaced the quantity-based calculation with a proper amount-based approach:
- Introduced `total_invoiced_amount` to track the sum of all non-refund invoice line amounts (both posted and draft).
- Modified the unbilled calculation to: `PO_amount - total_invoiced_amount`, ensuring that the unbilled portion accurately reflects what remains to be invoiced from the purchase order.
- Excluded refunds from `total_invoiced_amount` calculation because credit notes represent reversals of previous invoices, not consumption of the purchase order.  Refunds still correctly affect the "billed" and "to_bill" buckets through the normal invoice line processing.

This ensures the accounting principle is maintained: Total Expected Cost = Billed + To Bill = Purchase Order Amount

opw-5167734

Forward-Port-Of: odoo/odoo#245649

Steps to reproduce:
---
- Install `Sales` module.
- Create a Sale Order.
- Add a section with products.
- Add a subsection under it with products.
- Enable `Hide Prices` on the section.
- Enable `Hide Composition` on the subsection.
- Preview the Sale Order.

Issue:
---
- Prices are still visible in the subsection (grouped view) even though `Hide Prices` is enabled on the parent section.

Root cause:
---
- The variable `show_section_total` was defined only within the main rendering block and not reused in the grouped (`t-else`) block.
- The grouped section summary (used when `collapse_composition=True`) did not respect the parent section's `collapse_prices` setting, causing prices to be displayed.

Solution:
---
- Moved `show_section_total` definition outside the main conditional block so it can be reused in both rendering paths.
- Applied `t-if="show_section_total"` to price fields in the grouped section summary to ensure consistency with the parent section's price visibility.

Before:
---
<img width="1030" height="232" alt="image" src="https://github.com/user-attachments/assets/1ac05e5e-6841-420f-909f-994690656cc0" />

After:
---
<img width="1023" height="232" alt="image" src="https://github.com/user-attachments/assets/921ae337-4d53-433a-a42b-bdc437181889" />



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

Forward-Port-Of: odoo/odoo#255464

The AVCO audit report currently recalculates the AVCO value on outgoing moves. Based on the logic in `run_average_batch()`, it should instead use the AVCO value computed on the last ingoing move to recalculate the
`added_value`.                                                         

On the other hand, the `added_value` should not be recomputed from the AVCO value on ingoing moves.

Source of those changes: [245141](https://github.com/odoo/odoo/pull/245141)

Steps to reproduce the issue:
1. Create a new product. Do not assign it to a category yet.
2. Set the cost (standard_price) to 10$ on the product form.
3. Add 10 units to inventory.
4. Sell and deliver 5 units to a customer.
5. Purchase 10 units at 25$/ea and validate the receipt.
6. Sell and deliver 5 units to a customer.
7. Assign the product to category with AVCO cost method.
8. Go to the AVCO justification report:
    - The added value on the purchase is incorrect: 200$ instead of 250$.
    - On the last delivery: the added value is -125$ and the AVCO increases from 20$ to 25$.

Ticket: opw-5921104

Forward-Port-Of: odoo/odoo#252239

**Description of the issue this PR addresses:**
Ensure the `Looking for Help` timer is shown even when the current 
user is already a member of the livechat channel.

**Steps to Reproduce:**
1. Log in as a visitor and as Mitchell Admin (Live Chat operator).
2. From the visitor side, select I have a pricing question.
3. From the admin side, mark the conversation as Looking for Help.
4. The channel appears in the Looking for Help category.
5. Observe that the timer should be visible there (e.g., 1m).

**Current behavior before PR:**
- The timer was hidden when an agent was already a member of the 
conversation, assuming that once an agent joined, the `waiting for help` 
phase was over.

- However, in escalation workflows an analyst may escalate a chat and 
remain a member while the channel returns to the `Looking for Help` 
state for another expert. In this case, the escalating analyst could not 
see the timer needed to track SLA requirements (e.g., creating a 
ticket after 10 minutes).

- Also, the mock server did not recompute
`livechat_looking_for_help_since_dt` when `livechat_status`
changes, leading to incorrect timer values (e.g., showing 2d
instead of < 1m after switching back to Looking for Help).

**Desired behavior after PR is merged:**

- The timer is displayed whenever the channel is in `need_help` 
and `livechat_looking_for_help_since_dt` is set, regardless of 
whether the current user is a member of the channel.
- The mock server now mirrors server-side behavior by updating
`livechat_looking_for_help_since_dt` when livechat_status changes,
prevents missing recomputations and ensuring consistent test
behavior.

task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851)


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