This fix prevents a mail template rendering test from crashing on Ubuntu 22.04. It improves the reliability of automated checks for the mail module without changing customer-facing behavior.

The image cropping tool now handles cases where a large image is still loading and the user closes the cropper. This prevents an error message and keeps editing smooth when working with large images.

**Problem**:
Loading large images into the cropper takes time. Closing the cropper early causes `this.imageRef.el` to be `null` or `this.initialSrc` to be `undefined`, leading to a traceback.

**What happens**:
1. Add a large image.
2. Click "Crop".
   - This triggers `show`.
   - While `loadImage` is still unresolved due to image size.
3. Click "Discard" to close the cropper before image loads.
   - **Issue**: `this.imageRef.el` is `null` and `this.initialSrc` is `undefined` as the component is destroyed but `loadImage` has not resolved yet, when it is resolved a traceback will be appear.

**Solution**:
Add a lifecycle flag as full mounting of the cropper might take time.

**Steps to Reproduce**:
1. Add a large image.
2. Open cropper.
3. Close cropper before image loads.
   - **Issue**: Traceback.

opw-4607020

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

This fix prevents an error from occurring when the text selection is outside the editable area during a collaboration reset. It helps keep the HTML editor stable for users working with collaborative editing features.

Purpose of this PR:

- Check `isSelectionInEditable` before `setSelection` to avoid error when selection is outside the editor.

task-4639982

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

This fix removes ambiguity in a Point of Sale test product name so automated checks select the intended item consistently. It helps prevent false test failures related to rounding validation, improving confidence in release quality without changing user-facing behavior.

Before this commit:

The test `test_rounding_half_up` do un-consistantly fail on the `totalIs("1.20")` check.
According to the screenshot, the total value is 1.25

This may be related to a rounding issue, but I suspect that another test product is wrongly selected instead.
The test select a product with a name containing `Product Test 1.2` this is expected to select the product with the exact same name. But I do suspect that it can also sometime wrongly select the product `Product Test 1.25` as it starts the same.

After this commit:
The name of the product is modified in the demo data and test to avoid ambiguity with the contains operator

Note: I don't really know why the issue start to happen only now

rb-161265

Fixed an issue where invoices could not be sent by email when the main invoice customer had no email address. The system now checks the selected email recipients instead, allowing invoices to be sent to other contacts with valid email addresses.

If the invoice partner has no email address set, you can't send out the invoice by email to other contacts. Check email for contacts in the mail_partner_ids field instead of invoice partner and send to emails existed.

opw-4624587


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

This fix updates an internal sales manufacturing test so it can run reliably even when sample data is not installed. It helps prevent false test failures and supports smoother maintenance of the sales and manufacturing integration.

The base.group_multi_company group is needed when the test is run without the demo data. Adding this group allows the stock.stock_location_customers location to be added to the stock rule’s search domain. This location is necessary for the stock rule to be found.

Runbot error: 161249

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

A timing issue caused an automated timesheet check to fail when it ran on Sundays. The date selection now uses the correct Monday so the overtime validation test remains reliable throughout the week.

This test tour fails on sunday.

Reason:

- Here in the test create timesheets in previous week to check overtime in timesheets.
- The formula works as today - current week day --> gives monday of this week
- But on when it sunday it gives monday of previous week.
- Timesheets are further created the previous weeks if given monday.
- But we only go one week previous to check

Fix:

- Selecting next monday if weekday is sunday as we go back one previous week in tour.

task-4667966

Description of the issue/feature this PR addresses: Current behavior before PR:  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202636

Description of the issue/feature this PR addresses: 

