The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#255780

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

In some cases, the users may have invoices with the same product, price unit,
and discount on multiple lines. When they create refunds from such invoices,
the lines ids matching algorithm would fail because it would match the first
matching line over and over again. Also, lines should not match based on line
label, as it can be modified in the refund.

This commit solves these 2 issues by
1) Preventing matching an invoice line more than once with refund lines
2) Preventing matching based on line label

The new algorithm finds the best match for a refund line from the invoice lines
with the following criteria:
1) same product
2) same unit price
3) same discount
4) invoiced quantity should be at least equal to the refunded quantity
5) invoice line should not be matched before
6) from the lines that match previous criteria, we pick the one with the minium quantity

This commit introduces this algorithm for both account.move and pos.order

task-6004207

Forward-Port-Of: odoo/odoo#252200

[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#176626