The project update walkthrough test now waits for a new milestone to be fully saved before continuing. This reduces occasional automated test failures caused by timing delays, helping keep project-related releases more stable.

Before this commit, the `project_update_tour` sometimes fails because the save action takes more time than usually and so the UI does not get the click event on the new milestone created and so the line does not go back in edit mode.

This commit adds a new step to make sure the create action is correctly made before doing the next steps.

runbot-104048

This fix improves how point of sale order lines appear by correcting note spacing, tightening combo product spacing, and removing unnecessary blank list areas. It makes receipts and register screens cleaner and easier for staff and customers to read.

- Fix missing space between "Customer Note" & "Kitchen Note"
- Reduce space for combo products (register & receipt)
- Remove empty <ul> element from order lines (when no `packLotLines`)

task-id: 4578826





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

Guests who open calendar invitation links will no longer automatically ring meeting channel members before the appointment time. This prevents unwanted call notifications and reduces disruption for invited users.

Curious guest that follow invitation links should not invite users to the call automatically.

task-4399188

This update fixes an issue in the rental point-of-sale test flow by ensuring POS users have the right access to product tracking information. It helps keep rental order line behavior reliable and reduces the risk of errors when handling tracked rental products in POS.

- Add groups `point_of_sale.group_pos_user` for tour `OrderLotsRentalTour`, so user can access `line.product_id.tracking`.

community PR: https://github.com/odoo/odoo/pull/197816

task-id: 4578826

The commission report no longer allows grouping commission data by sales team where that view could produce incorrect or confusing results. This helps users review commission information more reliably and avoids misleading reporting choices.

Taskid: 4471762

For visitors, the name of the author might not be known, only their live chat user name. Use the getter that takes this into account when displaying the author name of notifications such as "join", "left" or "invited to the channel" to actually display the live chat user name rather than nothing. task-4433078 Forward-Port-Of: odoo/odoo#199470

For visitors, the name of the author might not be known, only their live chat user name. Use the getter that takes this into account when displaying the author name of notifications such as "join", "left" or "invited to the channel" to actually display the live chat user name rather than nothing.

task-4433078

Forward-Port-Of: odoo/odoo#199470

Before this commit, when a product used in a paid order was archived, loading the paid order would cause the product to appear on the product screen. opw-4493666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194900

Before this commit, when a product used in a paid order was archived, loading the paid order would cause the product to appear on the product screen.

opw-4493666

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

Forward-Port-Of: odoo/odoo#194900

The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV. After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we c

The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it.

However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV.

After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we consider the request as failed and requires the user to send a new request again, we make the user send a second request on the same invoice, where the SPV actually acknowledges all of the received invoices.

After discussing with the PO, a temporary workaround for now is to increase the timeout limit to 60 seconds (1 full minute) to reduce the likelihood of this issue happening, and log error messages on the chatter if the request (either for send/fetch/download) failed, so that the user are aware when it is timeout and be more wary not to send another request right away, in case the new timeout limit are still not enough.

Other small changes in this PR:

- Handle response code 401, (which is a JSON object, invalid access token)
- Remove the "Error when sending the document to the SPV:" template in error documents (because not all error documents are for sending, some are from fetch/download)

opw-4571713

Forward-Port-Of: odoo/odoo#199036
Forward-Port-Of: odoo/odoo#198604

Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view. Step to produce: - Install the `hr_recruitment` module. - Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them. `ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)` The error occurs because the system attempts to access a singl

Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view.

Step to produce:

- Install the `hr_recruitment` module.
- Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them.

`ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)`

The error occurs because the system attempts to access a single value from multiple records at [1].

Link [1]: https://github.com/odoo/odoo/blob/f1637a10db2f34ca3a272792079115e0192489f8/addons/hr_recruitment/models/hr_applicant.py#L384-L385

To resolve this issue, Use an iteration(for loop) to process each record one by one.

Sentry-6229305438


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

Forward-Port-Of: odoo/odoo#194328

Forward-Port-Of: odoo/odoo#197213

Forward-Port-Of: odoo/odoo#197213

**Avoid archive attribute value when is not been used** Impacted versions: - 18.0 and later ### Steps to reproduce: 1. Create a new attribute with attribute values (ex: value 1) 2. Delete the attribute value 3. Confirm that the attribute value still exists (archived instead of deleted) ### Current behavior: - Attribute value is being archived ### Expected behavior: - Attribute value must be deleted Task: [4551094](https://www.odoo.com/odoo/my-tasks/455

