Fixes an issue where grouped list views could show the wrong total in nested group pagers after sorting or reloading. Users now see accurate group counts and avoid stale empty groups appearing when the sort order changes.

Have a list view grouped by 2 fields (e.g. Contacts: Salesperson >
name). Open a group which contains more groups than the limit (set the groups_limit attribute on the arch if necessary). Next to the name of the group, the total number of records belonging to that group is displayed (e.g. Mitchel Admin (32)). In the group header row, the pager allows to browser the inner **groups**, so the total displayed there is the total number of inner groups in that group (e.g. 1-10 / 31).

From that point, clicking on a column header to sort by a given field produces a reload, and the group pager is updated with the wrong total: it now displays the number of records, not the number of groups (1-10 / 32 in the example).

This commit fixes that issue.

The test also hihglighted another issue: when reloaded, we sometimes have to keep former groups that became empty and that weren't returned by the last call to web_read_group (e.g. we drag and dropped the last record from a group to another group). We only do that if search query parameters didn't change. However, we forgot to take the orderBy into account, so when sorting groups, groups that were no longer on the current page were still displayed, with count 0. This commit also fixes that issue.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

The IoT hardware drivers now handle unexpected non-JSON responses more gracefully. Instead of showing a vague error, the system logs the problematic response so support teams can diagnose device or CDN issues faster.

Before commit:

To reproduce the error: A device may send non-JSON data to the IoT controller, or the CDN might return an error in a non-JSON format.

We just get a very non-explicit error: "Expecting value: line 1 column 1 (char 0)".

After commit:

We add a catch for non-JSON data and log the error along with the incorrect data to have more information.

opw-3876631

This fix ensures customer or contact profile pictures are shown correctly in the WhatsApp section instead of displaying an incorrect image link. It improves visual recognition in conversations and reduces confusion for users managing WhatsApp messages in Odoo.

PR modifies avatar URL, instead of incorrectly returning wrong URL it uses `avatarUrl` to get it.

Commit 95726f3d99ba7cf5796a9acd1c13a631db63fbd7 made it so that rewards are archived instead of unlinked when linked to a specific SO/PO, but forgot to bypass access rights to search the linked PO/SO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170094

Commit 95726f3d99ba7cf5796a9acd1c13a631db63fbd7 made it so that rewards are archived instead of unlinked when linked to a specific SO/PO, but forgot to bypass access rights to search the linked PO/SO.




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

Forward-Port-Of: odoo/odoo#170094

### Steps to reproduce - Install project. - Create 2 projects one with timesheets and the second without timesheets. - Open the project without time sheets. - Observe that there are timesheet filters even if the timesheets are disabled. ### Issue: Timesheet filters are available for project tasks even though the project is not using the timesheets. ### Cause: Filters were missing some conditions to enable only when timesheets are available. ### Solution: Corrected the timesheet

### Steps to reproduce

- Install project.
- Create 2 projects one with timesheets and the second without timesheets.
- Open the project without time sheets.
- Observe that there are timesheet filters even if the timesheets are disabled.

### Issue:
Timesheet filters are available for project tasks even though the project is not using the timesheets.

### Cause:
Filters were missing some conditions to enable only when timesheets are available.

### Solution:
Corrected the timesheet-related filters so they are only available for the project tasks which use the timesheets.

Note: When we refresh the page, filters become visible because the context is lost.

task-3754591

Forward-Port-Of: odoo/odoo#155186

Activate a second lang (ex French) and set it to the demo user Set "Cash Discount Tax Reduction" to "Always" Create an invoice with tax Set Payment term to "2/7 Net 30" [1] Go to "journal items" tab Early payment discount lines are set correctly Now with the demo user create a credit note for the invoice Issue: Additional journal item is created, which cancels out the tax refund. This occurs because in https://github.com/odoo-dev/odoo/commit/5a256af35e5d612efed9ed8af1cf23fd62bd83f4

Activate a second lang (ex French) and set it to the demo user
Set "Cash Discount Tax Reduction" to "Always"
Create an invoice with tax
Set Payment term to "2/7 Net 30" [1]
Go to "journal items" tab
Early payment discount lines are set correctly
Now with the demo user create a credit note for the invoice

Issue: Additional journal item is created, which cancels out the tax refund.

This occurs because in https://github.com/odoo-dev/odoo/commit/5a256af35e5d612efed9ed8af1cf23fd62bd83f4
we addressed a duplicated key in the `existing` dict with a workaround:
we add a translated 'Discount' term to the line name and if we detect it
later at tax key creation we change the display_type. Unfortunately this
works only if the two operations are performed with the same lang
context.

[1] Payment terms: 30 Days, 2% Early Payment Discount under 7 days

opw-3922267

Forward-Port-Of: odoo/odoo#169881

Before this commit, when images are added to an Image Wall or to an Image Gallery, they remained in their original format. After this commit, images added to an Image Wall or an Image Gallery are converted to webp. Thanks to [1], the Image Gallery dataset entries related to the conversion are preserved. [1]: https://github.com/odoo/odoo/commit/e73a1a96dcf8786c01205ae0a97b10e38ab9afeb task-3666894 Forward-Port-Of: odoo/odoo#148068

Before this commit, when images are added to an Image Wall or to an
Image Gallery, they remained in their original format.

After this commit, images added to an Image Wall or an Image Gallery
are converted to webp.

Thanks to [1], the Image Gallery dataset entries related to the
conversion are preserved.

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

task-3666894

Forward-Port-Of: odoo/odoo#148068

The issue: When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field Expected behavior: to confirm the invoice Current Behavior: Singleton traceback opw-3878327 Forward-Port-Of: odoo/odoo#163766

