Creating a POS order with negative quantity to manually refund a product (without using the Refund action, e.g. when the original order is not in the POS) and then requesting an invoice produced a customer invoice (INV) instead of a credit note (RINV).

Steps to reproduce:
-------------------
* Open a POS session.
* Create a new order (do not use "Refund" from an existing order).
* Add a product with negative quantity to simulate a manual refund.
* Set a customer and request an invoice for the order.
* Pay the order (negative amount).

> Observation:
The system creates a customer invoice (INV) instead of a credit note (RINV).

Why the fix:
------------
* Invoice type was decided only from the `is_refund` flag, which is set only when the order is created via the Refund action. Manual refunds (negative qty) never had `is_refund` set, so they were treated as sales and got `out_invoice`.
* `_prepare_invoice_vals` now treats an order as a refund when `is_refund` is True or `amount_total < 0`, so `move_type` is `out_refund` for manual refunds and a RINV is created.
* `_get_invoice_lines_values` now uses the same condition (`is_refund or amount_total < 0`) to compute `is_refund_order` for the quantity sign. That way invoice lines keep positive quantities and the credit note has a positive total.

opw-5898700

Forward-Port-Of: odoo/odoo#248791

Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen.

### **Steps to Reproduce:**
1) Install the POS Restaurant app with demo data.
2) Open a Restaurant Session.
3) Click on 'Register' to create a Direct Sale.
4) Add a product (e.g., Water with Qty 2) and a customer (e.g., 'Billy Fox'). 
5) Click on 'Orders' from the navbar and load the recently created order. 
6) Update the quantity of Water from 2 to 5 and click on 'Orders' again.

### **Error:**
The quantity of Water is not updated, the order line still shows a quantity of 2.

Ref video: https://drive.google.com/file/d/1XR5W5Klyyll3KujirKb3UuAELjMcA7yD/view

### **Root Cause:**
Clicking on 'Orders' calls `syncAllOrders` (see [1]), which is responsible for updating the orders. However, `this.getPendingOrder()` returns null in this scenario, causing the orders array to be empty and the function to return early without syncing.

### **Fix:**
Override `updateSelectedOrderline` in `OrderSummary`. This method is
invoked whenever the Numpad modifies an orderline. By calling
`addPendingOrder` within this method, we ensure that Numpad modifications
are correctly registered. This allows `syncAllOrders` to properly sync
the updated order with the server when navigating away.

[1]- https://github.com/odoo/odoo/blob/7fd5f90fe8fce4de49ec10c683f92e7a3557981a/addons/point_of_sale/static/src/app/services/pos_store.js#L1485-L1512

opw-5405402

Forward-Port-Of: odoo/odoo#240366

**Steps to reproduce:**
1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time):
- Thursday: 20:00 to 24:00
- Friday: 00:00 to 04:00
2. Assign the above calendar to an employee.
3. Set the Employee’s Timezone to Asia/Kolkata (UTC+5:30).
4. Assign an active Overtime Ruleset to the employee.
5. When the attendance calendar is in Europe/Brussels TZ 
- Check-in: Jan 15, 15:30 CET
- Check-out: Jan 15, 23:30 CET

Expected Behavior: Worked Hours = 8.0, Overtime (Extra Hours) = 0.0 
Actual Behavior (Bug): Worked Hours = 8.0, Overtime = 4.0

**Bug Cause:**
1. The _update_overtime function normalized the Ruleset version periods using time.min for both the start and end of the day.
This forced the validity period of the rules to end exactly at 00:00:00 UTC on the final day.
2. The overtime recalculation logic failed to delete existing overtime records because the search domain was incorrectly computed.
Specifically, using relativedelta(SU) and relativedelta(MO(-1)) without the weekday= keyword argument did not shift the dates to the week boundaries.
This resulted in an empty or incorrect deletion range, leading to duplicated overtime hours as new records were layered on top of un-removed old ones.

**Solution:**
1. Modified the version_periods_by_employee mapping to use time.max (23:59:59) for the end of the version period.
This ensures that the ruleset remains active through the entire final calendar day in UTC, allowing shifts that cross the midnight boundary to be fully captured.
2. Corrected the date range logic by explicitly passing the weekday argument to relativedelta.
This ensures the domain correctly targets the full week window - from the preceding Monday to the following Sunday, ensuring all relevant stale overtime lines are purged before recalculation.
3. Updated Manual Edit Handling: Refined the logic to detect days with manual overrides or "To Approve" statuses before unlinking. If an attendance change triggers a recalculation on such a day, the system now replaces the manual entry with the mathematically correct value but flags the new record with a to_approve status for manager review.
4. Adjusted the expected overtime in test_weekly_overtime to 18.0 to correctly reflect the cumulative calculation of daily overtime (2h/day) plus the weekly overtime threshold reached on Friday.

