The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is that the list of IDs can be gigantic, leading to performance issues. Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report. That PR then simply bypassed the issue by passing t

The model 347 report is adding a partner exclusion domain in the search call.
It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf.
The issue is that the list of IDs can be gigantic, leading to performance issues.

Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report.
That PR then simply bypassed the issue by passing the domain as `forced_domain` so it would not go through the `literal_eval()` call (which is the one crashing when the list is too long).

But even after that fix, we still provide the list of IDs into the domain and so ultimately in the SQL request, which can still be an issue if there are too many.

This commit improves that by passing the SQL subquery (the one fetching the partners to exclude) directly into the domain, so the SQL query won't contain any list of IDs but just a sub-select. It does have better performance within PostgreSQL for big lists.

Note that the `SQL()` query is surrounded by parentheses on purpose, as it doesn't work otherwise. This might be improved at the ORM level in the future with odoo/odoo#163560.

Task [link](https://www.odoo.com/web#model=project.task&id=3895983)
task-3895983

Forward-Port-Of: odoo/enterprise#62866

This addresses several issues: - on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved - make this view clearer by separating the product and the other fields - 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant - fix component remaining quantity when no producing quantity has been set - generate a new pdf for barcodes: add print barcode & new ghostscript version seems t

This addresses several issues:

- on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved

- make this view clearer by separating the product and the other fields

- 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant

- fix component remaining quantity when no producing quantity has been set

- generate a new pdf for barcodes: add print barcode & new ghostscript
  version seems to solve some erratic scanning problems

task: 3987346

Forward-Port-Of: odoo/enterprise#66652
Forward-Port-Of: odoo/enterprise#65396

The settle due accounts was not always shown on the partner screen. Now it's always shown, and when the user doesn't have any amount due the text changes to "Deposit Money" instead of "Settle Due Accounts" Steps to reproduce: ------------------- * Install pos_settle_due module * Open PoS session * Open partner list * Click on details for any partner with no due > Observation: The "Settle Due Accounts" button is missing Why the fix: ------------ We always show the button, but change

The settle due accounts was not always shown on the partner screen. Now it's always shown, and when the user doesn't have any amount due the text changes to "Deposit Money" instead of "Settle Due Accounts"

Steps to reproduce:
-------------------
* Install pos_settle_due module
* Open PoS session
* Open partner list
* Click on details for any partner with no due
> Observation: The "Settle Due Accounts" button is missing

Why the fix:
------------
We always show the button, but change the text to better match the behavior. If there is no amount due the text says "Deposit Money" and when the user has some amount due it says "Settle Due Accounts"

opw-3925397

Forward-Port-Of: odoo/enterprise#66486
Forward-Port-Of: odoo/enterprise#65762

Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f388448

Steps to reproduce:
- Install "Field Service"
- Open "Project"
- Open the settings of a random project
- Then click on the "Settings" tab
- Disable "Field Service" and enable "Worksheets"
- Create a new task with a worksheet
- Click on start then stop and save
- Click on "Sign Report"

Issues:
The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled.

https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f38844861d9ed4e442/industry_fsm/views/project_portal_templates.xml?plain=1#L42

opw-4032692

Forward-Port-Of: odoo/enterprise#66599
Forward-Port-Of: odoo/enterprise#66057

vat base and change exempt base to exports account. Forward-Port-Of: odoo/enterprise#66086

vat base and change exempt base to exports account.

Forward-Port-Of: odoo/enterprise#66086

**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#63303 Forward-Port-Of: odoo/enterprise#59530

**Current behavior before PR:**

In mobile view, whatsapp tab had no search button.

**Desired behavior after PR is merged:**

In mobile view, added a search button to find whatsapp channel.

task-id:3525542

Forward-Port-Of: odoo/enterprise#63303
Forward-Port-Of: odoo/enterprise#59530

…dated on template change" This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon. This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c. Task-3996935 Forward-Port-Of: odoo/enterprise#66727

…dated on template change"

This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon.

This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c.

Task-3996935

Forward-Port-Of: odoo/enterprise#66727

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail. runbot-71136 Forward-Port-Of: odoo/enterprise#66739

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail.

runbot-71136

Forward-Port-Of: odoo/enterprise#66739

To reproduce: - install l10n_be_intrastat and sale_management, switch to the company BE company CoA - Settings > Sales > Product Catalog, activate the "Unit of Measure" setting - Go to Sales/Configuration/Units of Measure/Units of Measure menu - Create a new units of measure; set the category to "Weight" as Reference Unit of Measure, uncheck the Active checkbox to archive it - Create an invoice for the contact having country Germany and with a product having commodity code, weight, etc se

To reproduce:

- install l10n_be_intrastat and sale_management, switch to the company BE company CoA
- Settings > Sales > Product Catalog, activate the "Unit of Measure" setting
- Go to Sales/Configuration/Units of Measure/Units of Measure menu
- Create a new units of measure; set the category to "Weight" as Reference Unit of Measure, uncheck the Active checkbox to archive it
- Create an invoice for the contact having country Germany and with a product having commodity code, weight, etc set for the intrastate report
- Validate the invoice and check the intrastate report for "This Fiscal Year"

Result -  The report lines appear twice

Expected - The report shouldn't consider archived UoM, lines should appear only once

OPW - 3915784

Additional info:
This behavior happened because in the following refactor PR,
https://github.com/odoo/enterprise/pull/31893/files#diff-7b1b123893744b02df76c7fa971ebb68b9f59e26f619e3a7d8f290c0f45ed037L368
We forgot to re-add the following line as a condition in the where clause:
`ref_weight_uom.active`

Forward-Port-Of: odoo/enterprise#66223
Forward-Port-Of: odoo/enterprise#64500

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report. opw-4037481 Forward-Port-Of: odoo/enterprise#66666 Forward-Port-Of: odoo/enterprise#66343

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report.

opw-4037481

Forward-Port-Of: odoo/enterprise#66666
Forward-Port-Of: odoo/enterprise#66343

…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Sol

…d warning

Steps to reproduce:
- Go to Accounting/Reporting/Tax Report;
- Make sure there is a negative amount in the tax report;
- Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report";
- Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s);

