During a major upgrade the registry my be `loaded` but not `ready`. https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/odoo/modules/registry.py#L159-L160 This causes unnecessary warnings during upgrades (blocking the CI). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186467

During a major upgrade the registry my be `loaded` but not `ready`. https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/odoo/modules/registry.py#L159-L160

This causes unnecessary warnings during upgrades (blocking the CI).

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

Forward-Port-Of: odoo/odoo#186467

Fixed issue introduced in this PR: https://github.com/odoo/odoo/pull/119154. In the above PR, the recurring setting was removed, but the recurring groups were not removed from the group configuration, which caused the group's string to still appear. This issue has now been fixed. Steps to Reproduce and Verify the Fix: 1) Install the Project App. 2) Go to the Project App. 3) Activate the Recurring Feature in the settings. 4) Open any project and verify

Fixed issue introduced in this PR: https://github.com/odoo/odoo/pull/119154.

  In the above PR, the recurring setting was removed, but the recurring groups
  were not removed from the group configuration, which caused the group's string
  to still appear. This issue has now been fixed.

  Steps to Reproduce and Verify the Fix:
      1) Install the Project App.
      2) Go to the Project App.
      3) Activate the Recurring Feature in the settings.
      4) Open any project and verify the settings.

  task-4260042



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

Forward-Port-Of: odoo/odoo#183861

System shows Enterprise Widget on E-invoice module Although the module is available in community addons Steps to Reproduce : Run only community Install l10n_in module. Now Go to the Settings -> Invoicing. See the Enterprise Widget is on E-Invoice (Indian Integration). 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/submi

System shows Enterprise Widget on E-invoice  module

Although the module is available in community addons

Steps to Reproduce :
Run only community
Install l10n_in module.
Now Go to the Settings -> Invoicing.
See the Enterprise Widget is on E-Invoice (Indian Integration).

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

We can have a user that has enough rights to generate sales orders, but not enough right to check a BoM. When creating a new sale order for a kit, everything works fine. Before this commit, if we updated the quantity on the sale order line, the quantity on the moves would become incorrect. After this commit, the BoM is always found in order to correctly recompute the quantity on the moves. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwar

We can have a user that has enough rights to generate sales orders, but not enough right to check a BoM.
When creating a new sale order for a kit, everything works fine.

Before this commit, if we updated the quantity on the sale order line, the quantity on the moves would become incorrect.

After this commit, the BoM is always found in order to correctly recompute the quantity on the moves.

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

Forward-Port-Of: odoo/odoo#180442

Description of the issue/feature this PR addresses: - Improve _get_report_lines performance Current behavior before PR: - A lag is seen when opening Manufacturing orders, because it goes to compute `components_availability`, calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/mrp/models/mrp_production.py#L344 function, which ends up calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.

Description of the issue/feature this PR addresses:
- Improve  _get_report_lines performance

Current behavior before PR:
- A lag is seen when opening Manufacturing orders, because it goes to compute `components_availability`, calling
https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/mrp/models/mrp_production.py#L344 function, which ends up calling https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L190 
- currently, in `_get_report_lines` function, **transit_stock**
https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L353  is calculated by summing quantities with list comprehension on the **currents** dictionary for each product.
https://github.com/odoo/odoo/blob/0d3ab1203ad00e2c41768f3209e45cd673e519e7/addons/stock/report/stock_forecasted.py#L327  
- This becomes slow when handling huge number of products and large currents entries. due to O(n * m) complexity

Desired behavior after PR is merged:
- A dictionary of pre-computed product quantity, minimizes the time taken.

### Here are few benchmarks and stats.

**At time of function call :** 
- As the test database is populated with 2 location ids `_get_report_lines` is called twice during testing, because of https://github.com/odoo/odoo/blob/6e9ace2df2dd3750472c227f818d3dc8d5ba5016/addons/stock/models/stock_move.py#L515-L517
- size of currents dict :  2539 + 2600 
- No. of product :  2539 + 2412