**Avoid archive attribute value when is not been used**

Impacted versions:
 
 - 18.0 and later
 
### Steps to reproduce:
 
 1. Create a new attribute with attribute values (ex: value 1)
 2. Delete the attribute value
 3. Confirm that the attribute value still exists (archived instead of deleted)

 
### Current behavior:
 
 - Attribute value is being archived
 
### Expected behavior:
 
 - Attribute value must be deleted

Task: [4551094](https://www.odoo.com/odoo/my-tasks/4551094)

Forward-Port-Of: odoo/odoo#199119

It happens due to many reasons that the `stock.quant` object and `stock.move.line` loose their synchronisation and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the `stock.quant` It's important to keep tracking why the desycnh happens and to fix all the root causes of it. However, it's hard for the user to clean the data himself or even worst to lock him when it happens (as before 18.0). For quantity: It's not a big deal to have a

It happens due to many reasons that the `stock.quant` object and `stock.move.line` loose their synchronisation and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the `stock.quant`

It's important to keep tracking why the desycnh happens and to fix all the root causes of it.

However, it's hard for the user to clean the data himself or even worst to lock him when it happens (as before 18.0).

For quantity: It's not a big deal to have a huge difference between the quantity and all the long time history. As in real life, the inventory adjustement can help to clean the data.

For reserved quantity: It's a bigger problem since the user can't edit it. A first step would be to never write it to a negative value (since it should never happen). That way when the user empty the stock, it will also probably clean the reserved quantity. But in case where there is more reservation than on `stock.move.line`. We should also clean it to be able to reserve them. Currently, we will try in the scheduler for that part

A last step, could be to create a constraint during test that ensure the synch is never broken and it could raise directly if the developer made a mistake

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

When the user is on the screen saver, we do not want to propagate some events like click so that his click does not do something unexpected in the POS (like adding a product or something). This commit adds a check in the onAlive method of the pos app to stop the event propagation of some events when the screen saver is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199370

When the user is on the screen saver, we do not want to propagate some events like click so that his click does not do something unexpected in the POS (like adding a product or something).

This commit adds a check in the onAlive method of the pos app to stop the event propagation of some events when the screen saver is active.

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

Forward-Port-Of: odoo/odoo#199370

before this commit and since commit 42b207f, the pos_restaurant does not lock the state of the order button anymore. This has as an effect that if the order submitting takes a lot of time (which e.g. happens when a preparation printer is configured) the user could press the order button multiple times. This situation can happen both intentionally or unintentionally. The end result is a disturbed flow for users, where orders are sent multiple times in preparation and therefore need to be ma

before this commit and since commit 42b207f, the pos_restaurant does not lock the state of the order button anymore. This has as an effect that if the order submitting takes a lot of time (which e.g. happens when a preparation printer is configured) the user could press the order button multiple times.

This situation can happen both intentionally or unintentionally.

The end result is a disturbed flow for users, where orders are sent multiple times in preparation and therefore need to be manually checked by the staff regularly risking wrong extra order preparation otherwise.

This commit reverts the changes adding back the state locking the order button while it's being processed.

opw-4242269

Forward-Port-Of: odoo/odoo#190391

Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to. This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters. opw-4558352 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od

Currently, searching for `Resume's Content` on applicants uses the domain `attachment_ids.index_content`, which searches the `index_content` of all attachments, ignoring the model they are linked to.

This update modifies the domain to include a `res_model` filter, ensuring the search is limited to applicants' attachments, which are typically CVs added by recruiters.

opw-4558352

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

Forward-Port-Of: odoo/odoo#199288

CUP and CIG fields for the Italian Localization are available in account moves and are used when the buyer is a Public Administration or utilizes public funds for payment. However, in some cases, these fields are already necessary in the Sales Order. Therefore, this commit adds the CUP and CIG fields to eligible Sales Orders and automatically adds said fields to the Invoice generated from the SO. The fields Origin Document Type, Origin Document Name, Origin Document Date are also added to

CUP and CIG fields for the Italian Localization are available in account moves and are used when the buyer is a Public Administration or utilizes public funds for payment.

However, in some cases, these fields are already necessary in the Sales Order. Therefore, this commit adds the CUP and CIG fields to eligible Sales Orders and automatically adds said fields to the Invoice generated from the SO.

The fields Origin Document Type, Origin Document Name, Origin Document Date are also added to the Sales Order. If the fields are filled, then the values are passed to the invoice. If the fields are empty, then the Origin Document fields in the invoice are filled with information about the SO which originated it.

Task [link](https://www.odoo.com/odoo/project/967/tasks/4290997)
task-4290997

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

Forward-Port-Of: odoo/odoo#197267

All these issues were spotted using the new irregularity map feature (task 4357729) Task: 4387232 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189835

All these issues were spotted using the new irregularity map feature (task 4357729)

Task: 4387232



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

Forward-Port-Of: odoo/odoo#189835

steps to reproduce: ------------------------ 1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in) 2. Enable the "Anglo-Saxon Accounting" option. 3. Migrate to 18.0 version. Issue: ------- Commit c2d0251 , sets a default value when changing the CoA. However, during migration, when the `_pre_load_data` function runs, it overrides the customer's selection even if the CoA is not changed and assigns the default value to the `anglo_saxon_account

steps to reproduce:
------------------------
1. Install a localization module that does not use `anglo_saxon_accounting` in 17.0 (Ex:l10n_in)
2. Enable the "Anglo-Saxon Accounting" option.
3. Migrate to 18.0 version.

Issue:
-------
Commit c2d0251 , sets a default value when changing the CoA. However,
during migration, when the `_pre_load_data` function runs, it overrides the 
customer's selection even if the CoA is not changed and assigns the default
value to the `anglo_saxon_accounting` field, ignoring the customer's preference.

**Original DB:**
```psql
bona_2515224=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  6 | Handful of Health Pvt Ltd - TN | t
  4 | Handful of Health Pvt Ltd - KA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  2 | Handful of Health Pvt Ltd - MH | t
  7 | Handful of Health Pvt Ltd - GA | t
  5 | Handful of Health Pvt Ltd - RJ | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```
**Without fix:**
```psql
bona_2515224_upg=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  1 | Handful of Health Pvt Ltd - DL | f
  2 | Handful of Health Pvt Ltd - MH | f
  3 | Handful of Health Pvt Ltd - UP | f
  4 | Handful of Health Pvt Ltd - KA | f
  5 | Handful of Health Pvt Ltd - RJ | f
  6 | Handful of Health Pvt Ltd - TN | f
  7 | Handful of Health Pvt Ltd - GA | f
  8 | Handful of Health Pvt Ltd - GJ | f
(8 rows)
```
**With fix:**
```psql
bona_2515224_18.0=> select id,name,anglo_saxon_accounting from res_company;
 id |              name              | anglo_saxon_accounting 
----+--------------------------------+------------------------
  7 | Handful of Health Pvt Ltd - GA | t
  8 | Handful of Health Pvt Ltd - GJ | t
  4 | Handful of Health Pvt Ltd - KA | t
  2 | Handful of Health Pvt Ltd - MH | t
  5 | Handful of Health Pvt Ltd - RJ | t
  6 | Handful of Health Pvt Ltd - TN | t
  3 | Handful of Health Pvt Ltd - UP | t
  1 | Handful of Health Pvt Ltd - DL | t
(8 rows)

```

opw-4542300


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

Forward-Port-Of: odoo/odoo#198011

In this commit, we adapt the unit tests to use macro.isComplete. In all these tests, what we want to verify in the end is that the macro or tour has performed as expected. This allows to remove all await advanceTime() or await animationFrame() and makes the tests much clearer. 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-

In this commit, we adapt the unit tests to use macro.isComplete. In all these tests, what we want to verify in the end is that the macro or tour has performed as expected. This allows to remove all await advanceTime() or await animationFrame() and makes the tests much clearer.

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

Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record. Steps to reproduce: - Ensure the Mexican localization is installed and properly configured. - Generate an invoice and sign it with the government (CFDI). - Create and sign a payment for the invoice. - Cancel the payment from the CFDI table. Current behavior: - Odoo cancels the move

Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record.

Steps to reproduce:
- Ensure the Mexican localization is installed and properly configured.
- Generate an invoice and sign it with the government (CFDI).
- Create and sign a payment for the invoice.
- Cancel the payment from the CFDI table.

Current behavior:
- Odoo cancels the move, but the related payment remains posted.

Expected behavior:
- The payment should also be canceled when the move is canceled.

This fix ensures that the associated payment is canceled correctly.

opw-4528910

Forward-Port-Of: odoo/odoo#198082

The code has been introduced initialy by: https://github.com/odoo/odoo/commit/4cbd6cc52cb96cc20d41974a37410a37fd9902f5 ...but since the override has been reverted in: https://github.com/odoo/enterprise/commit/4f77e313ee9e97164f3ffe0e492f8f036fa53c50 ... those hooks are no longer necessary. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199460

The code has been introduced initialy by:
https://github.com/odoo/odoo/commit/4cbd6cc52cb96cc20d41974a37410a37fd9902f5

...but since the override has been reverted in:
https://github.com/odoo/enterprise/commit/4f77e313ee9e97164f3ffe0e492f8f036fa53c50

... those hooks are no longer necessary.

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

Forward-Port-Of: odoo/odoo#199460

Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-32

Steps to reproduce:
- Add an snippet.
- Click the "show/hide on desktop"  button of visibility option.
- Click on the little eye on the "hidden elements" section to have it displayed again.
- Go to mobile preview mode.
- Come back to desktop view by toggling off mobile preview button.
- An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view.

After this commit:
Empty overlays no longer appear when switching between preview modes.

task-3270034

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

Forward-Port-Of: odoo/odoo#198521
Forward-Port-Of: odoo/odoo#173328

Currently, a traceback is occurring when the user tries to create an exchange return without giving the origin value in picking. To reproduce this issue: 1) Install `purchase_stock` 2) Create a stock picking with operation type as `receipts` and don't give the `origin` value 3) Add a product in operation that contains vendor records in the product 4) `Validate` the product and click the `return` button to open a wizard 5) Update the qty to return and click the `Return for Exchange