Issue:
On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals

Solution:
We get the journal defined for the Tax Return Periodicity. If no journal defined;
We keep only the first Misc journal that is found

This way, we let the user have custom misc journals (fec import or custom coa)

opw-4004375

Forward-Port-Of: odoo/enterprise#66346

Currently, an error occurs when the payment status is failed, expired, or failed. Steps to produce an error: - Install `sale_subscription` and `payment_mollie` - setup `mollie` payment provider in testing - Create an invoice for the subscription and confirm it - Click preview of the invoice and click Pay Now. - fill card details, and on the on the next page, select failed or expired in payment status - Confirm error:  `PaymentTransaction._set_canceled() takes 1 positional argument b

Currently, an error occurs when the payment status is failed, expired, or failed.

Steps to produce an error:
- Install `sale_subscription` and `payment_mollie`
- setup `mollie` payment provider in testing
- Create an invoice for the subscription and confirm it
- Click preview of the invoice and click Pay Now.
- fill card details, and on the on the next page, select failed or expired in payment status
- Confirm

error: 
`PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given`

This is because at code [1], we have passed `**kwargs` as arguments in super call, and as a result, it sets all arguments of kwargs in agruments, e.g., 2 of super call, but method call requires one positional argument.

This commit will fix the above issue by passing a positional argument with kwargs in the super call.

[1]-https://github.com/odoo/enterprise/blob/43621084d0cf95970eb6e45cf67bcb20ec14b8b3/sale_subscription/models/payment_transaction.py#L186

sentry-5606090812

Forward-Port-Of: odoo/enterprise#66664

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made.

opw-3987849

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

Forward-Port-Of: odoo/odoo#173282

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models. By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models.

By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

Also add the same custom `trigram` index to support `like/ilike` operators in domains.

task-3942852

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

Forward-Port-Of: odoo/odoo#166698

Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order. Forward-Port-Of: odoo/odoo#173292

Before this commit, the self order was created with the user of the
current session. This is not the expected behavior, as the self order
is always accessed by a public user.

This commit fixes this by always using the self user for the self order.

Forward-Port-Of: odoo/odoo#173292

before this commit, a traceback was showing on creating product variant steps to reproduce: * click create button in product, traceback will be showing after this commit, without any traceback product is created traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7 traceback details:  super()._compute_display_name() File "/da

before this commit, a traceback was showing on creating product variant

steps to reproduce:
* click create button in product, traceback will be showing

after this commit, without any traceback product is created

traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7

traceback details:

![2024-07-08_14-02](https://github.com/odoo/odoo/assets/99093808/fc3c5132-3e22-478f-8b93-2daf60877bc0)

super()._compute_display_name()
File "/data/build/enterprise/sale_renting/models/product_product.py", line 14, in _compute_display_name
super()._compute_display_name()
File "/data/build/odoo/addons/l10n_gcc_invoice/models/product.py", line 23, in _compute_display_name
product.display_name = re.sub(r'(\d)(\s)([\u0600-\u06FF])', repl, product.display_name)
File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object

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

Forward-Port-Of: odoo/odoo#172240

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985 Forward-Port-Of: odoo/odoo#171416

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones

Expected deferred accounts:
- Expense: 486000
- Revenue: 487000

task-383985

Forward-Port-Of: odoo/odoo#171416

### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user. This is happening because when getting the changed values to use it in the create operation it will check if the organizer

### Steps to reproduce:
	- Install Calendar module
	- Create a new event
	- Change the organzier to Marc Demo and then add him as attendee
	- Save the event

### Current behavior before PR:
When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user.
This is happening because when getting the changed values to use it in the create operation it will check if the organizer field is readonly https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/model/relational_model/record.js#L592:L597 It will be true and it is readonly because of the computed field in the calendar.event 'user_can_edit' where when it checks who can edit the event before creating it the 'partner_ids' will be found as 'NewId' not yet 'res.partner'
https://github.com/odoo/odoo/blob/17.0/addons/calendar/models/calendar_event.py#L296

### Desired behavior after PR is merged:
We can change the organizer of the event before assign the attendees or creating the event. As we are now checking the ids itself not the whole object of the partner_ids

opw-3908333

Forward-Port-Of: odoo/odoo#172680

**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166934 Forward-Port-Of: odoo/odoo#159461

**Current behavior before PR:**

In mobile view, whatsapp tab had no search button.

**Desired behavior after PR is merged:**

In mobile view, added a search button to find whatsapp channel.

task-id:3525542





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

Forward-Port-Of: odoo/odoo#166934
Forward-Port-Of: odoo/odoo#159461

Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611

Fix of the COA:
There was a bad assignation in the account rate difference profit/loss.

As these are minor changes, we make this together with changes in the F29 report VAT base

https://github.com/odoo/enterprise/pull/55365





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

Forward-Port-Of: odoo/odoo#170301
Forward-Port-Of: odoo/odoo#151611

…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760

…ecordset

Steps to reproduce:
install hr_expense with demo data
try to make a jsonrpc or any search on product.product with no domain ->key error

Before PR:
When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys

opw-3741337

Forward-Port-Of: odoo/odoo#170300
Forward-Port-Of: odoo/odoo#154760

This fixes the syntax error on function _perform_analytic_distribution of the model AccountAnalyticAccount. opw-3907439 Description of the issue/feature this PR addresses and current behavior before PR: - The _perform_analytic_distribution function on model AccountAnalyticAccount has a syntax error causing a UnboundLocalError Desired behavior after PR is merged: - No UnboundLocalError --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For

This fixes the syntax error on function _perform_analytic_distribution of the model AccountAnalyticAccount.

opw-3907439

Description of the issue/feature this PR addresses and current behavior before PR:

- The _perform_analytic_distribution function on model AccountAnalyticAccount has a syntax error causing a UnboundLocalError

Desired behavior after PR is merged:

- No UnboundLocalError

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

Forward-Port-Of: odoo/odoo#168582

This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with. When using the days end of month payment term with a days_next_month to 0, the calculation was wrong. Ex: With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will

This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with.

When using the days end of month payment term with a days_next_month to 0, the calculation was wrong.

Ex:
With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will end up the 01/06.

With a days_next_month to 0, the problem is that the relative delta will keep the 22/06 which is not what we wanted.

task: 4045689




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

Forward-Port-Of: odoo/odoo#172609

### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified. 3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines. #### > the date is changed on all the lines #### Use case 2: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new li

### Steps to reproduce

#### Use case 1:

1. Create a PO with 2 lines having different "expected arrival".
2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified.
3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines.
#### > the date is changed on all the lines

#### Use case 2:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line on the SO and set a product
#### > the date is changed on all the lines

#### Use case 3:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line for a product with at least 2 product variant and complete his grid for quantities
#### > the date is changed on all the lines

### Cause of the issue:

The `date_planned` fields of the `purchase.order` and `purchase.order.line` are both computed and stored.  When the `date_planned` of a line (new or already existing) is changed, it triggers the compute method of the `date_planned` of the purchase order and changes it: https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L184-L190 
This will in turn trigger the `onchange_date_planned` of the purchase order since we are in the Form view of that model and will update the "planned_date" of every other existing line accordingly:
https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L229-L232

### Fix

We add back the override of the onchange that was present in previous versions and removed in the onchange refactoring made in commit https://github.com/odoo/odoo/commit/109935dbc10256bebb1f5ee0d76a23df7ea91e9f. The purpose of this override being to remove any update of the 'date_planned' of the POL's from the onchange call if this one was triggered by a change of an POL.

#### Note: 
The third use case was fixed by commit 387e9a4 by adding the `_must_delete_date_planned` method but this fix becomes ineffective without the onchange override.

opw-4000019
opw-4012390
opw-4028100
---

Forward-Port-Of: odoo/odoo#171769

This commits only just add partnerlist tour methods required for this fix https://github.com/odoo/enterprise/pull/65762 opw-3925397 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172744 Forward-Port-Of: odoo/odoo#171260

This commits only just add partnerlist tour methods required for this fix https://github.com/odoo/enterprise/pull/65762

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

Forward-Port-Of: odoo/odoo#172744
Forward-Port-Of: odoo/odoo#171260

Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR

Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF

Current behavior before PR: PDF show the unicode characters
![image](https://github.com/odoo/odoo/assets/30716308/73f3b03a-0ccc-4ca4-bc51-dab7c9f557b6)


Desired behavior after PR is merged: no more unicode characters




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

Forward-Port-Of: odoo/odoo#172490

NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs. In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that. (cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024) 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 t

NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs.

In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that.

(cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024)

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#173224
Forward-Port-Of: odoo/odoo#173151

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173112 Forward-Port-Of: odoo/odoo#172413

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes.


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

Forward-Port-Of: odoo/odoo#173112
Forward-Port-Of: odoo/odoo#172413

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`. This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`.

This commit simply performs a quick raw SQL check to ensure  no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

Running the populate command 4 times in a row will produce the following results:
```
select id,default_code, barcode from product_product order by id desc;

 id  | default_code |          barcode
