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#110939

Steps to reproduce:
-------------------
* Enable "Master Production Schedule" in Inventory settings
* Create tracked Product "Child" and set up a vendor
* Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days
* Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days
* Open MPS and add your three products:
  - Child, Parent: activate indirect demand
  - Parent: Safety Stock Target of 10
* Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second

Observation:
-------------
Usefull comment form the function :
https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447

When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars)
When calculating the production schedule. we wil we calculate each product for each date_range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509

When calculating the values for a product, we will set the indirect demand qty for it component

The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time):
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555

If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range:
https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560

In our case this will create the issue, since it will try to compensate each time on the previous week.

opw-5413838

Forward-Port-Of: odoo/enterprise#107671

[FIX] website_profile, gamification: fix weekly/monthly leaderboards

Prior to this commit, the leaderboard pagination logic was flawed when
filtering by specific time periods (e.g., "This Week" or "This Month").

The system would first retrieve users sorted by their *all-time* global
karma, apply pagination (taking the top X users), and only then calculate
the karma gain for the specific period for those few users.

This caused users with high recent activity but low all-time karma to only
be displayed much later in the page order than they should.

This commit fixes the issue by introducing a pre-search step that
calculates the karma gain for the requested period at the database level.
Pagination is now applied to this specific result set, ensuring users are
correctly ranked by their actual performance during that week or month.

Note: A new method `_get_users_by_tracking_karma_gain` was added to
`res.users` to handle this logic. This approach was chosen to strictly
preserve the signature of existing methods for the stable version.
A distinct refactor to unify these calculation methods is planned for
the master branch.

Steps to reproduce:

- Install the eLearning module.
- Create a few users with different karma_points (more than 25 to have 2 pages).
- Go to /profile/users.
- Group by week.
- Paginate, and you will notice that the order is wrong; the first user on the second page might have more points than users on the first page. Also, when the logged-in user is not on that page, they do not appear at the bottom.

task-5344657
opw-3979785

Forward-Port-Of: odoo/odoo#256908
Forward-Port-Of: odoo/odoo#176626

This reverts [1]

With enabled valuation and in case of a DB with many locations, it is currently
impossible to validate a picking or open the on hand quantity smart button:
it will lead to a traceback, for instance:
```
Traceback (most recent call last):
[...]
  File "/home/odoo/src/odoo/addons/stock/models/stock_picking.py", line 1432, in button_validate
    pickings_to_backorder.with_context(cancel_backorder=False)._action_done()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
  File "/home/odoo/src/odoo/addons/stock_account/models/product.py", line 205, in _prepare_valuation_layer_field_values
    "total_value": avg_cost * self.sudo(False)._with_valuation_context().qty_available if avg_cost else 0
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
  File "/home/odoo/src/odoo/addons/stock/models/product.py", line 172, in _compute_quantities_dict
    moves_in_res = {product.id: product_qty for product, product_qty in Move._read_group(domain_move_in_todo, ['product_id'], ['product_qty:sum'])}
                                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
  File "/home/odoo/src/odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SyntaxError: memory exhausted at or near "("
LINE 1: ...((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
```

[1] https://github.com/odoo/odoo/commit/c71c21647d468bd1f2e3261b6b612a060c4b6461

OPW-6083436

Forward-Port-Of: odoo/odoo#256799

**Steps to reproduce:**
* Install  `point_of_sale` module.
* Go to Settings:
     * Enable Lots & Serial Numbers.
     * Enable Variants.
     * Set Barcode Nomenclature to Default GS1 Nomenclature.
* Create a product:
     * Enable Track Inventory set to By Lots.
     * Under Attributes & Variants:
     * Add an attribute with two values and save.
* Generate product variants:
     * Open one variant and set barcode to 5123648695416.
* Update inventory:
     * Go to the main product (template).
     * Update On Hand Quantity:
             * Update On Hand Quantity with a lot/serial number:
               010512364869541610784512.
             * Select the variant with the defined barcode.
* Under Point of Sale tab:
    * Set a POS Category.
* Open a POS session and scan:
010512364869541610784512.

**Observed behavior:**
* Scanning the GS1 barcode in POS raises a traceback:
  *TypeError: Cannot read properties of undefined (reading
  'product_template_attribute_value_ids')*.

**Cause:**

[Scans GS1 barcode: 010512364869541610784512]
│
├─ ProductScreen._barcodeGS1Action(parsed_results)
│    • product = await _getProductByBarcode(productBarcode)  ✅ found
│    • calls `addLineToCurrentOrder(vals, { code: lotBarcode })`
│                                                              ⚠️ only `lotBarcode` passed, `productBarcode` discarded
│
├─ PosStore.addLineToCurrentOrder() → addLineToOrder()
│    • product has variants → isConfigurable() = true
│
├─ PosStore.handleConfigurableProduct()
│    • calls openConfigurator(productTemplate, { ...opts })
│      opts = { code: lotBarcode }
│
└─ PosStore.openConfigurator()
     • opts.code = lotBarcode  → truthy → enters if(opts.code) branch
     • getBy("barcode", opts.code.base_code)
     •  getBy("barcode", "784512")   ← "784512" is a LOT number, not a product barcode!
       → returns undefined ❌
     • product packaging lookup also fails → undefined ❌
     • product = undefined
     │
     └─ attributeLinesValues.map(values =>
            values.filter(value =>
                product.product_template_attribute_value_ids.includes(value)
                ^^^^^^^ undefined  → 💥 TypeError

**Fix:**
* Pass the product from `handleConfigurableProduct` to the configurator.
* If no product is found using `opts.code`, use the passed product
  instead.

---

opw-6031909

The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains internal emails (aliases to filter) AND external email addresses (should not be filtered).

The `_find_aliases` method is used to identify internal system emails (aliases, bounces, catchalls) to prevent mail loops and ensure correct recipient filtering during notification grouping.

Before this fix, when the `mail.catchall.domain.allowed` system parameter was set, the logic for local-part aliases (where `alias_incoming_local` is True) failed to correctly associate the local part with the allowed domains. This resulted in external email addressed being returned by the system, potentially leading to incorrect notification routing.

We now use a more robust approach:
- Pre-filter local parts based on the allowed domains to reduce DB load.
- Utilize Python Sets for O(1) lookups of static and local aliases
- Explicitly validate the (local_part, domain) combo during the final filtering.

Example Scenario:
- Config: mail.catchall.domain.allowed = "test1.com,test2.com"
- Alias: "info" (alias_incoming_local=True)
- Input: ["info@test1.com", "info@test3.com"]

### Output Before Fix:
["info@test1.com", "info@test3.com"]
(The function failed to recognize info@test3.com as an external alias to be ignored based on the `mail.catchall.domain.allowed` config)

### Output After Fix:
["info@test1.com"]
(Correctly identifies the internal alias tob filtered while ignoring the external one)


OPW-5469264
OPW-5504201

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