This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958

This PR refactors `_create_backorder `for better extensibility.
Related: https://github.com/OCA/manufacture/pull/1467

@qrtl QT5016

Forward-Port-Of: odoo/odoo#207355
Forward-Port-Of: odoo/odoo#195958

## Version: 18.0+ ## Issue: Total section on Purchase Order document is misaligned. ## Steps to reproduce: - Go to Purchase: - Open a purchase order record; - Click on Print > Purchase Order. ## Cause: Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 ## Fix: Full style reverting opw-4771854 Forward-Port-Of: odoo/odoo#209084

## Version:
18.0+

## Issue:
Total section on Purchase Order document is misaligned.

## Steps to reproduce:
- Go to Purchase:
  - Open a purchase order record;
  - Click on Print > Purchase Order.

## Cause:
Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 

## Fix:
Full style reverting

opw-4771854

Forward-Port-Of: odoo/odoo#209084

[FIX] base: fix error message partner form This commit will fix two things: - Currently, the error message if you have a duplicate tax id or a duplicate company registry in the partner form displays the label of the concerned field twice. With this commit, we display the label of that field only once. From : "Potential duplicates: Partner A (Same Tax ID Tax ID)" To : "Potential duplicates: Partner A (Same Tax ID)" - Currently, the error message shows only 1 partner even if the Tax ID

[FIX] base: fix error message partner form

This commit will fix two things:
- Currently, the error message if you have a duplicate tax id or a
duplicate company registry in the partner form displays the label of the
concerned field twice. With this commit, we display the label of that
field only once.
From : "Potential duplicates: Partner A (Same Tax ID Tax ID)"
To : "Potential duplicates: Partner A (Same Tax ID)"

- Currently, the error message shows only 1 partner even if the Tax ID
is duplicated with a partner A and the Company Registry is duplicated
with a partner B. With this commit, the partner
with the same Tax ID and the partner with the same Company Registry are
both printed in the error message if they are different.
From : "Potential duplicates: Partner A (Same Tax ID Tax ID and Company
Registry Company Registry)"
To : "Potential duplicates: Partner A (Same Tax ID) and Partner B (Same
Company Registry)"

The choice to not display the value of the field (vat or company
registry) was done because of technical constraints : it would be too
much of a development for an information that's already displayed on the
screen a few lines further on.

task-4668697

runbot : https://runbot.odoo.com/runbot/bundle/saas-18-1-error-message-partner-form-roto-358947

Forward-Port-Of: odoo/odoo#204733

Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings

Issue:

On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings on the first page takes 8 to 10s.

One of the issues found when analyzing the issue is that the 3 SQL queries performed on stock_move in the beginning of _get_report_lines are slow:

```
        past_outs = self.env['stock.move'].search(AND([out_domain, past_domain]), order='priority desc, date, id')
        future_outs = self.env['stock.move'].search(AND([out_domain, future_domain]), order='reservation_date, priority desc, date, id')

        outs = past_outs | future_outs

        ins = self.env['stock.move'].search(in_domain, order='priority desc, date, id')
```

Further analysis and testing show that using a domain with a negative condition ('not in') on the `state` column of stock_move prevents PostgreSQL from using the existing index on that column. By changing the condition in the domain to use a positive condition on that column, the execution time of each of the three queries goes from 1000-1500ms to about 100ms, saving about 3s on the total loading time of the page, which is still slow but a bit less.

Without patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 3.907 4.824
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 3.998 5.284
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 4.246 5.725
```

With patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 0.619 4.639
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 0.643 5.143
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 0.862 5.618
```


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

Forward-Port-Of: odoo/odoo#207022

**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/s

**Steps to reproduce:**
- Create a new product storable product
- Open Inventory/Operations/Physical Inventory
- Add a new line
- Choose your product
- Click on History

**Current behavior:**
An Odoo Client Error window appears

**Cause of the issue:**
Inside the counted quantity widget's useEffect,
When adding the event listener "this.onInput.bind(this)" creates a new function reference
https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L18
when removing the event listener "this.onInput.bind(this)" creates another function reference
https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L22
As a consequence the event listener is not properly removed