Task: 5710273

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

Forward-Port-Of: odoo/odoo#245247

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#109790
Forward-Port-Of: odoo/enterprise#105040

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#104771

Currently some providers require a customer to be registered on the order because the email address needs to be sent with the request. We the order does not have a customer the payment cannot be made using that provider.

Step to reproduce:
------------------
- Set up Amazon payment services on a online pos payment method
- Set this method as the online payment method for a self and also set is as payment method of the pos
- Place an order in the self or without a customer on the normal pos
- Try to pay it
> Observation: When the page is redirected to provider's checkout page,
an error occurs: Signature mismatch

Why the fix:
------------
On a normal pos shop we are simply ensuring that a customer with an address mail is registered on the order if the provider of an online payment method requires customer identification.
- When selecting the payment method on the payment screen if the payment method is online, requires customer identification and there's no customer on the order, the validate order button will be unavailable and the customer button is highlighted.
- When there is a customer the validate button is highlighted
- When validating the order if the customer does not have an email it will not go through and warn the cashier that the customer needs an email. This behavior is similar to the present "Delivery" which, if the cashier disregarded all popups, will not have the validate button available until a cashier is registered. Also if the selected customer doesn't have an address it will show a popup upon validation.

We are not doing anything regarding the self order as using presets like "Delivery" is compatible since the information required filled by the customer creates a partner in the db and sets it on the order. This preset ensures we always have a partner.

Other preset don't but we don't want to block flows that are currently working.

The list of providers requiring customer identification can be extended.

opw-5406501

Forward-Port-Of: odoo/odoo#245016

__

## Short functional explanation of the error
When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page.

## Reproduction Steps
1. Go to Time off > Configuration > Time off Types and click on any time off type.
2. A smart button Allocations should appear with a number in it. Note the number and click on the button.
3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation.
4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now.
5. Go back to the Time off type page and look at the number on the Allocations smart button.

### Expected behavior
As the allocation we set is still valid, the number shouldn't have changed.

### Unexpected behavior
The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity.

## Origin of the issue
The domain of the allocations to take into account when computing the count of valid allocations is defined here:
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year.
The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above.
__
opw-5504272

Forward-Port-Of: odoo/odoo#250992
Forward-Port-Of: odoo/odoo#248482

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

Forward-Port-Of: odoo/odoo#242264
Forward-Port-Of: odoo/odoo#224298

When the product category valuation is set to `real_time` but the
company is set to `periodic`, the POS session closing was not posting
COGS entries as expected. If the product category valuation is set to
`real_time`, it should always prevail over the company setting. And if
no valuation is set on the product category, then the company setting
should be used.

Steps to reproduce:
-------------------
* Create a product category with `Inventory Valuation` set to
  `real_time` (Perpetual).
* Create a product in this category and make sure it is storable and has
  a cost price.
* Set the company `Inventory Valuation` to `periodic` (Periodic).
* Create a POS order with this product and pay it.
* Close the POS session.
> Observation: In the session no COGS entries are created for the sold
  product.

Why the fix:
------------
We adapt the `_search_valuation` to correctly fallback on the company
setting only if the product category valuation is not set. It was not
working before because in some cases the product had no company set
(it means that it is visible to all companies) and the domain was not
matching. To fix that we check that the current company matches the
search value, and if it does we also match all the products without
company set.

We also adapt the PoS code to use the `product_id.valuation` field to
filter all the stock_moves that should create COGS entries when
closing the session.

opw-5885960

Forward-Port-Of: odoo/odoo#247011

`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:

- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model

We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:

```
  File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
    if invoice.pos_order_ids:
       ^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
    recs._fetch_field(self)
  File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
    self.fetch(fnames)
  File "/c19-1/odoo/orm/models.py", line 3055, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
    field.read(fetched)
  File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
    raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:

```
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
    return super()._create_update_invoice_document_from_invoice(invoice, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
    document = remaining_documents._create_update_document(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
    result_document = self.create({
                      ^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
    records = self._create(data_list)
              ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
    field.create([
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
    self.write_batch(record_values, True)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.

[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590

opw-6000974

Forward-Port-Of: odoo/enterprise#109461

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109880
Forward-Port-Of: odoo/enterprise#102126

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/enterprise#109873
Forward-Port-Of: odoo/enterprise#109645

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

### Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

### Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

### Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/odoo#252568
Forward-Port-Of: odoo/odoo#252190

Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` 
is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report.

