Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry. This fix adds the missing inverse command. OWP: 3966053 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168744

Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry.

This fix adds the missing inverse command.

OWP: 3966053





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

Forward-Port-Of: odoo/odoo#168744

The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language. opw-3976888 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#168567 Forward-Port-Of: odoo/odoo#168482

The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language.

opw-3976888

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#168567
Forward-Port-Of: odoo/odoo#168482

This reverts commit d6bacc6859a30afbbe57ba3be0c7c77ebd6c5c60. Cause: https://github.com/odoo/enterprise/pull/63268#issuecomment-2160019128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168815

This reverts commit d6bacc6859a30afbbe57ba3be0c7c77ebd6c5c60.

Cause: https://github.com/odoo/enterprise/pull/63268#issuecomment-2160019128


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

Forward-Port-Of: odoo/odoo#168815

## Description As an internal user one has access to many timesheets as if from the backend. If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of reco

## Description
As an internal user one has access to many timesheets as if from the backend.
If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of records, this leads to an Memory Error (OOM).

## Benchmark
On a database with over 4+M of timesheets matching the domain:
|        | Before    | After |
|--------|-----------|-------|
| Timing | N/A (OOM) | 0.7s  |

## Reference
task-3977971

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

Forward-Port-Of: odoo/odoo#168549

Steps: - Install Ecom. - Buy a product without login and set different address for billing and shipping. Issue: - SO email sent to both billing and shipping emails it should only be sent to billing (main address). Cause: - In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails. Fix: - Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal

Steps:
- Install Ecom.
- Buy a product without login and set different address for billing and shipping.

Issue:
- SO email sent to both billing and shipping emails it should only be sent to billing (main address).

Cause:
- In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails.

Fix:
- Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal Sales flow.

opw-3714686

Forward-Port-Of: odoo/odoo#168259

Steps: - Create a quotation template with 2+ products and optional products. - Create a new quotation using the template. - Add an optional product from the template. Issue: - Optional product is not added at the end of the quotation. Cause: - Optional product sequence defaults to 10 instead of continuing the sequence. Fix: - Adjust the sequence of added optional products in add_order_button to be the max sequence + 1. opw-3932966 I confirm I have signed the CLA and read the P

Steps:
- Create a quotation template with 2+ products and optional products.
- Create a new quotation using the template.
- Add an optional product from the template.

Issue:
- Optional product is not added at the end of the quotation.

Cause:
- Optional product sequence defaults to 10 instead of continuing the sequence.

Fix:
- Adjust the sequence of added optional products in add_order_button to be the max sequence + 1.

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

Forward-Port-Of: odoo/odoo#168311

Currently, when buying products with variants the attribute values are not reflected on the backend order. Steps to reproduce: ------------------- * Go to the **Point of Sale** app * Open a shop session * Make an order for the product `Desk Organizer` * Select any option from the product configuration popup * Pay and Validate the order * Go in the backend * Navigate to **Orders** * Select the last order > Observation: Selected options for the product are not reflected Why the fix

Currently, when buying products with variants the attribute values are not reflected on the backend order.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** app
* Open a shop session
* Make an order for the product `Desk Organizer`
* Select any option from the product configuration popup
* Pay and Validate the order
* Go in the backend
* Navigate to **Orders**
* Select the last order
> Observation: Selected options for the product are not reflected

Why the fix:
------------
The function `set_full_product_name()` was changed with https://github.com/odoo/odoo/commit/672c853ab7d77ac1cebd2f4d16bd98fc454b2d55

It basically changed the behavior to set the `full_product_name` to `display_name` where it was previously computed with the attribute values.

The fix is based on the fix made for the `pos_retaurant` module. https://github.com/odoo/odoo/commit/3b6455eb979078354e3b1009a354ca7010e5fec9

This will re-introduce a feature removed from the first commit mentioned which is to show the attribute values in full name of the product. This has already been re-introduced in later versions

https://github.com/odoo/odoo/blob/8e00b5337a2ee30e667b0b2e6ff26b7df9fef2e3/addons/point_of_sale/static/src/app/store/models.js#L315-L320

This is in sass-17.2

opw-3950366

Forward-Port-Of: odoo/odoo#168121