Currently, a traceback is occurring when the user tries to create an 
exchange return without giving the origin value in picking.

To reproduce this issue:

1) Install `purchase_stock`
2) Create a stock picking with operation type as `receipts` and don't give the `origin` value 
3) Add a product in operation that contains vendor records in the  product
4) `Validate` the product and click the `return` button to open a wizard 
5) Update the qty to return and click the `Return for Exchange` button

Error:-
```
TypeError: sequence item 0: expected str instance, bool found
```

This traceback occurs from the line below because we are getting the origin value as False from the procurements.

https://github.com/odoo/odoo/blob/949ed6f30f539dd787594511751bda0e714a5409/addons/purchase_stock/models/stock_rule.py#L119

The origin value of this procurement is directly taken from the origin value of picking. 
The above traceback occurs because the user didn't provide the origin value in picking.

We can resolve this issue by providing a fallback value of an empty string if there is no origin in picking.

sentry-6316652948

Forward-Port-Of: odoo/odoo#198724

**Issue:** The COA for the French localization has been updated in 2025. Some accounts have been replaced or removed and the reports have been updated with the new formulas. However, the reports from 2024 are still needed for those who need to print a report for 2024. **Solution:** Restore the old reports from 2024 as variants. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80358 Forward-Port-Of: odoo/enterprise#79946