**Steps to reproduce:**
- Install the `l10n_be` module and switch to the `BE company CoA`.
- Navigate to `Invoicing > Configuration > Taxes` and open any tax (e.g., 6%).
- Replace the `Tax Grid` with `61` on the second line under `Distribution for Invoices`, then `save`.
- Navigate to `Customers > Invoices` and create and confirm an invoice using this `tax`.
- Navigate to `Reporting > Tax Report` and select the current month.

**Observation:**
- The report shows a warning: `The report contains negative amounts. This is normally not allowed and could cause the tax authorities to reject it.`
- Case `61` under `Taxes > IV Due` displays a `negative` value.

**Root Cause:**
At [1], all formulas under `IV Due` use a negative sign (-XX) except for case `61`, 
which uses `61` instead of `-61`. Since the concept of `inverted tax tags` was 
removed in v19 in PR [2], case `61` must follow the same sign convention 
as the other `IV Due` cases to ensure correct reporting behavior.

**Fix:**
This commit updates the formula of case `61` to `-61`, aligning it with the 
other `IV Due` lines. As a result, the VAT report no longer displays an incorrect 
negative amount for case `61` and prevents the related `warning` from appearing.

[1]:
https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/l10n_be/data/account_tax_report_data.xml#L497-L596

[2]:
https://github.com/odoo/odoo/pull/225252

opw-5866225

Forward-Port-Of: odoo/odoo#248961

Currently, an error occurs when the user opens the shop page.

**Steps to Reproduce:**

 - Install `website_sale_stock` module.
 - Go to `Settings` and enable `Product Variants`.
 - Create a `product template` of type `Goods`.
 - Enable `Track Inventory`.
 - In the `Sales tab`, disable `Sell when Out-of-Stock`.
 - In the `Attributes & Variants` tab, add one attribute with two values and save.
 - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants.
 - Go to `Website` > `Shop`.

**Error:**
`ValueError: Expected singleton: product.product()`

After [this commit], when opening the shop page, it calculates the quick add availability [1] 
for every product. It checks whether the product is sold out [2] to determine whether the quick 
add to cart button should be displayed or not. Since the product has no variants, it raises the 
error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4].

This commit ensures that if a product has no variants, it is treated as sold out. As a result, the 
quick add to cart button is not shown, as in the previous version.

