Description of the issue/feature this PR addresses:
This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745
In the above ticket, an employee Norbert Loibl had an accrual allocation
from Feb. 2023 to May 2024. Since then, all his allocations have been
regular allocations, so he is no longer accruing vacation days. But,
Norbert’s future leaves do not get counted against the “Days Available”
displayed on his Time Off Dashboard.

Current behavior before PR:
If an employee had an accrual allocation (of the relevant type, e.g. 
past vacation allocations won’t affect sick leave) at any point in 
time, their future leaves do not get counted against the “Days 
Available” on their Time Off Dashboard.

Desired behavior after PR is merged:
If an employee has an accrual allocation between today’s date and the
date of a future leave, that future leave does not get counted against 
the “Days Available” on their Time Off Dashboard. That way, we 
will count a leave against “Days Available” unless there is a 
possibility of accruing more days off before the leave.

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

Forward-Port-Of: odoo/odoo#241216
Forward-Port-Of: odoo/odoo#238977

Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done

Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```

Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511

According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554

Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency. 
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.

opw-5373018

Forward-Port-Of: odoo/enterprise#101774

Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records.

Introduced by [1]

This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open.

[1] https://github.com/odoo/odoo/pull/226312

Task~5387553

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

**Steps to produce:**
- Install the `Sales` module.
- Create a Sales Order.
- Add a section and some products under it.
- In the section menu (three dots), click Set Optional.
- Again, open the section menu and click Unset Optional.

**Issue:**
- After unsetting the optional, the product amounts remain `0`.

**Root cause:**
- At[1], when setting options, both quantity and price are reset to `0`.
- When unsetting optional, only the quantity is restored, leaving the price at `0`.

**Solution:**
- When unsetting optional, explicitly trigger the onchange on the field `product_uom_qty` using `.update()`.

[1]https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L138-L140

Before:
<img width="1198" height="476" alt="image" src="https://github.com/user-attachments/assets/01dee1d6-2870-4222-8a6c-724fbfff8da1" />

After:
<img width="1214" height="453" alt="image" src="https://github.com/user-attachments/assets/63ed4eb4-27cf-4b15-a957-c28a46a3ca42" />

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

**Description of the issue/feature this PR addresses:** 
In Odoo 19, file attachments added to activities (for example, on Project Tasks) were not visible after saving the activity. Although the attachment was correctly stored, it was not rendered in the activity chatter.

The root cause was that the activity note containing the embedded attachment placeholder `(<span data-embedded="file">) `was rendered as raw HTML, bypassing the HtmlViewer logic that mounts embedded file components.

As a result, the attachment card and download link were missing from the UI.

 **Current behavior before PR:**
Attachments can be added to an activity and are saved correctly. After saving the activity:

 * The attachment card is not displayed.
* No download link appears in the activity chatter.
* The activity note is rendered as raw HTML, so embedded file components are never mounted.

**Desired behavior after PR is merged:**
 
* Attachments added to activities are correctly displayed after saving.
* The attachment card and download link appear in the activity chatter.
* Activity notes are rendered using the HtmlViewer component, ensuring embedded files are properly mounted and displayed.
 
 **Related issue** Closes #238967


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

Issue
-----
When creating a sale for a future date, the purchase of the product is not created for (sale date) - (vendor lead time).

More generally, RR procurements are not created to be as close to the delivery date as possible.

Steps to reproduce
-----
- Create a product with a reordering rule
- Create a delivery
	- Scheduled Date: 31/12/2025
- Mark as Todo
- Open the created incoming picking

> The IN picking's scheduled date should be 31/12/2025 (no lead time)

Cause
-----
The IN is created using the date of the procurement, which is created in

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L732-L741

While it makes sense for scheduled replenishments to use the `lead_horizon_date` returned by `_get_orderpoint_procurement_date`

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L793-L794

For procurements created by a delivery, we want to push the IN date to as close to the delivery date as possible to minimize storage costs.

Solution
-----
Procurements created by replenishments are created by `action_replenish`

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L342-L348

(same goes for automatic ones)

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L368-L370

However, when we plan the delivery, we go through SM's `trigger_scheduler`

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_move.py#L2411

This means we can give a context key to the `_procure_orderpoint_confirm` call to indicate that we want to use the orderpoint's `deadline_date` (which was introduced by 71adec9).

https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/stock/models/stock_orderpoint.py#L95-L99

-----
Ticket:
opw-5223991

Steps to reproduce:
----------------------------
1. Install `hr_appraisal` module.
2. Go to Appraisals and open any new appraisal
3. Change or add text in Employee's feedback and Manager's Feedback
4. Confirm the appraisal
5. Give it a Final Rating and click Mark as Done
6. Click the Reopen button

Observation:
----------------------------
The changes made to the feedback fields are lost after reopening the appraisal, feedback reverts to the template values.

Issue:
----------------------------
In the feedback compute methods, the code was unconditionally assigning the appraisal template when the appraisal was in the new state. https://github.com/odoo/enterprise/blob/036002fa6415c796a9b73efa5ea85c582fafb7c6/hr_appraisal/models/hr_appraisal.py#L171-L187

Solution:
----------------------------
Preserve existing feedback when reopening an appraisal:
When an appraisal is reopened, any feedback already entered by the Employee or
Manager should remain unchanged.

Reset feedback only when the Manager resets the appraisal:
If the appraisal is in the Pending stage and the Manager chooses to reset it,
then the feedbacks should be restored to the default template values.

opw-5404776

Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the quantity to produce on the parent MO causes the child MO’s quantity to roduce to update incorrectly. This is because the new quantity to produce on the child MO is calculated with quantities in different UoMs.

Purpose: To ensure that the child MO’s quantity to produce updates correctly when the parent MO’s quantity to produce is updated. This is achieved by making sure the quantities that get added together are both the same UoM, in this case the product’s UoM.

Steps to Reproduce on Runbot:
1. Create product_a with the MTO route and UoM set to pack of 6.
2. Create a BoM for product_a that creates 1 pack of 6 products.
3. Create product_b.
4. Create a BoM for product_b that creates 1 unit and uses 3 units of product_a. Make sure the component line shows 3 units instead of 0.5 pack of 6.
5. Create a manufacturing order for 1 unit of product_b and confirm it.
6. There should be a child MO for 0.5 pack of 6 of product_a.
7. On the parent MO update the production quantity to 2 units.
8. Observe that the child MO is now for 3.5 pack of 6 instead of 1 pack of 6.

opw-5414085

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

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

Forward-Port-Of: odoo/enterprise#102910
Forward-Port-Of: odoo/enterprise#102859

## Issue 1:

Purchasing a Kit and validating the receipt sets the value of the pol to all the exploded kit moves. It should rather explode that valuation by taking care of the defined and undefined cost_share as well as the kit
proportions.

### Steps to reproduce:

- Create a kit product with 2 bom lines:
- 1 x COMP1, cost_share: 20%
- 2 X COMP2, cost_share: 80%
- Create and confirm a PO for 1 x your kit prodcut for 1000$
- Validate the receipt
#### > Both moves are valued as 1000$

## Issue 2:

The cost_share of a bom corresponding to a given variant should sum up to 100% and the valuation of kit product via a purchase order should be distributed among its exploded moves.

Currently, the constraint is that the sum of all cost_share's used on the bom sum up to 100%:
https://github.com/odoo/odoo/blob/7038c786ff0da782dd1895f124c272d5617379fc/addons/purchase_mrp/models/mrp_bom.py#L12-L22
and if not all lines are used by a product variant it value will be lost in the process.

### Steps to reproduce:

- Create a bom:
  - 1 X COMP1 cost share 50%
  - 1 X COMP2 cost_share 50% for White
  - 1 X COMP3 cost share 50% for Black
#### > User error: The total cost share for a BoM's component have to be 100

opw-4806023

When using a promotion program applied only on specific products with
tax included prices, the discount value was incorrect.

Steps to reproduce:
-------------------
* Create a product with a price of 100$ and tax of 10% included
* Create a promotion program with:
  - Apply on: Specific Products (the product created above)
  - Discount Type: $ Fixed Discount
  - Discount Value: 10$
* Open PoS and add the product to the order
* Apply the promotion code
> Observation: The value of the discount is 9.09$ instead of 10$

The same steps also applies to the discount reward applied on the whole
order.

Why the fix:
------------
When computing the discountable amount for the promotion it would take
the amount excluding tax instead of the base price. The base price
should be the unit price of the product multiplied by the quantity. As
it was before here :
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112
To do so we modified the accounting helpers to provide this value
instead of computing it manually.

opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task)
opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task)

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Forward-Port-Of: odoo/enterprise#102364

Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0.

**Steps to replicate:**
* Install `accountant` and `hr_expense` with demo.
* Enable analytic accounting from settings.
* Expense > Approve and Post submitted expense
* Analytic Accounts > Nebula > Vendor Bills

**Observed Behaviour:**
* Even though the smart button shows a count of 1 there are no records displayed in the list view.

**Root cause:**
* After PR [1], vendor bills were changed to receipts. Since [2] counts receipts too, the button shows a different count than the list view, as [3] does not include receipts.

**Solution:**
* Show purchase receipts along with the vendor bills which correctly matches with the vendor bill count.

[1]:
https://github.com/odoo/odoo/pull/217758
[2]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L36 
[3]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L68

opw-5359320