**Issue:**
The COA for the French localization has been updated in 2025. Some accounts have been replaced or removed and the reports have been updated with the new formulas.
However, the reports from 2024 are still needed for those who need to print a report for 2024.

**Solution:**
Restore the old reports from 2024 as variants.

opw-4566689
opw-4590293
opw-4572865

Forward-Port-Of: odoo/enterprise#80358
Forward-Port-Of: odoo/enterprise#79946

Followup report title and columns were not added to `.pot` file for translation Forward-Port-Of: odoo/enterprise#80131

Followup report title and columns were not added to `.pot` file for translation

Forward-Port-Of: odoo/enterprise#80131

This PR adds a redirect warning sending the user to the Accounting settings when the certificate or the key is missing before an xbrl export to avoid a traceback and give a friendlier feedback to the user. --- linked to opw-4563442 Forward-Port-Of: odoo/enterprise#80050

This PR adds a redirect warning sending the user to the Accounting settings when the certificate or the key is missing before an xbrl export to avoid a traceback and give a friendlier feedback to the user.

---

linked to opw-4563442

Forward-Port-Of: odoo/enterprise#80050

This PR removes empty replace possibly breaking view inheritence Forward-Port-Of: odoo/enterprise#80200

This PR removes empty replace possibly breaking view inheritence