## Before
![before](https://github.com/user-attachments/assets/f99c11b3-ee11-4b09-80c1-e769589b6156)

## After
![after](https://github.com/user-attachments/assets/597687dc-fc1f-452f-b5a5-e5579880ed61)

opw- 4285618
upg- 2179723

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

Forward-Port-Of: odoo/odoo#186238

Before this PR, pressing `Escape` while renaming a thread in the chat window closed the entire chat window instead of simply exiting the rename mode. This PR ensures that pressing `Escape` only exits the rename action, keeping the chat window open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185833

Before this PR, pressing `Escape` while renaming a thread in the chat window closed the entire chat window instead of simply exiting the rename mode.
This PR ensures that pressing `Escape` only exits the rename action, keeping the chat window open.

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

Forward-Port-Of: odoo/odoo#185833

When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified

When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted.

Steps to reproduce:
- Send a message on a record, add a recipient with an incorrect email.
- A red enveloppe is displayed next to the message and a notification is added in the messaging menu.
- Delete this record.
- Try to mark this failure as read.
- Nothing happens.

This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue.

opw-4272165

Forward-Port-Of: odoo/odoo#186000

When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Re

When a user disconnects from a device, the server assumes he is
disconnected until another device/browser says otherwise. However,
this can lead to small flickers. This PR fixes the issue by debouncing
the update of the im status field of the persona model. This way, there
is no flickering.

Steps to reproduce the issue:
- Open two browser windows with mitchell admin in the discuss app
(incognito + regular windows).
- Go to the chat with your self, where the im status can be seen.
- Reload one tab several times: you can sometimes see a flicker from
online to offline.

task-4236550

Forward-Port-Of: odoo/odoo#184825

**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected behavior:** AMLs generated for this move have 0 quantity. **Steps to reproduce:** *Having accounting, purchase_stock* 1. Create a storable product with `average` costing 2. Create a purchase order for some of the product with some arbitrary price unit, receive the product 3. In

**Current behavior:**
Manually adjusting a FIFO/AVCO product's cost creates a journal
items with non-zero quantity, despite there not being a logical
quantity associated with this entry.

**Expected behavior:**
AMLs generated for this move have 0 quantity.

**Steps to reproduce:**
*Having accounting, purchase_stock*
1. Create a storable product with `average` costing

2. Create a purchase order for some of the product with some
     arbitrary price unit, receive the product

3. In the product form, change the cost to a smaller value

4. In the journal items pivot view, select the `quantity` field
     from the 'Measures' dropdown in the top left, expand the
     stock valuation journal on the left axis, observe that the
     change in cost has created 2 balancing AMLs, each with
     quantity == 1

**Cause of the issue:**
This case was not handled and quantity is always set to 1 if
falsy.

**Fix:**
Create the AMLs created in the cost change handle with
quantity=0. While it does risk being overwritten to 1 if the
`display_type` of the line changes, the diff is minimal and
use-case is non-critical- which makes it the best solution here.

opw-4090620

Forward-Port-Of: odoo/odoo#186304
Forward-Port-Of: odoo/odoo#180998

Before this commit, when the accrual cron was running and there was a leave in the future to account for, it would calculate the number of days by processing a fake allocation and invalidating it afterwards. However, the cache invalidation was too aggressive and would also invalidate any changes that were made to existing accrual allocations that were not yet flushed. This commit fixes this behavior by invalidating the recordset so as to only invalidate the fake allocations. opw-4200067 F

Before this commit, when the accrual cron was running and there was a leave in the future to account for, it would calculate the number of days by processing a fake allocation and invalidating it afterwards. However, the cache invalidation was too aggressive and would also invalidate any changes that were made to existing accrual allocations that were not yet flushed.

This commit fixes this behavior by invalidating the recordset so as to only invalidate the fake allocations.

opw-4200067

Forward-Port-Of: odoo/odoo#185957

Blacklist Odoo in your browser from having access to the local and session storages (security parameters). Before this commit, there were unrecoverable crashes because even doing `window.[localStorage|sessionStorage]` is forbidden. After this commit, we catch those exceptions and make a RamStorage instead. opw-4226366 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

Blacklist Odoo in your browser from having access to the local and session storages (security parameters).

Before this commit, there were unrecoverable crashes because even doing `window.[localStorage|sessionStorage]` is forbidden.

After this commit, we catch those exceptions and make a RamStorage instead.

opw-4226366

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#186294
Forward-Port-Of: odoo/odoo#185811

- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559

- Update CoA
- Update taxes
- Update tax groups
- Update reports
- Update fiscal positions

Courtesy of `Editor.si` for providing data in order to update the files.

Enterprise PR: odoo/enterprise#65817

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

Forward-Port-Of: odoo/odoo#166559

Use loops with clear input/expected structure to ease changes and debugging. Add few tests while passing by. Task-3943087 Forward-Port-Of: odoo/odoo#186468

Use loops with clear input/expected structure to ease changes and debugging. Add few tests while passing by.

Task-3943087

Forward-Port-Of: odoo/odoo#186468

When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). By adding the minlength attribute

When trying to sign in (for a new user) after making a purchase (existing token), we can choose a password of less than the minimum length allowed in the configuration. 
The _check_password_policy method prevents the save of the password to the user but arrives too late in the flow as the initiation of the user creation is half done leading to an Invalid token issue at the next attempt (no partner found for the existing token with _signup_retrieve_partner). 

By adding the minlength attribute in the form of the sign up, we force the respect of the password policy minimum length in the front end and minimize the risk to encounter the issue. 

opw-4182543

Forward-Port-Of: odoo/odoo#185139

**Steps to reproduce the bug:** - Create two storable products, “P1” and “P2”. - Set “P1” to be tracked by Serial Number - Update P1 with SN1. - Create a repair order: - Set P1 with SN1. - Save. - Edit and update the product to P2. - Save. - Print the order. **Problem:** The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is no

**Steps to reproduce the bug:**
- Create two storable products, “P1” and “P2”.
- Set “P1” to be tracked by Serial Number
- Update P1 with SN1.
- Create a repair order:
   - Set P1 with SN1.
   - Save.
- Edit and update the product to P2.
- Save.
- Print the order.

**Problem:**
The “lot_id” is not cleared and appears in the report because the “lot_id” field becomes invisible and read-only under the same condition. Since it is read-only and not force-saved, the value of “lot_id” is not considered in the write of the repair order, even though the `onchange` sets the “lot_id” field to False:

https://github.com/odoo/odoo/blob/16.0/addons/repair/models/repair.py#L208-L212

**opw-4281176**

Forward-Port-Of: odoo/odoo#185906
Forward-Port-Of: odoo/odoo#185552

### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_auto

### Analysis 
Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on.

Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation.

### Solution
In this commit, we update the `date_automation_last` after filtering the records by checking the `trigger_field_ids`.

## Benchmarks
Measuring `web_save` when updating the stage of a lead in the Kanban view of CRM:
| # `crm.lead `   | # `automation.rule` on crm.lead | Before | After | %
| -------------------- | -----| -- | ---------- | --------
|  970 records| 6 |  1.5s   | 0.3 s | - ~80%

### References
opw-4263443

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

Forward-Port-Of: odoo/odoo#186487

Steps to reproduce: - In edit mode, drop a "Text-Image" snippet. - In the text column, add 4 columns with the powerbox (type "/" then "columns"). - In each column, add an image. => The two outer columns image have the same size, which is bigger than the inner ones. This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in

Steps to reproduce:
- In edit mode, drop a "Text-Image" snippet.
- In the text column, add 4 columns with the powerbox (type "/" then "columns").
- In each column, add an image.
 => The two outer columns image have the same size, which is bigger than the inner ones.

This happens because in commit [1], in order for the columns to be well aligned with the rest of the content, the left padding of the first column and the right padding of the last one have been forced to 0px. This resulted in the columns content having different sizes depending on their position.

Moreover, this was not a good solution because if we added more columns (by duplicating them) such that they go on multiple lines, the last one of the first line would not be correctly aligned to the content, because it is not the last column so it would keep its right padding. This would also result in the columns being shifted compared to the first line.

This commit fixes that by removing the rules added by commit [1], as the columns were already aligned without them. The row margins are then set so they compensate the grid item padding, for the case when we are in grid mode, to avoid overflow. Note that if the padding is under 15px, the columns are not aligned anymore, but this is the compromise to have identical columns.

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

opw-4172256

Forward-Port-Of: odoo/odoo#186613
Forward-Port-Of: odoo/odoo#182951