Current behavior before PR: ![image](https://github.com/user-attachments/assets/75f9e251-b840-4910-b1f5-22afa1f7fcdd)

Desired behavior after PR is merged: ![image](https://github.com/user-attachments/assets/0e12c8b0-6d3a-484a-a12d-2827e70362c3)



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

Forward-Port-Of: odoo/odoo#202636

The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN". However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation. In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done. --- ## BEFORE https://github.com/user-attachments/assets/7

The "Lot / SN" column is redundant with the "Pick From" column. When Pick From is displayed, we can hide the "Lot/SN".

However, if the user does not have the lot/serial number in a quant, they still need a way to select it, so we allow for a quant creation.

In order to not re-introduce the bug fixed by this commit: 60d95aa8304c11698e49336391d98926861e640d , we overwrite the name_create to return False, aka no action is done.

---

## BEFORE
https://github.com/user-attachments/assets/7e6c5a6a-ed86-4564-bcb5-51c94a5a4ae4

- Selecting a SN is very fast
- We can easily use an unavailable SN
- The unavailable SN is taken from a quant without lot
- Lot is displayed twice (pick from & lot/sn)


## AFTER
https://github.com/user-attachments/assets/f5bd7cc6-d77e-410c-a1aa-8ad6ba6d0020

- Selecting a SN is a bit harder
- Selecting an unavailable SN is even more complicated
- The unavailable SN is taken from a quant with its lot


OPW-4485159

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

Forward-Port-Of: odoo/odoo#202778
Forward-Port-Of: odoo/odoo#199630

When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`. However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill. Steps to Reproduce: 1. Create a vend

When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`.

However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill.

Steps to Reproduce:
1. Create a vendor bill where the vendor is set to your own company.
2. Try to access the vendor bill with a user who does not have `"Employees / Officer: Manage all employees"` access rights. Issue: An error occurs because the user lacks permission to check the related `employee_ids` for the vendor.
Refer to this [video](https://drive.google.com/file/d/1hIUTbNYhZxT4aOtNq8XE1z7uy7K_HJM1/view) for clearer steps.
opw-4539017

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

Forward-Port-Of: odoo/odoo#202033

#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components

#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues.

Issue 1
-----
When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity.

Issue 2
-----
When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables.

Commit breakdown
-----
- Commit 1 (handle component quantities - first ticket):
  - use the correct exploded value for the quantity (divided by the original quantity as the ratio isn't done for the top-level bom)
  - update test_update_mo_from_bom_with_kit with correct values
  - extend test_update_mo_from_bom_with_kit for when the kit components' quantities are updated
- Commit 2 (handle components for specific variants - second ticket):
  - adapt the filtering of bom lines to keep them based on the kit's attribute instead of the end product one's
  - add a new test_update_mo_from_bom_with_kit_vraiants
- Commit 3 (handle confusion of multi-variants/UoM kits - additional issues):
  - change bom_lines_by_id to a defaultdict to consolidate quantity of components
  - update test_update_mo_from_bom_with_kit to test for multiple UoMs
  - update test_update_mo_from_bom_with_kit_variants to test for multiple variants

-----
Tickets:
opw-4473337
opw-4480039

Forward-Port-Of: odoo/odoo#196227

Description of the issue/feature this PR addresses: Odoo Individual Contributor License Agreement Current behavior before PR: Odoo Individual Contributor License Agreement Desired behavior after PR is merged: Odoo Individual Contributor License Agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202642

Description of the issue/feature this PR addresses:  Odoo Individual Contributor License Agreement

Current behavior before PR:  Odoo Individual Contributor License Agreement

Desired behavior after PR is merged:  Odoo Individual Contributor License Agreement




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

Forward-Port-Of: odoo/odoo#202642

Steps to reproduce the bug: - Install accounting - Go to reporting, Invoice analysis - Select Product Quantity, Untaxed Total and Average Price in Measures Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price. Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price. This is because the override of the read_group in the account.account_invoice_report in case of ave

Steps to reproduce the bug:
- Install accounting
- Go to reporting, Invoice analysis
- Select Product Quantity, Untaxed Total and Average Price in Measures

Traceback is thrown that the field prive_subtotal is used twice for the combination Untaxed total and Average price.
Another traceback is thrown that quantity field is used twice for the combination Product Quantity and Average price.

This is because the override of the read_group in the account.account_invoice_report in case of average price in the fields it add fields of quantity and price_subtotal. By default the fields are added with the default agg, so they are as <field>:sum. And the Untaxed Total and Poruct Quantity by default add both quantity and prive_subtotal as well. So they are duplicate columns to show on pivot and view crashes. The override of the read_group was introduced in d741788306.

opw-4638089

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#201155

Before this commit: ------------------------- When increasing the quantity of a combo product before adding it to the cart, only `1 unit` was added due to a hardcoded quantity value. After this commit: ----------------------- - The hardcoded quantity of `1` was removed. - The selected quantity is now correctly added to the cart, preserving user input. Task-4592610 Forward-Port-Of: odoo/odoo#199160

Before this commit:
-------------------------
When increasing the quantity of a combo product before adding it to the cart,
only `1 unit` was added due to a hardcoded quantity value.

After this commit:
-----------------------
- The hardcoded quantity of `1` was removed.
- The selected quantity is now correctly added to the cart, preserving user
  input.

Task-4592610

Forward-Port-Of: odoo/odoo#199160

Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill. To reproduce this issue: 1) Install account 2) Create a Bills record from vendors 3) Change the `Auto-Post` value to `at date` from `other info` 4) Now remove the `Accounting Date` Error:- ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` When the user removed the date value, a compute method will be triggered in which a comparison is done

Currently, a traceback is occurs when the user tries to remove the date value, while creating a Bill.

To reproduce this issue:

1) Install account
2) Create a Bills record from vendors
3) Change the `Auto-Post` value to `at date` from `other info` 
4) Now remove the `Accounting Date`

Error:-
```
TypeError: '>' not supported between instances of 'bool' and 'datetime.date'
```

When the user removed the date value, a compute method will be triggered
 in which a comparison is done between the record date and the today value.

However, the user removed the record's date value,
which leads to the above traceback from the below line

https://github.com/odoo/odoo/blob/2adabe7321f26e67eea9853460948cbd4ac10a4a/addons/account/models/account_move.py#L626-L627

sentry-6402545255

Forward-Port-Of: odoo/odoo#202057

Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438

Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop.

This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries.

Benchmarks:

|num res.partner | time before | no. queries| time after | no. queries after|
|-----|-----|----|------|----|
| 80 | ~18s | 80 | ~0.4s | 1|

Forward-Port-Of: odoo/enterprise#81438

Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.t

Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation).

This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole.

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Forward-Port-Of: odoo/enterprise#80851
Forward-Port-Of: odoo/enterprise#78781

If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81904 Forward-Port-Of: odoo/enterprise#81325

If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas.

Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#81904
Forward-Port-Of: odoo/enterprise#81325

Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - P

Before this PR:
- The computation used `start_yearly_period` as the start date.
- This caused incorrect depreciation calculations when an asset was disposed of early.
- Example:
  - Prorata Date: 01/01/2025
  - Disposal Date: 20/02/2025
  - Computed Days: 326 (incorrect, should be 20)

After this PR:
- `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`.
- Ensures depreciation is calculated only for the valid period before disposal.
- Example:
  - Prorata Date: 01/01/2025
  - Disposal Date: 20/02/2025
  - Computed Days: 20 (correct).

OPW: 4599614

Forward-Port-Of: odoo/enterprise#81888
Forward-Port-Of: odoo/enterprise#80214

Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depen

Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet`
after creating a helpdesk ticket.

Steps to generate an error:
- Create a database without a demo and install helpdesk_sale_timesheet.
- Create a helpdesk ticket.
- Now try to uninstall sale_management (Sales).

Error `KeyError: 'helpdesk.ticket.sale_line_id'`

This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet`
field (see [1]), which is a depends field of the  `compute_sale_line_id` method, which is the compute
method of the field sale_line_id (see [2] and [3]) in the helpdesk ticket.

In helpdesk code line [4] tries to update the value of the field `use_helpdesk_sale_timesheet` since this
field is related to the helpdesk ticket (see [1]) value of this field also changed in the helpdesk ticket,
and the value was changed the compute method trigger because this field depends on the compute method.

This commit will solve the above issue by executing an SQL query instead of writing the team
field so it doesn't trigger depending on that field.

[1]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L27 [2]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L31-L38 [3]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L77-L78 [4]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk/models/ir_module.py#L15

sentry-6308112739

Forward-Port-Of: odoo/enterprise#81008