Forward-Port-Of: odoo/enterprise#80200

this follows commit 0f9d262fb1de2ea4355fc3a6f6d0152e67ccd37e which forgot a few things to enable drag/dropping for fields that are in the view but because of their automatic addition by ir.ui.view when the field is used in an expression. opw-4578365 Forward-Port-Of: odoo/enterprise#80157

this follows commit 0f9d262fb1de2ea4355fc3a6f6d0152e67ccd37e which forgot a few things to enable drag/dropping for fields that are in the view but because of their automatic addition by ir.ui.view when the field is used in an expression.

opw-4578365

Forward-Port-Of: odoo/enterprise#80157

…cies Add a boolean field on hr.contract via studio. Then remove that field from the model. That last operation crashes because _compute_final_yearly_costs has a dynamic depends on it which take many fields of the model. While we don't want to exclude every custom fields (starting with "x_") to continue to allow sufficient extension points we do exclude studio fields specifically, because those are not meant to be used in a complex compute method. After this commit, there is no crash

…cies

Add a boolean field on hr.contract via studio. Then remove that field from the model. That last operation crashes because _compute_final_yearly_costs has a dynamic depends on it which take many fields of the model.

While we don't want to exclude every custom fields (starting with "x_") to continue to allow sufficient extension points we do exclude studio fields specifically, because those are not meant to be used in a complex compute method.

After this commit, there is no crash

opw-4503855

Forward-Port-Of: odoo/enterprise#78963

A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique. runbot-135304 [^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d Forward-Port-Of: odoo/enterprise#80224

A previous commit[^1] disabled the rollback of the subtests. This was leading to the creation of multiple times the same data inside of the same sub transaction, raising a constraint on the company name, which should be unique.

runbot-135304

[^1]: 8f50521be74d0cf858beea3b0aeb59760264ac4d

Forward-Port-Of: odoo/enterprise#80224

Before Commit: ---------------------------- - Quality checks only displayed the product name, making it difficult to distinguish between variants in the same transfer. After Commit: ----------------------------- - Quality checks now display variant details, ensuring clarity and reducing confusion when handling multiple variants of the same product. task-4478249 Forward-Port-Of: odoo/enterprise#77337

Before Commit:
----------------------------
- Quality checks only displayed the product name, making it difficult to distinguish between variants in the same transfer.

After Commit:
-----------------------------
- Quality checks now display variant details, ensuring clarity and reducing confusion when handling multiple variants of the same product.

task-4478249

Forward-Port-Of: odoo/enterprise#77337

### Issue: - When we select a document and click on the "Info and tag" button, a traceback is thrown. ### Steps to reproduce: - Open the documents app - Preview a document - Click on the "Info and tag" in the "Action" dropdown menu - a traceback is thrown ### Solution: - When we click on the "Info and tag" button, `onToggleChatter` is called, in it we try getting the element of the selected document and scrolling to it, if the `querySelector` returns null, and we try to call `scrollI

### Issue:
- When we select a document and click on the "Info and tag" button, a traceback is thrown.

### Steps to reproduce:
- Open the documents app
- Preview a document
- Click on the "Info and tag" in the "Action" dropdown menu
- a traceback is thrown

### Solution:
- When we click on the "Info and tag" button, `onToggleChatter` is called, in it we try getting the element of the selected document and scrolling to it, if the `querySelector` returns null, and we try to call `scrollIntoView` on it, a traceback is thrown.
- we fixed this by adding the optional chaining operator `(?.)` to safely call scrollIntoView only if querySelector returns an element.
- although not directly related to the issue, we also added a small check to disconnect any previous `MutationObserver` before creating a new one.

OPW-4586089

Forward-Port-Of: odoo/enterprise#79975

As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states. task-4557365 Forward-Port-Of: odoo/enterprise#79684

As we support two more states (Alabama and Colorado), this commit adapts the W2 report to include information about those two states.

task-4557365

Forward-Port-Of: odoo/enterprise#79684

…2025 Forward-Port-Of: odoo/enterprise#80170 Forward-Port-Of: odoo/enterprise#80030

…2025

Forward-Port-Of: odoo/enterprise#80170
Forward-Port-Of: odoo/enterprise#80030

The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution. Traceback: (VALUES where removed for readability, there were 100 of them) ``` 2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "accoun

The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock.

Notes:
We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution.

Traceback: (VALUES where removed for readability, there were 100 of them)
```
2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "account_bank_statement_line"
SET "cron_last_check" = "__tmp"."cron_last_check"::timestamp, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (...), (...), (...), (...), ) AS "__tmp"("id", "cron_last_check", "write_date", "write_uid")
WHERE "account_bank_statement_line"."id" = "__tmp"."id"'
ERROR: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"

