Currently, an error occurs when the user checks the report line errors.

**Steps to Reproduce:**

 - Install the `l10n_hk_hr_payroll_empf` module with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`.
 - Create a record by setting the `Scheme` and adding a `contribution line`.
 - Ensure that the employee and payslip fields are empty in the contribution line.
 - Click on `Validate`, then click on the `error icon` on the report line.

`ValueError: Expected singleton: hr.version()`

This error occurs when the user manually adds a line and checks the errors on it.. The system 
attempts to open the employee record from the version [1], but the version is not set [2] on the 
line because there is no employee. And it raise the error [3].

This commit ensures that when checking errors, if the version is not set on the line, a UserError 
is raised, prompting the user to set the employee on the line. It also corrects a typo in the status 
message.

[1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219

[2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156

[3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

Forward-Port-Of: odoo/enterprise#116607

The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency

Steps to reproduce:
1. Install Sales
2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN
3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN
4. Go to Sales > Products and create a new combo product "test"
5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$
6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001)
7. Change the pricelist to MXN and update prices
8. The total is ~MX$10,018 (it should be ~MX$186,682)

Issue:
The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted

Solution:
Convert the extra price of the combo product to the sale order's pricelist currency

opw-6192935

Forward-Port-Of: odoo/odoo#266172
Forward-Port-Of: odoo/odoo#265008

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243).

To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically.

However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge.

To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`).

This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16.

Task-5999878

Forward-Port-Of: odoo/enterprise#109379

# How to reproduce
- Install the Events, Porject & CRM apps
- Create two event A & B with tickets that can be purchased
- Go to Events > Configuration > Lead Generation
- Create a Lead Generation Rule with :
	- Create : Per Order
	- When : Attendees are created
	- Event : None
- Create a new quotation with two lines :
	- Product : Even Registration for event A 1st, then B
- Confirm the SO

# The problem
A traceback will appear

# Cause of the issue
When confirming the SO, we create `event.registrations`s that will check for
lead generation rules and create or update `crm.lead`s accordingly :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35

We will then group the registrations by leads & grouping model :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166

For all groups, if the lead does not exist, we create one :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187

`_get_lead_values()` works fine with multiple `event.registrations`s, but crashes
when those registrations does not have all the same event, which is our case :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170

# Proposed solution
Since we have multiple events and leads are associated to a single event :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11

We group the registrations by event and create multiple leads accordingly

opw-6167518

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

Forward-Port-Of: odoo/odoo#265017

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#265639
Forward-Port-Of: odoo/odoo#262591

**Steps to reproduce**
- Have user A with Sign admin rights and user B without Sign rights.
- With user A, create a sign request activity on a record that user B can access. Send the signature request.
- With user B, try to access the record. -> AccessError when trying to fetch the chatter.

**Cause**
By default, users get access to all the activities associated to records they have access to (see `_search` of `mail.activity`). This is an issue since some of the fields added in `_store_activity_fields` for the sign request activity display might not be accessible for a user with access to the activity.

**Change**
Use `sudo` to be able to display the activity, even if the user doesn't have access to the sign request.
Also, in that case, `can_write` should be `False` in order to hide the action buttons of the activity, which trigger access errors when trying to make operations on the sign request.

Another related change is to create the activity for the user creating the sign request, this avoids falling back on the `user_id` of the record associated with the activity and makes sure the activity's user has access to the sign request.

opw-6157455

**PROBLEM**
In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case.

**STEP TO REPRODUCE**

1. Install l10n_pe_edi
2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding
3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means).
4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount.

**CAUSE**
We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues.

opw-6010388

Forward-Port-Of: odoo/enterprise#113689

### Steps to reproduce:

- In the settings enable: Multi-steps routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with a bom using the MTO Route
- In the Miscellaneous tab of the bom tick Batch Size and set it to 2
- Create and confirm a sale order for 6 units of P
#### > Three MO's are created but only the last one will update the quantities of the delivery at validation of the production.

### Cause of the issue:

The `move_dest_ids` of the `move_finished_ids` is only set on the last of the three productions. That is only the last MO is properly chained to the delivery via an MTO chain. This happens because the `move_dest_ids` field of the `mrp.production` model is a `One2Many` field: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L223-L224 Which implies that each move can be linked to at most one mrp.production via the `created_production_id` field. However, if you have set a batch size on your bom, it is expected for a single move to create multiple mo's. While the `move_dest_ids` of each of these MO is appropriately set in the create vals to be the mto `stock.move` of the delivery, due to the nature of the `created_production_id` field only the *last* mo will created with a set `move_dest_ids` as this is the only record that will be set as `created_production_id`. However, after the creation of these MO's, the related `move_finished_ids` will be recomputed:
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1089-L1093 However, the `move_dest_ids` of the created moves will be set to be either the `move_dest_ids` of their production (which is unset for all but the last one) or these of the first production of the same `production_group` that is these generated by a common production split: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1263-L1267
Now, since neither are set in our use case, the `move_dest_ids` will not be set on the `move_finished_ids` which implies in particular that the mto link between our productions (but the last one) and the delivery is lost.

Fix:

Since we can not change the nature of the `move_dest_ids` and `created_production_id` in stable to become Many2Many fields, we need to find a way to propagate the `move_dest_ids` on moves without relying on the probably inaccurate value provided by the production. And, since the compute of the `move_finished_ids` could be launched at many other points than during a create process (because of the many dependencies), we can not solely rely on the creation context but rather new to provide a way to recreate the link from relations at any given point. We therefore rely on the `stock.reference`'s similar to what was done prior to 19.0 via the `procurement_group_ids`: https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/mrp/models/mrp_production.py#L1198-L1202

opw-6188069

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

Forward-Port-Of: odoo/odoo#264951

**Problem**:
When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers.

**Before this commit:**
If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving.

**After this commit:**
Only SN-002 and SN-003 will be added to the move, which matches the quantity.

**Steps to reproduce:**
1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product.
2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0.
3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking.
4. SN-001 will be added to the move automatically, but the quantity stays at 2.

opw-6121208

Forward-Port-Of: odoo/odoo#266259
Forward-Port-Of: odoo/odoo#263080