Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000.

### **Steps to Reproduce:**
1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 
2) Switch to PK company.
3) Create an employee and a running contract with yearly cost 2,200,001 
4) Create a payslip and compute it from the Salary Computation tab.

### **Observed Behavior:**
'Tax Bracket Yearly' is computed as `122000.24`

### **Expected Behavior:**
'Tax Bracket Yearly' should be `116000.24`

### **Root Cause:**
since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on  [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value.

[official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf)

### **Fix:**
Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket.

**opw-5979265**

Forward-Port-Of: odoo/enterprise#112726
Forward-Port-Of: odoo/enterprise#110939

### [FIX] website_sale: keep preview data of dynamic category snippet

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe loads the interaction for dynamic category snippet to show its dynamic content in snippet preview dialog.

Commit 5cd8ba3b5abcad5a119bb879a9892e0bcfe27d9f changed the condition to avoid replacing the preview data.

The dynamic category snippet's preview data does not have the class `s_dialog_preview` to mark them as preview data. Thus the interaction was started and cleared the content (but could not fill it as the snippet does not have a valid configuration yet).

This commit uses a `html_builder.snippetsPreprocessor` to add the class on the preview data of that specific snippet in the loaded snippets.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Bug: the dynamic snippet containing categories is missing its preview data part

task-6088029

### [FIX] website_sale: scale down height of dynamic category snippet's item

Commit 08c41255d70ccbb35eff20e0a12671ffdfba3dfe enables preview of custom dynamic category snippets.

But the height of the item is not adapted to the downscaling of the iframe. Thus they looked 3 times too tall.

This commits adds a patch to the interaction when loaded in this context to adapt the computed value for the height.

Steps to reproduce:
- Open website builder
- Click on "Catalog" snippets category
- Add the dynamic category snippet
- Select the added snippet
- Save this snippet as a custom snippet
- Click on "Custom" snippets category
- Bug: the items int the snippet looks way too big

task-6088029

Forward-Port-Of: odoo/odoo#257026

Steps to reproduce:
1. Create a currency with a non-1 exchange rate with the company's
currency (e.g. VEF with a rate of 0.000005 against USD).
2. Create a pricelist in that currency.
3. Create an event.
4. Create a sale order with the new pricelist.
5. Add a sale order line with a ticket of the event and confirm
the order.
6. Go to the event's page and check the total sales smart button.
7. Check the total sales of the event: it should be equal to the sale
order's total price converted to the company's currency, but it is not,
because of the wrong conversion (it used the inverse of the correct
exchange rate, which is 200000 instead of 0.000005 in our example).

Problem:
The total sales smart button in an event's page shows wrong totals when
sales are in a currency other than the company's currency.

Cause:
The code converts the sale price from the event's currency (which is the
same as the company's currency) to each sale order's currency, while it
should be the other way around (from each sale order's currency to the
event's currency).
https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38

opw-5494790

Forward-Port-Of: odoo/odoo#258000
Forward-Port-Of: odoo/odoo#253605

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

Forward-Port-Of: odoo/odoo#255255

### Issue before this commit:
After generating a stock valuation closing entry from the Inventory Valuation report, reopening the report raised an access rights error. Users with Accounting permissions could no longer access the report.

### Steps to reproduce the issue:
1. Access the database with a user having Accounting Admin rights.
2. Go to the Inventory Valuation report.
3. Click to generate a closing entry.
4. Try to open the Inventory Valuation report again.
5. Result: System shows an access rights error.

### Cause of the issue:
The method _get_last_closing_date() retrieves the field state of the model account.move by querying the technical model ir.model.fields. However, accounting users do not have read access to this model. When the report tries to compute the last closing date after a closing entry exists, this lookup triggers an error.

### Reason to introduce the fix:
The lookup of account.move.state is only used internally to inspect tracking values in the chatter and determine the posting date of the closing entry. Since this requires reading a technical metadata model, the query is executed with sudo() to bypass the restriction while keeping the functional access to accounting data unchanged.

opw-5998151

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

Forward-Port-Of: odoo/odoo#254188

Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Now search for `drawer`.

Issue:
---
- Searching from a product page always scopes results to the product's category, even when the user navigated directly to the product without selecting any category.

Root cause:
---
- The issue occurs because `_prepare_product_values()`[1] always assigns a category using the fallback `product.public_categ_ids[:1]` when no category is explicitly provided. As a result, the `keep` object is generated with `_get_shop_path(category)`[2], which produces a category-based shop URL. Since the search form action is defined as `keep(search=0)` [3] in the template, the generated search URL always includes `/shop/category/<slug>`, even when the user accessed the product page directly. This unintentionally scopes all searches to the product’s first public category instead of performing a global `/shop` search.

Solution:
---
- Separate the breadcrumb logic from the search context logic. Before automatically assigning a default category for breadcrumb display, store the originally requested category (which is None when navigating directly to a product).
- Use the auto-assigned category only for breadcrumb display.
- Use the originally requested category to build the keep QueryURL

[1]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L796-L799 
[2]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L806-L812
[3]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/views/templates.xml#L360-L372

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

Forward-Port-Of: odoo/odoo#257375
Forward-Port-Of: odoo/odoo#251751

### Issue:

In certain flows, basic mrp users (mrp.group_mrp_user) can not mark MO's as done or split production due to the associated automatic creation of accounting analytics.

As concrete examples, the tests:
- test_automatic_backorder_no_redirect
- test_change_qty_produced can not be performed with a user with basic mrp access rights.

### Steps to reproduce:
- Incarnate a user with only mrp user rights
- Create and confirm an MO for 2 units with an operation
- Click on the cog wheel icon > Split production > split
#### > Access Error: You are not allowed to access 'Analytic Line' (account.analytic.line) records.

### Cause of the issue:

To begin with, members of the `mrp.group_mrp_user` do not and should not have read nor create access rights with respect to the `account.analytic.line` model. However, as soon as `mrp_account` is installed the `button_mark_done` can end up requiring such access.

1. The `_split_productions` fails for multiple reasons:

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2000 fails because of the assignment since this call:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L27-L35 requires write and read access on the `account.analytic.line` model.

This line:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/mrp_production.py#L2002 fails because the `copy_data` now checks that the user has the `read` access rights of the comodel when copying `many2many` data's: https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/odoo/orm/models.py#L4781-L4783 This is an issue for instance for the `wip_move_ids` field that can not be copied since mrp users do not have a read access to the `account.move` comodel:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp_account/models/mrp_production.py#L15

This line:
https://github.com/odoo/odoo/blob/0c2ad21773d4a7b23038b9bed19d64952d841fa1/addons/mrp/models/mrp_production.py#L2017 will fail since it checks the read access right on the comodel `account.move` of the `wip_move_ids` fields.

2. The `_post_inventory`:

https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L2221 Fails as it sets the duration:
https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp/models/mrp_production.py#L1922 which calls the `_create_or_update_analytic_entry`: https://github.com/odoo/odoo/blob/afc6f4b41c63800efaa8e3ca15afe5cff5cfa0f9/addons/mrp_account/models/mrp_workorder.py#L18-L21 which it self creates and update `account.analytic.lines` to which you do not have any read access.

backport of b5c7d5fed2d893bcd5ea2c2c5ed1cb9d8dfa2424

opw-6066674

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

Forward-Port-Of: odoo/odoo#257350

Steps to Reproduce:
-
1. In the Project app, create a new project and enable "Timesheets".
2. Create a parent task with allocated hours (e.g., 20h).
3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h).
4. Log in to the portal and navigate to the project's task list.
5. Observe the "Total" allocated time shown in the list header.

Issue:
-
- The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer.

Cause:
-
- The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present.

Fix:
-
- This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view.
- The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task.

task-4939234

Forward-Port-Of: odoo/odoo#258485
Forward-Port-Of: odoo/odoo#221563

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#258472
Forward-Port-Of: odoo/odoo#248619

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
> There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 10
#### > A Delivery is created for 8 units and the MO's demand is updated from 3 to 11

### Expected behavior:

Since the the SOL demand is updated to 10 units and none are currently delivered, a delivery for 10 units should be created and the MTO behavior should therefore add 10 units to be manufactured.

### Cause of the issue:

Adapting the quantity on the sale order from 3 to 10 will launch a call of the `_action_launch_stock_rule` with a `previous_product_uom_qty` of 3. The purpose of this call being to create and run a procurement to fulfill the new demand:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L388-L402
The demand of this procurement is therefore matching the new quantity of the sol minus the qty that is already handled by other procurements (determined by the `_get_qty_procurement` method): https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L310-L320
Note that this `_get_qty_procurement` call should determine the qty that is already planned to be delivered to and returned by the customer. In particular, this `_get_qty_procurement` call should return a value of 0.0 because the entire delivery has been cancelled and nothing is expected to be returned from the customer. However, the call will return an unexpected value of `-3.0` units which will in turn provide a procurement to the customer location for `5 - (-3) =  8` units and hence lead to the creation of a delivery for 8 units and adapt the MO by MTO for 8 additional units.

The discrepancy happening in the `_get_qty_procurement` is due to two recent changes. To begin with, since the 19.0 version the `move_finished_ids` of the production is linked to the sol (part of its `move_ids`) because of these lines:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/stock.py#L134-L139 This change ensuring that MO created by MTO is linked to the SO see 2713876dbc70d3984e584a9037a2206dcda4e84a for more details.

As such, the move of the produced product can now be part of the moves initially considered in the `_get_outgoing_incoming_moves` and that should be filtered out to not be accounted in the qty handled by the current sol:
https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/sale_stock/models/sale_order_line.py#L322-L331

Now, the reason this production move is not excluded from the incoming move pool is because of the change of this other fix: 37f1377344864770cd2a745dd4cb6999af07bbdf https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/sale_order_line.py#L353-L358 To be more precise, while the move is not not a refund, it satisfies the second part of the condition that `move.rule_id.id in triggering_rule_ids` for the incorrect reason that the move has no `rule_id` so that and that `move.rule_id.id` is False and the `triggering_rule_ids` contains the False value but this key is irrelevant and should never have been added as the purpose of the `triggering_rule_ids` list is to keep track of rules starting a push chain.

### Additional Note 

The `setUpClass` of the `TestSaleMrpFlowCommon` test class fails since https://github.com/odoo/odoo/commit/8bbdc99b565b3f678e11cd8889c47dad8944608f because the `tracking`
field is not present in the product form view if if the user does not have the `stock.group_production_lot` group:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/stock/views/product_views.xml#L189
But it is suppose to be reset in the setup:
https://github.com/odoo/odoo/blob/58fb55defee005beb44edb60d2abe044fc99121a/addons/sale_mrp/tests/test_sale_mrp_flow.py#L145-L149

opw-6010109
opw-5885741
runbot-240920

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

Forward-Port-Of: odoo/odoo#254636

Issue:
---
f23b7e6b70babc7d3c027963e0ac6f3e562f44c3 partially fixed the proforma issue.
If you use `Send PRO FORMA Invoice` button, the `proforma` will be present in the context:
https://github.com/odoo/odoo/blob/06205b59f56a87d6bb41b202b95c9716775c67b7/addons/sale/views/sale_order_views.xml#L328-L335

leading to correct beahviour as `is_proforma` will be set as context: https://github.com/odoo/odoo/blob/4ef6f93da818789fd63bd8d37c5526d9a85bef53/addons/sale/report/ir_actions_report_templates.xml#L12

However, if it is printed using the action button `print/PRO Forma Invoice`, the proforma will not be present in the record.context itself (it is present in the docs.context): https://github.com/odoo/odoo/blob/4ef6f93da818789fd63bd8d37c5526d9a85bef53/addons/sale/report/ir_actions_report_templates.xml#L379-L386

The commit bba2fc505f5d0b4770eacc6877155b1aeda6d772 has broke `report_saleorder_pro_forma`, by moving `<t t-set="is_pro_forma">` to attributes of the template call, while `is_pro_forma` is not meant for `html_container` template, and we actually need it to be defined inside the contents.

related: #257817

opw-6043669