2025-01-27 12:00:39,277 3822296 ERROR openerp odoo.addons.base.models.ir_cron: Job 'Try to reconcile automatically your statement lines' (297) server action #4952 failed
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_cron.py", line 572, in _callback
    self.env.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 833, in flush_all
    self[model_name].flush_model()
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6707, in flush_model
    self._flush(fnames)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6784, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4881, in _write_multi
    self.env.execute_query(SQL(
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 962, in execute_query
    self.cr.execute(query)
  File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 373, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL:  Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (10685,6) in relation "account_bank_statement_line"
```

task-id: 4393854

Forward-Port-Of: odoo/enterprise#80059

When toggling columns in any Accounting Report list view, it requires a manual refresh to see the changes. this is caused because this [commit](odoo/enterprise@adc4bb7) removed automatic reactivity, so we need to explicitly recompute the columns after updating optionalActiveFields To resolve this, we override the ListRenderer's `toggleOptionalField` function to explicitly recompute columns before rendering. Steps to reproduce: 0. Activate developer mode 1. Navigate to the 'Accounting Re

When toggling columns in any Accounting Report list view, it requires a manual refresh to see the changes.
this is caused because this [commit](odoo/enterprise@adc4bb7) removed automatic reactivity, so we need to explicitly recompute the columns after updating optionalActiveFields

To resolve this, we override the ListRenderer's `toggleOptionalField` function to explicitly recompute columns before rendering.

Steps to reproduce:
0. Activate developer mode
1. Navigate to the 'Accounting Reports' menu in accounting.
2. Open a report (e.g. the balance sheet)
3. Use the column selector to add or remove additional columns

OPW-4352833

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

Forward-Port-Of: odoo/enterprise#79592

Forward-Port-Of: odoo/enterprise#75261

Forward-Port-Of: odoo/enterprise#75261

An error occurs when the system tries to access single values from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/71747a21cb5c68a8ab151434f85c822f30649aad/stock_barcode/models/res_config_settings.py#L14-L15 Traceback On Sentry: ``` ValueError: too many values to unpack (expected 1) File "odoo/orm/models.py", line 6073, in ensure_one _id, = self._ids ValueError: Expected singleton: res.config.settings(52, 53) File "odoo/http.py", line 2420, in __c

An error occurs when the system tries to access single values from multiple records at [1].

Link [1]: https://github.com/odoo/enterprise/blob/71747a21cb5c68a8ab151434f85c822f30649aad/stock_barcode/models/res_config_settings.py#L14-L15

Traceback On Sentry:

```
ValueError: too many values to unpack (expected 1)
  File "odoo/orm/models.py", line 6073, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.config.settings(52, 53)
  File "odoo/http.py", line 2420, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1946, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 2010, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1977, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2228, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 335, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 741, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 31, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/service/model.py", line 62, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "odoo/orm/models.py", line 3611, in read
    return self._read_format(fnames=fields, load=load)
  File "odoo/orm/models.py", line 3841, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/orm/models.py", line 6880, in __getitem__
    return self._fields[key].__get__(self)
  File "odoo/orm/fields.py", line 1428, in __get__
    self.compute_value(recs)
  File "odoo/orm/fields.py", line 1594, in compute_value
    records._compute_field_value(self)
  File "odoo/orm/models.py", line 5055, in _compute_field_value
    determine(field.compute, self)
  File "odoo/orm/fields.py", line 70, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-18.1/stock_barcode/models/res_config_settings.py", line 32, in _compute_show_barcode_nomenclature
    self.show_barcode_nomenclature = self.module_stock_barcode and self.env['barcode.nomenclature'].search_count([]) > 1
  File "odoo/orm/fields.py", line 1369, in __get__
    record.ensure_one()
  File "odoo/orm/models.py", line 6076, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```


To resolve this issue, Use an iteration(for loop) to iterate records one by one.

Sentry-6296116940

Forward-Port-Of: odoo/enterprise#79320