project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

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#261380
Forward-Port-Of: odoo/odoo#260387

project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

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#261380
Forward-Port-Of: odoo/odoo#260387

Problem:
The abandoned cart reminder can crash when Click & Collect is enabled. The stock availability check reaches website_sale_collect._get_product_available_qty(), which assumes request.cart always exists.

Solution:
Safely access the cart with hasattr and fall back to the existing no-cart behavior when it is unavailable.

Why:
Scheduled actions may have a request object without a frontend cart. This fix prevents the cron from failing while sending abandoned cart reminders.

Reproduction Steps:
- Configure the website with a warehouse.
- Create/publish a delivery method with delivery type “Pick up in store”. Confirm the website has both
warehouse_id and in_store_dm_id
- Create a cart from the website shop using a storable product that has does not have "Sell When Out of Stock" turned on.
- Leave the cart without checking out.
-  On the generated quotation set the date to the past, but also the date must be after the website.send_abandoned_cart_email_activation_time
- Run the abandoned cart reminder scheduled action for the eligible abandoned cart with a storable product.

Related Ticket:
opw-6133986

Related PR:
https://github.com/odoo/odoo/pull/242864

Forward-Port-Of: odoo/odoo#261885

project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

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#261380
Forward-Port-Of: odoo/odoo#260387

Problem:
The abandoned cart reminder can crash when Click & Collect is enabled. The stock availability check reaches website_sale_collect._get_product_available_qty(), which assumes request.cart always exists.

Solution:
Safely access the cart with hasattr and fall back to the existing no-cart behavior when it is unavailable.

Why:
Scheduled actions may have a request object without a frontend cart. This fix prevents the cron from failing while sending abandoned cart reminders.

Reproduction Steps:
- Configure the website with a warehouse.
- Create/publish a delivery method with delivery type “Pick up in store”. Confirm the website has both
warehouse_id and in_store_dm_id
- Create a cart from the website shop using a storable product that has does not have "Sell When Out of Stock" turned on.
- Leave the cart without checking out.
-  On the generated quotation set the date to the past, but also the date must be after the website.send_abandoned_cart_email_activation_time
- Run the abandoned cart reminder scheduled action for the eligible abandoned cart with a storable product.

Related Ticket:
opw-6133986

Related PR:
https://github.com/odoo/odoo/pull/242864

Forward-Port-Of: odoo/odoo#261885

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#241827

Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#261529
Forward-Port-Of: odoo/odoo#249793

This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills.

This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common).

To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials

How to reproduce it:
- Install l10n_co_dian module
- On CO company with all required DIAN configuration set
- Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected.
- Click on acknowledge receipt, it should be rejected
- Complete information to be accepted and again click on acknowledge receipt
- A traceback appear

Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback

opw-6104541

When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on
`unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time.

This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models.

### speedup

In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model.

| Nbr linked unreconciled lines| Before PR | After PR | 
|:----------------------------:|:---------:|:--------:|
|              702             |    40s    |   3s     |
|              2000            |    40s    |   4.47s  |
|              10000           |    40s    |   11.28s |

Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch.

### memory

For the 702 unreconciled lines case, the memory consumption goes
 - 2.2 Gb -> 200Mb.