**Fix:**
If the new function reference is created before in a variable the same function reference will be passed the two times and it will be properly removed

opw-4711101

Forward-Port-Of: odoo/odoo#206478

In the lead generation form view, the widget that allows the user to select a filter currently spans into the label column in the grid, causing it to appear squished. To ensure it occupies the entire row properly, we will add the colspan="2" attribute to the field definition. Task-4750253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207480

In the lead generation form view, the widget that allows the user to select a filter currently spans into the label column in the grid, causing it to appear squished. To ensure it occupies the entire row properly, we will add the colspan="2" attribute to the field definition.

Task-4750253

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

Forward-Port-Of: odoo/odoo#207480

This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed. Forward-Port-Of: odoo/odoo#209004

This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed.

Forward-Port-Of: odoo/odoo#209004

This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#208836 Forward-Port-Of: odoo/odoo#207270

This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO.

task-id: 4750146

Forward-Port-Of: odoo/odoo#208836
Forward-Port-Of: odoo/odoo#207270

When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing

When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3).

However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing a unique constraint violation if the same name already exists.

This PR removes `default_name` from the context.

Task-3901336

Forward-Port-Of: odoo/odoo#208362

Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Description
-----------
Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`.

Benchmark:
----------
On odoo.com, unlinking an expense took:

| Before | After |
|--------|-------|
| 10s    | 58ms  |

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

Forward-Port-Of: odoo/odoo#208875

'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity. # How to Reproduce - Create Subcontract BoM, with 1 cmp at $10 - Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10) - Scrap 1 unit of finished product => Journal ent

'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity.

# How to Reproduce
- Create Subcontract BoM, with 1 cmp at $10
- Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10)
- Scrap 1 unit of finished product => Journal entry for scrapped layer contains 3 AML instead of 2 => The additional cost is incorrectly added to the Stock Valuation account, making the line balance at -$30, while the layer is still at -$20

OPW-4640650

---

Test result without fix:
```
2025-04-24 09:26:06,083 18424 ERROR oes_test_17 odoo.addons.mrp_subcontracting_account.tests.test_subcontracting_account: FAIL: TestAccountSubcontractingFlows.test_subcontracting_account_flow_1
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_subcontracting_account/tests/test_subcontracting_account.py", line 174, in test_subcontracting_account_flow_1
    self.assertRecordValues(amls, [
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
    self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 3 records versus 2 expected values.

==== Differences at index 0 ====
--- 

+++ 

@@ -1,3 +1,3 @@

-account_id:300
-debit:60.0
-credit:0.0
+account_id:301
+debit:0.0
+credit:60.0

==== Differences at index 1 ====
--- 

+++ 

@@ -1,2 +1,2 @@

-account_id:299
-debit:30.0
+account_id:300
+debit:60.0

==== Additional record ====
{'account_id': 301, 'credit': 90.0, 'debit': 0.0, 'product_id': 107}
 ```

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

Forward-Port-Of: odoo/odoo#207204

When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward

When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error
because the original invoice number, UUID, and amount are required.
This commit restricts the users from sending independent credit notes to JoFotara.
It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note.

task-4756603




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

Forward-Port-Of: odoo/odoo#208276

Forward-Port-Of: odoo/odoo#207024

Forward-Port-Of: odoo/odoo#207024

Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`. opw: 4744418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`.

opw: 4744418


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

Forward-Port-Of: odoo/odoo#208752

Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally

Description of the issue this commit addresses:

When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally impossible.

---

Steps to reproduce:

1. Install l10n_eu_oss and any oss member loca (be for example)
2. Use the company of the loca installed
3. Go to Accouting, Settings, click Refresh tax mapping.
4. Go to the fiscal positions and delete any oss fiscal position.
5. Go back to Accoutning, Settings, click Refresh tax mapping.
6. "Tax names must be unique!" error shows up.

---

Desired behavior after this commit is merged:

When creating the oss fiscal positions, a search is performed to gather the tax and its copies that use the desired name. The name of the new tax will be the name of the one with the most " (Copy)" in its name with one more " (Copy)".

---

no-task

---

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

Forward-Port-Of: odoo/odoo#208985
Forward-Port-Of: odoo/odoo#208532

This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency. task - 4680092 you can check this for reference  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208301

This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency.

task - 4680092

you can check this for reference 
![image](https://github.com/user-attachments/assets/c9e3b816-2b48-484a-b852-34ddbf07a93e)

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

Forward-Port-Of: odoo/odoo#208301

This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA. Forward-Port-Of: odoo/odoo#208969

This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA.

Forward-Port-Of: odoo/odoo#208969

This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scroll

This commit, fixes the scroll of the control panel when we opened the search bar.
The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scrolling element.
When the new delta was calculated (in the scroll handler) to set the top position of the control panel, a wrong value was set as there was an additional offset of the height of the "search input line".

This commit adds an ResizeObserver to observe the scrolling element and so adapt the `oldScrollTop` variable to adapt the delta of its height.

task-4466063

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

Forward-Port-Of: odoo/odoo#208955
Forward-Port-Of: odoo/odoo#208787

Add the Invoice Sending Method field to the partner's list view to enable mass edit. task-no (feedback from WTA) Forward-Port-Of: odoo/odoo#209007

Add the Invoice Sending Method field to the partner's list view to enable mass edit.

task-no (feedback from WTA)

Forward-Port-Of: odoo/odoo#209007

Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` cl

Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause.

However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead.

To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below:

```sql
apan_2760231=> select count(*) from pos_order;
 count
--------
 146885
(1 row)

apan_2760231=> select count(*) from pos_order_line;
 count
--------
 378860
(1 row)

apan_2760231=> select count(*) from pos_payment;
 count
--------
 184679
(1 row)
```

Logs:

Before fix (Almost 3 hrs):
```py
2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids
2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL
```

After fix (reduces to 10 mins):
```py
2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids
2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL
```

opw-4734894
upg-2760231


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

Forward-Port-Of: odoo/odoo#206558
Forward-Port-Of: odoo/odoo#206467

- saas-17.4 issue 2: ### Steps to Reproduce: - Install the hr_timesheet module. - Create a portal user. - Create a project, task, and sub-task (with timesheet entries). - Share the project with the portal user. - Log in as the portal user. - Open the shared project and navigate to the task. - Open timesheet. ### Issue: When a portal user tries to open the timesheet of a shared project task from a mobile device, an error occurs. ### Cause: The po

- saas-17.4

issue 2:
###  Steps to Reproduce:
   - Install the hr_timesheet module.
   - Create a portal user.
   - Create a project, task, and sub-task (with timesheet entries).
   - Share the project with the portal user.
   - Log in as the portal user.
   - Open the shared project and navigate to the task.
   - Open timesheet.

### Issue:
   When a portal user tries to open the timesheet of a shared project task from a mobile device,
   an error occurs.

### Cause:
   The portal user does not have access to the analytic account, which triggers this error.  The form view for analytic.line 
   in the analytic module includes analyti_account_id.

### Solution:
   In this commit, we have used the `timesheet_view_form_portal_user` form view. This view  does not include 
   analytic_account_id, which prevents the access error from occurring.

task-4369891

Forward-Port-Of: odoo/odoo#208889
Forward-Port-Of: odoo/odoo#168847

### Description: By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action. ### Reference: opw-4707551 Forward-Port-Of: odoo/enterprise#83296

### Description:

By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action.

### Reference:

opw-4707551

Forward-Port-Of: odoo/enterprise#83296

Steps to reproduce: - Activate foreign currency EUR (main company in USD) - Have a Bank journal in EUR - Create one Vendor "Send" payment of 100 EUR - Create a new Vendor batch payment and add the payment. - Open EUR Bank and register an outgoing transaction of 100 EUR - Match the transaction with the Batch payment Issue: Looking at the debit/credit columns it can be seen that the transaction amount is properly converted in company currency, but the batch amount is not converted (rate

Steps to reproduce:
- Activate foreign currency EUR (main company in USD)
- Have a Bank journal in EUR
- Create one Vendor "Send" payment of 100 EUR
- Create a new Vendor batch payment and add the payment.
- Open EUR Bank and register an outgoing transaction of 100 EUR
- Match the transaction with the Batch payment

Issue: Looking at the debit/credit columns it can be seen that the
transaction amount is properly converted in company currency, but
the batch amount is not converted (rate 1.00)

This occurs because when the payments in a batch don't have an
associated move, the amount residual is converted from payment currency
(EUR) to batch currency (still EUR) and not company currency (USD)

opw-4656807

Forward-Port-Of: odoo/enterprise#83632

Before this commit, when rescheduling call activities, this could lead to the following crash: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This error state that the activity has no related persona in order to display its avatar in the popover. The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data. The reas

Before this commit, when rescheduling call activities, this could lead to the following crash:

```
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at ActivityListPopoverItem.template
```

This error state that the activity has no related persona in order to display its avatar in the popover.
The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data.

The reason of crash comes from voip method `_format_call_activities` that returns custom activity data that do not pass `persona`. This commit fixes the issue by passing `persona` data like in the usual `_to_store` of activity.

The crash occurs since https://github.com/odoo/odoo/pull/190161

opw-4586756

Forward-Port-Of: odoo/enterprise#84970

It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback. This commit aims to handle this case so the report can be open without issue. opw-4749480 Forward-Port-Of: odoo/enterprise#84812

It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback.

This commit aims to handle this case so the report can be open without issue.

opw-4749480

Forward-Port-Of: odoo/enterprise#84812

Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819 Forward-Port-Of: odoo/enterprise#83829

Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost.

The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values.

opw-4686819

Forward-Port-Of: odoo/enterprise#83829

Sometimes, when opening the documents folder, test folder is hidden on a second page, even if we open a parent folder first. With this fix, we search for the folder directly through search bar, eliminating undeterminism from the test. Forward-Port-Of: odoo/enterprise#83486

Sometimes, when opening the documents folder, test folder is hidden on a second page, even if we open a parent folder first. With this fix, we search for the folder directly through search bar, eliminating undeterminism from the test.

Forward-Port-Of: odoo/enterprise#83486

**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report) - Select "Argentinean VAT Book (AR)" as report - A cog button should appear after the report name with "VAT Book (ZIP)" option - With browser debug feature, switch to a responsive display and reduce the width or - Repeate

**Steps to reproduce:**
- Install Accounting
- Install a module that adds a button to tax report (e.g. l10n_ar)

- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)
- Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report)
- Select "Argentinean VAT Book (AR)" as report
- A cog button should appear after the report name with "VAT Book (ZIP)" option