-----+--------------+----------------------------
 639 | PP-150       | BARCODE-PP-150-150-150-150
 638 | PP-149       | BARCODE-PP-150-150-150-149
              ...
```

Another option would have been to use a fully randomized string, but avoiding randomness is preferable, especially when considering the case of running the populate command only once.

Note that the `product.product` model is the only problematic one when
running back to back `populate` on all models used by accounting:
- account.move
- account.journal
- account.bank.statement
- account.bank.statement.line
- account.payment
- account.reconcile.model
- account.reconcile.model.line
- res.company
- res.partner
- res.partner.industry
- product.product
- product.category
- ...probably more through `_populate_dependencies`...

task-3821088

Forward-Port-Of: odoo/odoo#166365

Specification: The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog. Expected behavior: The automation rule ID and name are visible, and both buttons work as expected. Task-3959044 Forward-Port-Of: odoo/odoo#171486

Specification:
The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog.

Expected behavior:
The automation rule ID and name are visible, and both buttons work as expected.

Task-3959044

Forward-Port-Of: odoo/odoo#171486

To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565 Forward-Port-Of: odoo/odoo#171104

To reproduce the bug:
1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5.
2. Go to the website and add a product to the cart.
3. Go to the cart and click on the "+" button.

Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend.

opw-3990565

Forward-Port-Of: odoo/odoo#171104

Before this commit: When you click `Send & Print` for an invoice with removing the attachments => It shows an error with a traceback `psycopg2.errors.SyntaxError: syntax error at or near ")" LINE 1: UPDATE ir_attachment SET res_id = NULL WHERE id IN ()` After this commit: `Send & Print` process works properly with removing attachments. opw-4047545 Forward-Port-Of: odoo/odoo#173371

Before this commit:
When you click `Send & Print` for an invoice with removing the attachments 
=> It shows an error with a traceback `psycopg2.errors.SyntaxError: syntax error at or near ")" LINE 1: UPDATE ir_attachment SET res_id = NULL WHERE id IN ()`

After this commit:
`Send & Print` process works properly with removing attachments.

opw-4047545

Forward-Port-Of: odoo/odoo#173371

Fix for 17.1 and 17.2 only Problem: en_US data is loaded while the user uses another language Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Change the language (e.g. to french) - Go to POS -> Products -> Discount & Loyalty - Create a new Loyalty Card - In Rewards, set a discount of 20 $ on order and save - Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable) - Click on "Reward", the e

Fix for 17.1 and 17.2 only

Problem:
en_US data is loaded while the user uses another language

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Change the language (e.g. to french)
- Go to POS -> Products -> Discount & Loyalty
- Create a new Loyalty Card
- In Rewards, set a discount of 20 $ on order and save
- Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable)
- Click on "Reward", the earlier created reward is there
- Go back to the form of the loyalty card and change the value and save
- Go back to the shop
- Click on "Reward" and the name of the loyalty card is still the same as before while it should be for the new price

Note:
This error has been already fixed but this commit generalize the solution to all the params. So the previous fix is replaced by this one.
See this PR for the previous fix and the test: https://github.com/odoo/odoo/pull/171049

Solution:
Set the environment context for each data param so that the language is loaded by creating a wrapper. Only apply a context if some has not already been defined for specific cases where a different context is needed. "_load_data_params_with_context" replaces "_load_data_params" only where the context is used to keep a bit of optimization.

opw-4039850


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

Forward-Port-Of: odoo/odoo#172769

A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query. Description of the issue/feature this PR addresses: Creating an analytic account is slow on a db with 1.5M account.analytic.line. Current behavior before PR: Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39 Desired behavior after PR is merged: Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9 --- I confirm I have signe

A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query.

Description of the issue/feature this PR addresses:
Creating an analytic account is slow on a db with 1.5M account.analytic.line.

Current behavior before PR:
Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39

Desired behavior after PR is merged:
Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9


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

Forward-Port-Of: odoo/odoo#173437