### Issue: When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal. The same thing happens with Vendor Bills when the firm setting is activated. ### Steps to reproduce: - In Set

### Issue:
When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal.

The same thing happens with Vendor Bills when the firm setting is activated.

### Steps to reproduce:
- In Settings > Accounting > 'Accounting Firms Mode' select "Customer Invoices and Vendor Bills"
- In Accounting > Customers > Invoices create a new Invoice
- Choose a name, for example 'INV234' and a journal
- Save the record
- Change the journal
- When saving a popup indicates it is impossible to change the journal when a sequence number is assigned

### Cause:
When not in firm mode the invoice can't be filled (displays as Draft) and will be generated from the previous invoice name (In fact the user can only modify the name of the first invoice created in the journal, not the next ones). With the firm mode activated, the user can always modify the name of the draft invoice, giving it a sequence number. Then when changing the journal, it is blocked because the user is not supposed to change the journal of an invoice with a sequence number greater than 1. The check: https://github.com/odoo/odoo/blame/16.0/addons/account/models/account_move.py#L2303

### Solution:
Modify the condition of the UserError so that it is not triggered when the 'Firm Mode' is active.

opw-3925402

Forward-Port-Of: odoo/odoo#168319

Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode. This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode. task-3754159 Part of task-3575827 | Before | After | |--------|--------| |  | ![Capture d’éc

Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode.

This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode.

task-3754159
Part of task-3575827

| Before | After |
|--------|--------|
| ![image](https://github.com/odoo/odoo/assets/80679690/62476368-c3cd-4652-a8a4-19afc09631a1) | ![Capture d’écran 2024-02-21 à 11 40 56](https://github.com/odoo/odoo/assets/80679690/62b8cd53-4f4e-4f41-9b93-803b83e49d7d) |
| ![image](https://github.com/odoo/odoo/assets/80679690/274fb188-5779-4259-9681-ae7eb402b842) | ![Capture d’écran 2024-02-21 à 11 41 46](https://github.com/odoo/odoo/assets/80679690/35148fb7-1eea-49f1-b5b0-7aff46593a99) |
| ![Capture d’écran 2024-02-21 à 11 42 51](https://github.com/odoo/odoo/assets/80679690/536f6b4e-bff2-4ecb-963d-72c9acc78a59) |  ![Capture d’écran 2024-02-21 à 11 43 24](https://github.com/odoo/odoo/assets/80679690/3d2c3b20-b49b-4cb0-98e6-4c655778bd3d) |
| ![Capture d’écran 2024-02-22 à 08 39 12](https://github.com/odoo/odoo/assets/80679690/f91f0375-4768-4929-a89a-60152ead96a6) | ![Capture d’écran 2024-02-22 à 08 38 17](https://github.com/odoo/odoo/assets/80679690/daf670c1-86b6-4e2a-bfb6-dfceb4de6de5) |


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

Forward-Port-Of: odoo/odoo#154856

Fix for 17.0 only Problem: In restaurant, when we make a bill, the order is made to the kitchen Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules - Open a restaurant session - Select products for a table - Click on "Bill" - The order is now in the kitchen while it should not Cause: The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill Solut

Fix for 17.0 only

Problem:
In restaurant, when we make a bill, the order is made to the kitchen

Steps to reproduce:
- Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules
- Open a restaurant session
- Select products for a table
- Click on "Bill"
- The order is now in the kitchen while it should not

Cause:
The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill

Solution:
Remove the "sendOrderInPreparationUpdateLastChange" for the bill screen when pos_preparation_display is installed

opw-3938924


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

Forward-Port-Of: odoo/odoo#166844

Issue: ------ The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account. For example: - monday morning: duration = 0.4 - monday afternoon: duration = 0.4 allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81 Note: It's strange to round up to the sixteenth of an 8-hou

Issue:
------
The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account.

For example:
- monday morning: duration = 0.4
- monday afternoon: duration = 0.4

allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81

Note:
It's strange to round up to the sixteenth of an 8-hour day. It makes sense to have half-hour intervals, but it is does not work correctly with calendars that differ from the standard 8-hour calendar.

opw-3957459

Forward-Port-Of: odoo/odoo#168517

-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step, the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done -Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/b

-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step,
the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done

-Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/res_company.py#L336-L338

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

Before, we could not send any simplified invoice for Bizkaia, because it would give error B4_2000026: "Las Claves indicadas no son compatibles". En las validaciones dice que "Las claves 51 y 52 sólo son compatibles entre sí" But normally we send 01 and 52 in case of a simplified invoice. By removing the 52 however, we see that we can send the simplified invoice. Also, elsewhere in the XML, it is already clearly indicated that the invoice is simplified anyways. So, the simple fix for n

Before, we could not send any simplified invoice for Bizkaia, because it would give error  B4_2000026: "Las Claves indicadas no son compatibles". En las validaciones dice que "Las claves 51 y 52 sólo son compatibles entre sí"

But normally we send 01 and 52 in case of a simplified invoice.

By removing the 52 however, we see that we can send the simplified invoice.  Also, elsewhere in the XML, it is already clearly indicated that the invoice is simplified anyways.

So, the simple fix for now is to remove the 52 key if the agency is Bizkaia

opw-3938800

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

Due to Stripe sending multiple confirmations regarding authorized payment, multiple mails were send to customer that their payment was succesful, now only transactions that were not processed yet result in mail sending. opw-3967807 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#168298

Due to Stripe sending multiple confirmations regarding authorized payment, multiple mails were send to customer that their payment was succesful, now only transactions that were not processed yet result in mail sending.

opw-3967807

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

This error occurs when a user with ``Billing/Bookkeeper`` rights attempts to delete a payment associated with invoices from different companies. Steps to reproduce: - Install the ``account_accountant`` module - Create a new company (eg: Company A) and switch to it - Open Accounting > Configuration > Settings > Fiscal Localization > Generic Chart Template > Save - Enable all companies > Settings > General Settings > Companies > Inter-Company Transactions > Save > Again search for In

This error occurs when a user with ``Billing/Bookkeeper`` rights attempts to delete a payment associated with invoices from different companies.

Steps to reproduce:
- Install the ``account_accountant`` module
- Create a new company (eg: Company A) and switch to it
- Open Accounting > Configuration > Settings > Fiscal Localization > 
  Generic Chart Template > Save
- Enable all companies > Settings > General Settings > Companies > Inter-Company
  Transactions > Save > Again search for Inter-Company Transactions >
  Synchronize invoices/bills > Create as: ``Mitchell Admin`` > Save
- Accounting > Customers > Invoices > Select the one invoice with ``YourCompany`` 
  as a company and ``Register Payment`` > Journal Entry > Reconciled Items > 
  Select all and unreconciled them and the same for another invoice with 
  ``Company A`` as a company
- Go to ``Marc Demo`` in Users > Allowed Companies > add ``Company A`` > Save
- Logout and login with ``Marc Demo``
- Accounting > Customers > Payments > Select both and delete it

``Traceback : ValueError : Expected singleton: res.company(2, 4)``

When we try to delete a payment involving different companies, at line [1] in ``self.company_id``, we are getting the IDs of two companies, which causes an error.

This commit will fix the above error by adding a for loop that checks each record individually.

[1]: https://github.com/odoo/odoo/blob/4fb50c6079dd59f3f82d335dbdf6c65f001c5855/addons/account/models/account_move.py#L2811

sentry-5408865989

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

Forward-Port-Of: odoo/odoo#167195

Steps to reproduce: - insert a pivot in a spreadsheet - create a From/To global filter - leave the filter values empty - click on the Share button => boom because of `cell.value.toString()` `cannot read toString of undefined` opw-3971278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168147

Steps to reproduce:
- insert a pivot in a spreadsheet
- create a From/To global filter
- leave the filter values empty
- click on the Share button

=> boom because of `cell.value.toString()`
`cannot read toString of undefined`

opw-3971278

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

Forward-Port-Of: odoo/odoo#168147

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022`

Before the present commit, the tests were surprisingly expecting the wrong result.

An attempt was made [1] to fix the upstream issue but was never merged.

In the meanwhile, Debian reverted the Babel issue 621 [2] in their package.

It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib.

So, this commit mitigate the issue by guessing the expected value even if the result is wrong.

[0]: https://github.com/python-babel/babel/pull/621
[1]: https://github.com/python-babel/babel/pull/887
[2]: https://sources.debian.org/patches/python-babel/2.10.3-1/



For reference (from @Xavier-Do )

Pip version and Jammy
```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2022'
```

It looks like the week year used is actually not localized, adding a cornercase on Sunday

Noble version

```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2023'
```

Forward-Port-Of: odoo/odoo#168132

Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations. The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed. Impacted branches: `17.0` and `master` Steps to reproduce: 1. Go to the

Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations.

The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed.

Impacted branches:

`17.0` and `master`

Steps to reproduce:

 1. Go to the Technical menu -> Fields and select a monetary type field
 2. Try to update the Field Label or any field translation

Current behavior:

The editing is blocked by the required 'Currency field'.

Expected behavior:

Allow editing the form view or the related translations.

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

**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field of the respective purchase order line. **Expected behavior:** These values will be synchronized. **Steps to reproduce:** 1. Make a purchase order with a following combination: A) `picking_type = receipt` `product cost_method != standard` B) `picking_type = dropship`

**Current behavior:**
Depending on the created picking type and product costing
method, unlocking a validated picking and changing the quantity
field of a move will not update the qty_received field of the
respective purchase order line.

**Expected behavior:**
These values will be synchronized.

**Steps to reproduce:**
1. Make a purchase order with a following combination:
    A) `picking_type = receipt`
       `product cost_method != standard`

    B) `picking_type = dropship`
       (product cost_method is arbitrary)

2. Confirm the order, validate the picking

3. Unlock the picking and change the quantity value of the stock
     move

4. Observe that the purchase order's qty_received value does not
     change

**Cause of the issue:**
In the case of the receipt picking type, when creating a stock
valuation layer for the related move with a 'standard' product
costing method we do not call `_get_price_unit()`. This method
will compute the qty_received value of a purchase order line.
After we unlock the picking and change the move quantity, this
field will not be recomputed (because it is stored). Thus, it is
not updated.

The dropship case is similar, except in the creation of a
dropship SVL, `_get_price_unit()` is called before checking the
product's cost method- so the bug always occurs.

**Fix:**
Make the purchase order line's qty_received field depend on it's
stock moves' quantities.

Reorder the conditional in the dropship SVL creation so it
matches that of the incoming SVL creation- this is for
improving consistency rather than a necessary modification for
the fix.

opw-3863510

Forward-Port-Of: odoo/odoo#166366

Revisions are technical records that are never supposed to be changed (except the `active` field). If any of `res_model`, `res_id`, `revision_uuid` is changed, the spreadsheet history will be broken. Changing field `commands` could also break the spreadsheet if the json is malformed or the command is made invalid. In this commit, we prevent the admin to make any changes. Forward-Port-Of: odoo/enterprise#64328

Revisions are technical records that are never supposed to be changed (except the `active` field). If any of `res_model`, `res_id`, `revision_uuid` is changed, the spreadsheet history will be broken.

Changing field `commands` could also break the spreadsheet if the json is malformed or the command is made invalid.

In this commit, we prevent the admin to make any changes.

Forward-Port-Of: odoo/enterprise#64328

ComercioExterior20 has wrong path for its xsd runbot-55568 Forward-Port-Of: odoo/enterprise#63429

ComercioExterior20 has wrong path for its xsd

runbot-55568

Forward-Port-Of: odoo/enterprise#63429

Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file. Task-3468245 Forward-Port-Of: odoo/enterprise#55641

Document fields in the salary configurator now check for existing files on the current contract. Fields are set to required only if no associated file is detected on the contract, otherwise we just show the already existed file.

Task-3468245

Forward-Port-Of: odoo/enterprise#55641

This reverts commit f7f0317a1d6d129a847e09c3ccd0df19ae99d3e5. Cause: https://github.com/odoo/enterprise/pull/63268#issuecomment-2160019128 Linked with https://github.com/odoo/odoo/pull/168815 Forward-Port-Of: odoo/enterprise#64317

This reverts commit f7f0317a1d6d129a847e09c3ccd0df19ae99d3e5.

Cause: https://github.com/odoo/enterprise/pull/63268#issuecomment-2160019128

Linked with https://github.com/odoo/odoo/pull/168815

Forward-Port-Of: odoo/enterprise#64317

Problem: In restaurant, when we make a bill, the order is made to the kitchen Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules - Open a restaurant session - Select products for a table - Click on "Bill" - The order is now in the kitchen while it should not Cause: The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill Solution: Remove the "sen

Problem:
In restaurant, when we make a bill, the order is made to the kitchen

Steps to reproduce:
- Install "Point of Sale" app and "pos_restaurant" and "pos_preparation_display" modules
- Open a restaurant session
- Select products for a table
- Click on "Bill"
- The order is now in the kitchen while it should not

Cause:
The full process for making an order is called with "sendOrderInPreparationUpdateLastChange" while it is not necessary to make a bill

Solution:
Remove the "sendOrderInPreparationUpdateLastChange" for the bill screen when pos_preparation_display is installed

Note:
Linked with this PR: https://github.com/odoo/odoo/pull/166844

opw-3938924

Forward-Port-Of: odoo/enterprise#63268

In the reports, the groups called '(No Group)' fold and unfold together. ### Steps to reproduce: - in Accounting app go in Configuration > Account Groups and create an account group for the current company - Go in Reporting > Profit and Loss - All '(No Group)' lines fold and unfold together ### Cause: Line ids are duplicate for (No Group) lines: '\~account.group\~'. The hierarchy is ignored for these ids, there is no reference to the parent line. ### Solution: Integrate the parent

In the reports, the groups called '(No Group)' fold and unfold together.

### Steps to reproduce:
- in Accounting app go in Configuration > Account Groups and create an account group for the current company
- Go in Reporting > Profit and Loss
- All '(No Group)' lines fold and unfold together

### Cause:
Line ids are duplicate for (No Group) lines: '\~account.group\~'. The hierarchy is ignored for these ids, there is no reference to the parent line.

### Solution:
Integrate the parent line in the ids to take the hierarchy into consideration.

### opw-3885400

Forward-Port-Of: odoo/enterprise#63804
Forward-Port-Of: odoo/enterprise#62647

User using the filters in the bank reco widget want to be able to save them for next time. In the implementation of the search view of the kanban, we only added the filter. This commit will add the favorite section. task-3871505 Forward-Port-Of: odoo/enterprise#60860

User using the filters in the bank reco widget want to be able to save them for next time. In the implementation of the search view of the kanban, we only added the filter. This commit will add the favorite section.

task-3871505

Forward-Port-Of: odoo/enterprise#60860

Purpose ------- Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell) If the user does multiple such very large revision, one after the other, every thing is fine client side. The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions ca

Purpose
-------

Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell)

If the user does multiple such very large revision, one after the other, every thing is fine client side.

The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions can be so large it can blow up the server memory limit.
The spreadsheet cannot be open anymore.

Solution
--------

In this commit, we increase the number of snapshot by snapshotting more often.

Previously, we used to snapshot when opening a spreadsheet and no activity was done in the spreadsheet in the last 12 hours. It's reduced to 2 hours in this commit.
The reason we don't want to snapshot too often is that it kills the local history (CTRL+Z) of connected users.

Task: 3940465

Forward-Port-Of: odoo/enterprise#63741

Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment. opw-3904458 Forward-Port-Of: odoo/enterprise#62976

Currently, a traceback with `KeyError: 'emisor'` occurs when attempting to update payments after creating and signing a PPD and external trade invoice, and registering a payment.

opw-3904458

Forward-Port-Of: odoo/enterprise#62976

When a user in US/Pacific generates a file after 17:00 the File Creation Date field incorrectly has tomorrow's date. To fix it use the localized timestamp for the File Creation Date as well. opw-3942095 Forward-Port-Of: odoo/enterprise#64188 Forward-Port-Of: odoo/enterprise#64172

When a user in US/Pacific generates a file after 17:00 the File Creation Date field incorrectly has tomorrow's date. To fix it use the localized timestamp for the File Creation Date as well.

opw-3942095

Forward-Port-Of: odoo/enterprise#64188
Forward-Port-Of: odoo/enterprise#64172