- With browser debug feature, switch to a responsive display and reduce the width
or
- Repeatedly increase the zoom to increase the size of the button

**Issue:**
For a certain range of width the cog button is not visible.

**Cause:**
".o_control_panel_breadcrumbs" element that contains the buttons has a min-width of 200px, hiding all elements that are after these 200px when reducing the width.

**Solution:**
Increase the min-width to 350px.
The value is arbitrary but it covers well this use case.
With a lower value, the cog button could still be hidden in the case of the Argentinian Tax Report in Spanish language.

opw-4747697

Forward-Port-Of: odoo/enterprise#84432

Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR. The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error. This PR reverts the value assigned to be the status description, as it was prior to the above commit. opw-4775345 Forward-Port-Of: odoo/enterprise#84749

Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR.

The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error.

This PR reverts the value assigned to be the status description, as it was prior to the above commit.

opw-4775345

Forward-Port-Of: odoo/enterprise#84749

In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction. An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction. task-3969988 Forward-Port-Of: odoo/enterprise#84917 Forward-Port-Of: odoo/enterprise#74760

In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction.

An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction.

task-3969988

Forward-Port-Of: odoo/enterprise#84917
Forward-Port-Of: odoo/enterprise#74760

This is a useful option that is hard to know about unless you read the code or are told it exists. It should be visible in the report options. In the context of: task-4734528 Forward-Port-Of: odoo/enterprise#83556

This is a useful option that is hard to know about unless you read the code or are told it exists.
It should be visible in the report options.

In the context of:
task-4734528

Forward-Port-Of: odoo/enterprise#83556