## Short functional explanation of the error
When in settings, we click on Manage users, we sometimes get a validation error.

## Reproduction Steps
1. Go to settings.
2. Click on Manage Users.

### Expected behavior
The list of users is displayed.

### Unexpected behavior
Sometimes (around 20% of the time), we get the error:
```
Validation Error

The operation cannot be completed: A user cannot be linked to
multiple employees in the same company.
```

## Origin of the issue
This validation error is triggered due to a psycopg2 constraint error. Indeed, it occurs because the code tries to create an employee for the current user, when an employee for this user already exists:
https://github.com/odoo/odoo/blob/35da8c4d8e86a752cc76d275463a752039465984/addons/pos_hr/models/pos_config.py#L27-L30 In our case, the `group_users` only contains the admin user. This user has an existing corresponding employee in the field `employee_ids`, but not in `employee_id`.

__
opw-6066533






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

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/5416006

Issue:
If a database has products that use the average cost method, and those products have millions of stock moves, a memory error can occur when the inventory valuation report is opened.

Explanation:
When the inventory valuation report is opened, the `_run_average_batch` method is invoked on batches of up to 1000 AVCO products at a time. Previously, all matching stock moves for those products were fetched in a single query and kept in cache for the duration of the computation. For large databases, even a single invocation of `_run_average_batch` can exhaust available memory if the products involved have enough stock moves.

Solution:
Moves are now fetched and processed in batches of 50,000 records, with the cache for `stock.move` and `stock.move.line` invalidated between each batch.

For memory:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 280 MB | 274 MB |
| 500 products with 535,250 moves | 983 MB | 301 MB |
| 500 products with 912,405 moves | 1.7 GB | 337 MB |
| 1000 products with 1,447,655 moves | Mem error | 393 MB |

For speed (in m:ss):
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 100 products with 61,024 moves | 0:15 | 0:16 |
| 500 products with 535,250 moves | 1:12 | 1:17 |
| 500 products with 912,405 moves | 2:02 | 2:10 |
| 1000 products with 1,447,655 moves | N/A | 3:53 |

opw-5416006

Co-authored by Cooper Spinelli (spco)

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

Forward-Port-Of: odoo/odoo#250526

Step to reproduce:
- setup Restaurant and do the following config
- set "self-ordering" -> "Qr Menu + Ordering"
- set "service At" -> "pickup zone"
- save and print the qr-code ( option is right there below these configs)

Observation:
- in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be.
- QRs do not have table_id

Cause:
- there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone"

Fix:
- we only use table_id when ordering_mode = 'table'.

**Before:** 
<img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" />


**After**
<img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" />


opw-5095607


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

Forward-Port-Of: odoo/odoo#254897
Forward-Port-Of: odoo/odoo#247184

**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#252246
Forward-Port-Of: odoo/odoo#249264

Before this commit, when in discuss call and current user has microphone muted, the icon has light red / pink background color on muted instead of red.

The color should be the same as the one from "disconnect", but the difference comes from `btn-danger` with or without `.active` that has different shade of red for background: the `.active` version is lighter like in the mute button when active.

`.active` classname is preferred to keep so that the visual is consistent for most discuss actions, including the ones without success / danger which a majority of these buttons have. However, the buttons with danger / success style are intended to preserve their color unchanged as the `.active` aspect is meant to tell whether the button is active or not and the slight change of color shade is not desirable in the context of discuss action list.

This commit uses the same background color for danger / success / primary inline button. Other styles line dropdown and inline buttons without background had already the same colors, so this commit fixes the only case that was missing.

Task-5436990

Before / After

<img width="283" height="38" alt="Screenshot 2026-03-13 at 15 21 22" src="https://github.com/user-attachments/assets/3ebba48c-5b22-43e9-a915-e18a5531e660" /> <img width="270" height="41" alt="Screenshot 2026-03-13 at 15 21 45" src="https://github.com/user-attachments/assets/586d05a4-2a6c-48e0-89c6-bffa85a86e59" />

Forward-Port-Of: odoo/odoo#255282
Forward-Port-Of: odoo/odoo#253923

Versions
--------
- 19.0+

Steps
-----
- Log in on the portal
- Go to "My Account"
- Go to "Addresses"
- In the billing section uncheck "Same as delivery address"
- In the billing section click "Add Address"
- Fill in address details
- Click "Save Address"

Issue
-----
The newly added address is visible in both the delivery and billing sections, and in the backend the address has type "other" instead of "invoice".

Cause
-----
This happens because the "Add Address" url in the billing section contains the parameter `use_delivery_as_billing=True`, which supersedes the parameter `address_type=billing`, creating an address with type "other". This is because the "Add Address" url in the billing section is not dynamically updated when the "Same as delivery address" toggle is toggled like with the url in the delivery section.

Solution
--------
The `use_delivery_as_billing` is completely removed from the url in the billing section, because the button only appears when the toggle is unchecked (i.e. when `use_delivery_as_billing=false`). And by not sending the parameter, it defaults to false in the backend.

opw-5880430

Forward-Port-Of: odoo/odoo#256326

When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:

https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34

If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy.

https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397

The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not.

We propose to use the context_today() method instead to get the date from the user's timezone.

Benchmark:

| No AVCO Products | Before PR | After PR |
|------------------|-----------|----------|
|            12000 |    > 40 s |      3 s |

opw-6050007

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

Forward-Port-Of: odoo/odoo#255841

Step to reproduce:
- setup Restaurant and do the following config
- set "self-ordering" -> "Qr Menu + Ordering"
- set "service At" -> "pickup zone"
- save and print the qr-code ( option is right there below these configs)

Observation:
- in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be.
- QRs do not have table_id

Cause:
- there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone"

Fix:
- we only use table_id when ordering_mode = 'table'.

**Before:** 
<img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" />


**After**
<img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" />


opw-5095607


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

Forward-Port-Of: odoo/odoo#254897
Forward-Port-Of: odoo/odoo#247184

## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.

## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
    - Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
    - Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
    - Add a row for the current month, with *Next Number* set to 1
    - Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
    - Any Customer
    - Any Product
    - Set the *Quotation Date* to next month
    - Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**

<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />

The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.

## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.

https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216

In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.

https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270

**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**

opw-5950028

Forward-Port-Of: odoo/odoo#256320

Versions
--------
- 19.0+

Steps
-----
- Log in on the portal
- Go to "My Account"
- Go to "Addresses"
- In the billing section uncheck "Same as delivery address"
- In the billing section click "Add Address"
- Fill in address details
- Click "Save Address"

Issue
-----
The newly added address is visible in both the delivery and billing sections, and in the backend the address has type "other" instead of "invoice".

Cause
-----
This happens because the "Add Address" url in the billing section contains the parameter `use_delivery_as_billing=True`, which supersedes the parameter `address_type=billing`, creating an address with type "other". This is because the "Add Address" url in the billing section is not dynamically updated when the "Same as delivery address" toggle is toggled like with the url in the delivery section.

Solution
--------
The `use_delivery_as_billing` is completely removed from the url in the billing section, because the button only appears when the toggle is unchecked (i.e. when `use_delivery_as_billing=false`). And by not sending the parameter, it defaults to false in the backend.

opw-5880430

Forward-Port-Of: odoo/odoo#256326

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

[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