The issue:
When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field

Expected behavior:
to confirm the invoice

Current Behavior:
Singleton traceback

opw-3878327

Forward-Port-Of: odoo/odoo#163766

Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected behavior: --- The survey colors should be the same as the website theme. Steps to reproduce: --- 1. Go to the website 2. Click on Edit > Theme 3. Change the background color to black 4. Save then go to Survey 5. Select a survey 6. Remove the background image if there is one 7. Click

Current behavior:
---
On the website, when changing the background color to 
a darker color (ie: black) then starting a survey, 
the background color for the survey is lighter (ie: gray)

Expected behavior:
---
The survey colors should be the same as the website theme.

Steps to reproduce:
---
1. Go to the website
2. Click on Edit > Theme
3. Change the background color to black
4. Save then go to Survey
5. Select a survey
6. Remove the background image if there is one
7. Click on Test
8. Survey's background color is grey

Cause of the issue:
---
Introduced by https://github.com/odoo/odoo/blob/90c6e52f15277d44cbecdd5f6a70391551fb72bd/addons/survey/static/src/scss/survey_templates_form.scss#L22 
A box-shadow is used to make a "translucent white overlay" 
Which lighten the background color if there is no image

Fix:
---
Only lighten the background if there is a background image

opw-3834397

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

Forward-Port-Of: odoo/odoo#161942

The tour is not actually ran in this version, and is blocked before in other versions. We should fix it in an other PR. This typo causes a check on available steps to fail in master. runbot-68355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169973 Forward-Port-Of: odoo/odoo#169646

The tour is not actually ran in this version, and is blocked before in other versions.
We should fix it in an other PR.
This typo causes a check on available steps to fail in master.

runbot-68355




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

Forward-Port-Of: odoo/odoo#169973
Forward-Port-Of: odoo/odoo#169646

Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 0

Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies.

To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is.

#### Speedup
15.0 customer database with 476 000 account.moves, 1M account.move.lines,
8400 products, 700 000 stock.moves, 650 000 stock.move.lines, 500 000 svls
All categories have Inventory Valuation set to real_time.

Benchmark validation of IN transfers, changing the number of products + total number of svls
| Number of products | Total number of svls | Before PR | After PR |
|:----------------:|:-------------------:|:-----------:|:-----------:|
|        1           |          112         |    3.88s  |   3.78s  |
|        2           |          607         |    548ms  |   524ms  |
|        5           |          2561        |    2.27s  |   1.10s  |
|        3           |          8956        |    15min  |   2min   |
|        32          |          43310       |    7min   |   50s    |

Some pickings are not directly impacted by the PR, most probably because these pickings don't have candidates svls/svls to 
vacuum to begin with. Still for the fourth and fith picking, the batch version performs way better than the iterative
one.

Validating an IN transfer with stock_account and real-time inventory valuation is a complex process so it's a bit difficult to
pinpoint tables cardinalities that correlate with the validation time. Here it's the Before vs After time that is relevant, more than
the validation time growth.

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

Forward-Port-Of: odoo/odoo#165948
Forward-Port-Of: odoo/odoo#157558

Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours of timesheeted service; 5. click confirm; 6. add 9.1 hours to a timesheet for the SO. Issue ----- The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded. Cause ----- The smart button displays the value of the `timesheet_total_duration` fie

Versions
--------
- 15.0+

Steps
-----
1. Go to Sale / Configuration / Units of Measure Categories;
2. go to Working Time;
3. set rounding precision of Hours to 1.0;
4. create a SO, selling 10 hours of timesheeted service;
5. click confirm;
6. add 9.1 hours to a timesheet for the SO.

Issue
-----
The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded.

Cause
-----
The smart button displays the value of the `timesheet_total_duration` field, this field gets computed with `_compute_quantity` method of `uom.uom`, which defaults to the `UP` rounding method:
https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/uom/models/uom_uom.py#L216

In contrast, the SOL displays the result of `_get_delivered_quantity_by_analytic`, which uses the same `uom.uom` method, but with the `HALF-UP` rounding method: https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/sale/models/sale_order_line.py#L387

Solution
--------
Modify the `_compute_timesheet_total_duration` methods of `account.move` and `sale.order` to use the same rounding method as the `_get_delivered_quantity_by_analytic` method.

opw-3949986

Forward-Port-Of: odoo/odoo#169900
Forward-Port-Of: odoo/odoo#167607

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain. This commit changes the format to be the same as in module l10n_es_edi_tbai . task-3990176 Forward-Port-Of: odoo/odoo#169609

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain.

This commit changes the format to be the same as in module l10n_es_edi_tbai .

task-3990176

Forward-Port-Of: odoo/odoo#169609

reverts e6c55e1683d679efd12e7d1cfca85b736fcbea01 We notice too many usability issues as a result of this commit. As it was stated that the security concerns were not that bad we let users delete any mail attachment they may find necessary. task-3983664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169891 Forward-Port-Of: odoo/odoo#168832

reverts  e6c55e1683d679efd12e7d1cfca85b736fcbea01

We notice too many usability issues as a result of this commit.

As it was stated that the security concerns were not that bad we let users delete any mail attachment they may find necessary.

task-3983664

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

Forward-Port-Of: odoo/odoo#169891
Forward-Port-Of: odoo/odoo#168832

This commit import payment_token file in __init__ which was missed by [1] PR to properly execute it's code and do not return any token for express checkout. [1]: https://github.com/odoo/odoo/pull/107788 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169942

This commit import payment_token file in __init__
which was missed by [1] PR to properly execute
it's code and do not return any token for express
checkout.

[1]: https://github.com/odoo/odoo/pull/107788

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#169942