[this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c

[1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39

[2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33

[3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41

[4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403

sentry-7287364112


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

Forward-Port-Of: odoo/odoo#250373

An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below.

Step1:
- install `crm` and `base_automation`
- Create a new automation rule for the `Activity` module and set the `Apply On` domain as below: `[("res_model", "=", "crm.lead"), ("state","=","done")]`
- An error will occur in the log when you open this record.

Step 2:
- Install `mass_mailing`
- Go to Email Marketing and create a record as below data
    - Recipients: `Contact`
    - Set domain as `[("vat_label", "=", 'test')]`
- An error will occur in the log when user open this record.


This issue occurred because the recently refactored commit [1] used `validate` of Domain for the domain instead of `search_count`. The `validate` method only checks the structure of the domain and does not verify whether the domain is actually executed or not.

This commit fixes the issue by reverting commit [1], restoring the previous behavior where the domain is evaluated using `search_count`.

[1]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b

sentry-7004977102

Forward-Port-Of: odoo/odoo#252379

## Steps to reproduce:

- Configure event registration with only free-text fields (no selection field).
- Open the POS, add an event ticket product, and fill in the registration form.
- Click Payment and validate the order.

## Issue:

- Registration answers were only sent to the backend when at least one selection-type question was filled.
- When no selection field was present, free-text answers were not synced at all.

## Reason:

- The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85

- This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75

## Fix:

- Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`.


task-5438565

Forward-Port-Of: odoo/odoo#250106
Forward-Port-Of: odoo/odoo#242465

### Steps to reproduce:
- Download Planning app
- From the top bar 'Employees' > 'Employees', create a new employee
- From the top bar 'Work Entries' > 'Work Entries', add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB)
- Click on any empty cell, you'll find the "Replace by Attendance" smart button replicated

> If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError**

### Cause of issue:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/hr_work_entry_enterprise/static/src/work_entries_gantt_model.js#L110-L138 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. 
https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17

### Fix:
Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`.

opw-5953671

Forward-Port-Of: odoo/enterprise#109823

Note about v19.1:
Since the bug isn't present in this version, we'll only merge the test.

**Description of the issue this PR addresses:**
Thread unread counters should reflect the actual backend state 
as soon as Inbox messages are loaded, not only after a new bus 
notification is received.

**Steps to Reproduce:**
- Log in as User A and User B.
- Ensure User A preferences set to Handle in Odoo.
- From User B, mention User A in the chatter of a record.
- From User A, Open the messaging menu, counter for that related thread 
is correct.
- Refresh the page.
- Open the messaging menu again, the thread now shows a grey badge 
instead of the expected unread counter.

**Current behavior before PR:**
- When loading Inbox messages, related `mail.thread` records 
(such as project.task) did not include unread counters in the store payload. 
As a result, threads that already had unread messages appeared as (grey badge) 
after a refresh, leading to an incorrect counter state.

- Additionally, frontend-only counter adjustments could sometimes lead to 
inconsistent or even negative unread values due to missing initial sync.

**Desired behavior after PR is merged:**
- Threads with existing unread messages now receive the correct counter state, 
when Inbox messages are fetched.
- This also prevents inconsistent or negative counter values caused by 
frontend-only updates.

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

Before/After (**on refresh**):
<img width="461" height="55" alt="image" src="https://github.com/user-attachments/assets/2fc57aba-049c-4129-95b1-1d2b2770ac66" />

<img width="469" height="57" alt="image" src="https://github.com/user-attachments/assets/111d10bb-2aec-4711-8f5a-af7f332021d8" />



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

Forward-Port-Of: odoo/odoo#247569

Description of the issue/feature this PR addresses:
Based on this feedback : [https://www.odoo.com/odoo/project.task/5436300 ](https://www.odoo.com/odoo/project.task/5436300%C2%A0)
When I got two versions with different working schedules, normally, in Attendance, the gant view should show the unavaibilities by putting in gray days you're not working.

As the feedback shows:-
. If you have two different working schedules on two different versions and two different occupations period (contract dates), it's working fine.
. If the two versions have the same occupation period (contract date), it's only considering the latest working schedule.
. If both versions are under the same contract, then it only shows the working schedule on the latest version. This is not what we expect 
Instead, it should show the correct working schedule for each period

Current behavior before PR:

Desired behavior after PR is merged:
. Modify _get_calendar_periods() method to return the correct working schedule for each period
. Fix version_date to use the specified date instead of the creation date.
. Add the corresponding tests

task-5473047

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

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#110013
Forward-Port-Of: odoo/enterprise#107760

Step to reproduce:
- Install point_of_sale
- Enable Identify Customer on the Card payment method
- Create an order with a customer and refund it
- Use Card as the payment method
- Close the POS session
- Go to Invoicing → Customers → Payments

Observation:
- Two payment records are created
- Both payments have payment_type = inbound
- The refund payment should be outbound

Cause:
- When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records
- The method does not adjust payment_type for refund transactions

Fix:
- Add helpers to swap destination and outstanding accounts
- Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority
- Ensure refund payments are created as `outbound`

few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e
https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228
https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8

opw-5437456


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

Forward-Port-Of: odoo/odoo#247760

…lues landed cost sbc

**Problem:**
account move line created from a landed cost on a  subcontracted 
receipt do not take into account already out quantity.

**Steps to reproduce:**
- create a tracked product with avco auto category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product 
with the same partner as the subcontractor of the bom
- validate the receipt
- create and validate a delivery for 4 unit of your product
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- select the valuation smart button
- a 6$ svl was created (which is correct because 6 out 10 products
of the receipt are still in stock)
- click on the book widget to open the account move view

**Current behavior:**
Only two account move lines were created both with a value 
of 10
One crediting sotck interim received
On debiting stock valuation

**Expected behavior:**
4 extra account move lines (all with a value of 4) should have been 
created to compensate the out quantity like it is the case for 
non subcontracted product.
One debiting stock interim delivered
One crediting stock valuation 
One debiting expenses
One crediting stock interim delivered

**Cause of the issue:**
_is_in() will return false for the move of a subcontracted receipt
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185
This is wanted and happens because _should_be_valued()
will return true when called on the subcontracted location
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_account/models/stock_move.py#L129

As a consequence, qty_out stays 0
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185-L186
and we do not append the values for the extra amls 
inside _create_account_move_line()
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L465-L466

**fix:**
if we make sure the the adjustment line is linked to the move 
of the MO instead of the move of the receipt, this problem does 
not happen because _is_in() returns true for the move of the MO. 
Also in this case we don't need _get_stock_valuation_layer_ids()
which was introduced by this PR https://github.com/odoo/odoo/pull/166107
to solve the same issue. 
That is because the move used in button_validate is the move linked
to the adjustment line, which will, after this fix, be the one of 
the MO, so we can directly take its stock valuation layers.

opw-5723126

Forward-Port-Of: odoo/odoo#251972
Forward-Port-Of: odoo/odoo#248231

## Description of the issue/feature this PR addresses:
If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)
![image](https://github.com/user-attachments/assets/7747b0ee-fb36-43d1-bfde-5f3ad29ce77d)

First column: Client ref
Second column: committment date
Third column: Customer

## Current behavior before PR:

When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. 
The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d  format .
This is an error because that column does not contain a date .
The reason is that check_patterns when convert the pattern to reg ex using
`def to_re(pattern):`
on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex .


## Desired behavior after PR is merged:
No error should appear and the correct date format from the right date column should be guessed 



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

Forward-Port-Of: odoo/odoo#252488
Forward-Port-Of: odoo/odoo#196477

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:

- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model

We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:

```
  File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
    if invoice.pos_order_ids:
       ^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
    recs._fetch_field(self)
  File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
    self.fetch(fnames)
  File "/c19-1/odoo/orm/models.py", line 3055, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
    field.read(fetched)
  File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
    raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:

```
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
    return super()._create_update_invoice_document_from_invoice(invoice, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
    document = remaining_documents._create_update_document(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
    result_document = self.create({
                      ^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
    records = self._create(data_list)
              ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
    field.create([
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
    self.write_batch(record_values, True)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.

[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590

opw-6000974

Forward-Port-Of: odoo/enterprise#109461

### Step to reproduce:

- Take a user with only basic inventory user access rights
- Create a new delivery, add a stock move, try to save the record
#### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids

This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module.

Cause of the issue:

Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53
Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error.

runbot-240937

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

**Steps to reproduce:**
- Install Expenses
- Activate "Incoming Emails" in the settings
- Configure the expense Alias
- Configure an "Incoming Mail Server"

- Create a Branch for a company
- Create a User:
  * Email Address: [an existing email address]
  * Allowed Companies: [the parent company + the branch company]
  * Default Company: [the branch company]
  * User Types: Internal User
- Create an employee for the user in the parent company

- From the email address, send a PDF to the expense alias

**Issue:**
The expense is not created in the database due to a UserError: "Incompatible companies on records".

**Cause:**
When the email is received and treated, the system tries to create an expense.
From the email address, it retrieves an employee that is linked to the expense.
For the company of the expense, if a user is linked to the employee, it takes the default company of the user.
Otherwise, it takes the company of the employee.
In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check.

**Solution:**
Always use the company of the employee, even if there is a user linked to the employee.

opw-5346809




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

*:website_event, website_slides

Before this commit, long titles in blog posts, events, and eLearning courses
caused horizontal page overflow with an unnecessary scrollbar.

This commit ensures long titles wrap correctly, preventing horizontal scrolling
while keeping the text intact.

Steps to reproduce the issue:
1. Install blog, events and eLearning modules
2. Add long titles to a blog post, event and course
3. Observe the text overflow causing a horizontal scrollbar

 | Before  | After |
   | ------------- | ------------- |
   Blog Module
   | <img width="1631" height="422" alt="image" src="https://github.com/user-attachments/assets/8faa6e22-ac7a-4b59-9b54-f674978dc931" /> | <img width="1633" height="420" alt="image" src="https://github.com/user-attachments/assets/66a2de39-95e2-4871-827e-4965e571ed33" /> |
   | <img width="882" height="394" alt="image" src="https://github.com/user-attachments/assets/b807245f-0d84-47b6-a65b-ce0005037c50" /> | <img width="888" height="385" alt="image" src="https://github.com/user-attachments/assets/3c35cd12-08f2-4775-9c4d-d9d6e4555f00" /> |
   Event Module
   | <img width="1335" height="398" alt="image" src="https://github.com/user-attachments/assets/7d3af438-58f7-4a56-acd0-46e6dc90fe2a" /> | <img width="981" height="376" alt="image" src="https://github.com/user-attachments/assets/fb419243-4c0d-4c72-97ec-47812f81b378" /> |
   E-Learning Module
   | <img width="1534" height="317" alt="image" src="https://github.com/user-attachments/assets/3b03835c-c72b-40fb-bbf0-8fc91d3fafe5" /> | <img width="1423" height="393" alt="image" src="https://github.com/user-attachments/assets/551e332d-25af-453a-bfda-b669b04fdd39" /> |



task-[5457179](https://www.odoo.com/odoo/project/974/tasks/5457179)





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

The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.

Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version. 

```
Traceback (most recent call last):
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
    result = records.read(fields, **read_kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
    return self._read_format(fnames=fields, load=load)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
    self._read(fnames)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
    self.env.cache.insert_missing(fetched, field, values)
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
    field_cache.setdefault(id_, val)
MemoryError
```

opw-5921410
upg-3891767