[FIX] web: use back button don't break filters in search view Open a kanban view or a list view; Enter a filter in the search view; Open a record; Go back to the multi-record view using the browser (back button). Before this commit, the previously entered filter is not there anymore. Now, the filter stays. To achieve this, before leaving the multi-record view, the global state is saved on the history state. To be able to push a key (the global state) on the state to be saved on the

[FIX] web: use back button don't break filters in search view

Open a kanban view or a list view;
Enter a filter in the search view;
Open a record;
Go back to the multi-record view using the browser (back button).

Before this commit, the previously entered filter is not there anymore.
Now, the filter stays. To achieve this, before leaving the multi-record view, the global state is saved on the history state.

To be able to push a key (the global state) on the state to be saved on the history and not shown in the browser, a new way to add a key/value to the state,
but omit it on the URL was developed. Also, a way to push the state synchronous was added.

Forward-Port-Of: odoo/odoo#170074

The COGS registered was wrong when invoicing a product that is a kit with UOM A and component uses UOM B. Steps to reproduce: ------------------- * Create Comp A with UOM Dozens. It's cost should be 12000 * Create Product A with UOM Units. * Make sure both use the same category, and the category should use automcatic inventory valuation. * Create a kit bom for product A that contains 1 comp A. * Sell this kit in the PoS and invoice it. * Close the PoS and go to the order then on th

The COGS registered was wrong when invoicing a product that is a kit
with UOM A and component uses UOM B.

Steps to reproduce:
-------------------
* Create Comp A with UOM Dozens. It's cost should be 12000
* Create Product A with UOM Units.
* Make sure both use the same category, and the category should use
  automcatic inventory valuation.
* Create a kit bom for product A that contains 1 comp A.
* Sell this kit in the PoS and invoice it.
* Close the PoS and go to the order then on the invoice.
* Check the journal items

> Observation: the COGS is 12000 it's wrong. It should be
  1000

Why the fix:
------------
The `_get_pos_anglo_saxon_price_unit` is not taking the product uom into
account. So in this example the price unit will be for a dozen, but the
bom specifies that we are using a unit and not a dozen. So the quantity
needs to be modified from a dozen to unit. That's what the 
`_compute_price` method is doing.


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

Forward-Port-Of: odoo/odoo#170267
Forward-Port-Of: odoo/odoo#166382

Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef5

Current behaviour:
---
Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil.
(Adding a 9 to mobile phone numbers)

Cause of the issue:
---
Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, 
phone numbers aren't formatted, thus patched metadata not being applied.
See format_number in phonenumbers "Early exit for E164 case"

Fix:
---
Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef55886c280240b76a 
In phone_validation, before formatting, phone_parse is called, https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L72 
old brazilian mobile numbers would be invalid, and raise an error. https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L51 
Now if the number is invalid, we force format in international, to force apply patched metadata, before re-trying to parse.

opw-3861847

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

Forward-Port-Of: odoo/odoo#170287
Forward-Port-Of: odoo/odoo#169134

It may happen that user will try to blacklist a number that he already unblacklisted (archived blacklist record). Before that attempt was ignored. With this commit we simply blacklist the number again (so we unarchive existing record) ### [Reproduce] - Install mass_mailing_sms - Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses) - Blacklist a number N - Unblacklist number N - Go back to Blacklisted Phone Numbers - Blacklist a number N (a

It may happen that user will try to blacklist a number that he already
unblacklisted (archived blacklist record). Before that attempt was ignored. With
this commit we simply blacklist the number again (so we unarchive existing record)

### [Reproduce]
- Install mass_mailing_sms
- Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses)
- Blacklist a number N
- Unblacklist number N
- Go back to Blacklisted Phone Numbers
- Blacklist a number N (again) -> BUG: no effect

opw-3700268

Forward-Port-Of: odoo/odoo#170297
Forward-Port-Of: odoo/odoo#158923

This commit adds structured data in the form of a JSON-LD object to facilitate rich search engine results. Now, each question with a valid answer or suggested answers in the forum will be eligible for enhanced display in search engine results. task-3858663 Courtesy of @Sumeeshsree for his insight regarding this task. Forward-Port-Of: odoo/odoo#164369

This commit adds structured data in the form of a JSON-LD object to facilitate rich search engine results. Now, each question with a valid answer or suggested answers in the forum will be eligible for enhanced display in search engine results.

task-3858663

Courtesy of @Sumeeshsree for his insight regarding this task.

Forward-Port-Of: odoo/odoo#164369

-Before this commit, when user has no expense at all and in mobile view of expense, it will display term "Or" alongside with "Snap pictures of your receipts..." -After this commit, remove term "Or". Description of the issue/feature this PR addresses: Current behavior before PR:  Desired behavior after PR is merged: ![image](https://github.com/odoo/odoo/assets/56789189/d549a497-e39f-4c55-bd3a-

-Before this commit, when user has no expense at all and in mobile view of expense, it will display term "Or" alongside with "Snap pictures of your receipts..."
-After this commit, remove term "Or".

Description of the issue/feature this PR addresses:

Current behavior before PR:
![image](https://github.com/odoo/odoo/assets/56789189/fba82ba0-f2ab-4b87-8a65-618eca3b5e3a)


Desired behavior after PR is merged:
![image](https://github.com/odoo/odoo/assets/56789189/d549a497-e39f-4c55-bd3a-be8e8a8e4640)




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

Forward-Port-Of: odoo/odoo#170460

Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching. This commit fixes that by parsing the dataAttribute to float. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f2380

Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching.

This commit fixes that by parsing the dataAttribute to float.

[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f23809818a0b78c118d84606a1ab5d7bf1203

task-4001189

Forward-Port-Of: odoo/odoo#170092

**Current behavior:** Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category: Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move

**Current behavior:**
Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category:

Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move process.

**Expected behavior:**
The second move will not get assigned via putaway rule to the second location, as its quantity is too large.

**Steps to reproduce:**
1. Create a storage category with a capacity: `product: productA` `quantity: 5`

2. Create an internal location: `parent location: WH/STOCK` `storage category: from step 1`

3. Create a putaway rule: `product: productA` `src location: WH/STOCK` `dest location: from step 2` `storage category: from step1`

4. Create a receipt picking with a move for productA that will not exceed the storage categ. cap -> confirm the picking

5. Create another receipt picking with a move for productA that exceeds the storage categ. cap -> confirm -> fill out the quantity -> validate

6. Go to the storage location and view its quants, see it's more than the max capacity

**Cause of the issue:**
During the picking assignment, the current/pending quantity of the proposed location gets calculated. Prior to the 7dda6bb refactor on the `qty_done` field, this current/pending quantity was stored in the method in a local variable, coincidentally also called qty_done. It got changed to quantity in this commit, which is also the name of one of the method arguments that represents the quantity value of the current move line which is being validated.

Thus, the incoming quantity becomes the current quantity in the location which, of course, does not validate the defined cap.

**Fix:**
Rename the local variable.

opw-3926597

Forward-Port-Of: odoo/odoo#170422
Forward-Port-Of: odoo/odoo#169746

When posting a big invoice (>800 lines) for products that are valuated in real_time, the `_post` override in `purchase_stock` can become a bottleneck for anglo-saxon companies. This method calls `_stock_account_anglo_saxon_reconcile_valuation` which performs reconciliations for all the invoice_lines. Thanks to odoo/odoo#113680 it's now possible to batch the reconciliation process via the backend method `_reconcile_plan`. This gives various speedups by batching create, reducing the number of

When posting a big invoice (>800 lines) for products that are valuated in real_time, the `_post` override in
`purchase_stock` can become a bottleneck for anglo-saxon companies. This method calls `_stock_account_anglo_saxon_reconcile_valuation` which performs reconciliations for all the invoice_lines.

Thanks to odoo/odoo#113680 it's now possible to batch the reconciliation process via the backend method `_reconcile_plan`. This gives various speedups by batching create, reducing the number of flush, etc.

Moving the reconciliation process outside of the loops in `_stock_account_anglo_saxon_reconcile_valuation` and calling `_reconcile_plan` only at the end of the method gives a significant speedup for big invoices.

#### speedup

Customer database with mix of real_time and manual inventory valuation and anglo-saxon accounting.
purchase_stock is installed.
15 000 products, 80 000 stock.moves, 66 000 stock.move.lines,
100 000 account.moves, 289 000 account.move.line.

Time to post an invoice changing the number of lines.

| # Lines |     Before PR            | After PR |
|:-------:|:------------------------:|:--------:|
|    10   |       1.66s              |   1.11s  |
|    50   |       8.53s              |   2.95s  |
|    200  |       1min30s            |   11.51s |
|    889  |       +20min (killed)    |   58.84s |

opw-3901468

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

Forward-Port-Of: odoo/odoo#169825
Forward-Port-Of: odoo/odoo#166482

This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing. 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#169290 Forward-Port-Of: odoo/odoo#167955

This is a missing test for odoo/odoo#165753. It also checks the first condition from the `_get_default_dest_location` method, since the test for it was also missing.

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#169290
Forward-Port-Of: odoo/odoo#167955

Previously, the floating icon wasn't an OWL component and has been refactored into an OWL component. When refactored he lost the auto move up top logic that came with the css classes 'o_bottom_fixed_element' and 'o_bottom_fixed_element_move_up' This commit reintroduce this auto move up behavior by default within the OWL component by listening to the scroll event of the document and identifying whenever we reach the end of the document. It is useful so we ensure the users can click all l

Previously, the floating icon wasn't an OWL component and has been
refactored into an OWL component. When refactored he lost the auto
move up top logic that came with the css classes 'o_bottom_fixed_element'
and 'o_bottom_fixed_element_move_up'

This commit reintroduce this auto move up behavior by default within the
OWL component by listening to the scroll event of the document and
identifying whenever we reach the end of the document. It is useful
so we ensure the users can click all links potentially present in the
footer. If the icon is dragged and moved elsewhere, we prevent this
smart behavior from happening until next refresh of the state.

Commit introducing the drag & drop feature :
https://github.com/odoo/odoo/commit/d9f07235484

Commit of the OWL refactoring :
https://github.com/odoo/odoo/commit/20c1772d

Steps to reproduce :

- Install LiveChat
- Toggle Mobile display
- Scroll down to the bottom of page
-> The livechat floating icon doesn't go up as it was before

task-3946855

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

Forward-Port-Of: odoo/odoo#169831
Forward-Port-Of: odoo/odoo#169383

Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback. By updating the country of the company by the one of the chart template, the issues will not happen again. task: 3945833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166896

Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback.
By updating the country of the company by the one of the chart template, the issues will not happen again.

task: 3945833




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

Forward-Port-Of: odoo/odoo#166896

Current behavior: In the journal items of a PoS session, Debit and Credit mismatch for the bank Steps to reproduce: - Install "Point of Sale", "Accounting" apps - Create a company and set the currency to something different than USD (eg. EUR) - Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template" - Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD) - Go to Accounting -> C

Current behavior:
In the journal items of a PoS session, Debit and Credit mismatch for the bank

Steps to reproduce:
- Install "Point of Sale", "Accounting" apps
- Create a company and set the currency to something different than USD (eg. EUR)
- Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template"
- Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD)
- Go to Accounting -> Currencies -> USD -> Add a rate line and set a rate different to 1 Unit per EUR (eg. 1.2)
- In Accounting, go to Journals -> Bank -> set the currency to USD -> do the same for Cash
- Add a Journal named "PoS" -> set its type to "Miscellaneous" -> set the short code to "POS" -> set the currency to USD
- Go to POS -> Payment Methods -> Create "Cash" -> set the journal "Cash (USD)" and the account "<some number> Account Receivable (PoS)"
- Create a "Bank" payment method -> set the journal "Bank (USD)" -> Set the Outstanding Account "<some number> Outstanding Receipts" -> set the Intermediary Account "<some number> Account Receivable (PoS)"
- Create a shop
- In the shop settings, set the default journal to "POS(USD)" then add "Cash" and "Bank to "Payment methods"
- Start a shop session and sell a product paid by bank
- Close the session ->  set the bank count to the price of 2 products
- Go to "Order" -> "Sessions" -> last session -> "Journal Items"
- The "PBNK" line doesn't have Debit and Credit equal

Cause:
The diff_amount used for the line calculation is in USD and not in the company currency

opw-3905691


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

Forward-Port-Of: odoo/odoo#168731

Steps: - Install the project - Enable use custom enable server from general settings. Set an alias domain - Create a new project - Wizard pops up Issue: - Default value of alias domain is not set. Cause: - alias_domain_id is related to alias_id and it is not present in the view. Fix: - Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field. - Additionally the same field is been to added to form view as well. task-3744319 Forwar

Steps:
- Install the project
- Enable use custom enable server from general settings. Set an alias domain
- Create a new project
- Wizard pops up

Issue:
- Default value of alias domain is not set.

Cause:
- alias_domain_id is related to alias_id and it is not present in the view.

Fix:
- Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field.
- Additionally the same field is been to added to form view as well.

task-3744319

Forward-Port-Of: odoo/odoo#154681

The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field. It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests. The missing dependency is added in this commit. enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262 Forward-Port-Of: odoo/odoo#170475

The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field.

It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests.

The missing dependency is added in this commit.

enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262

Forward-Port-Of: odoo/odoo#170475

**Reproduce issue:** - Drop and drop a form snippet - Set a field as a multiple checkbox - Toggle on option 1 - Set a space at the end of option 1 so "option 1 " - Blur the input **Result:** You will find, Option 1 is no more selected. The root cause of this issue appears to be the unexpected trimming of the HTML input box. By default, HTML trims leading and trailing spaces, as well as considers multiple inner spaces as a single space. Consequently, inconsistencies arise between

**Reproduce issue:**

- Drop and drop a form snippet
- Set a field as a multiple checkbox
- Toggle on option 1
- Set a space at the end of option 1 so "option 1 "
- Blur the input

**Result:** You will find, Option 1 is no more selected.

The root cause of this issue appears to be the unexpected trimming of the HTML
input box. By default, HTML trims leading and trailing spaces, as well as
considers multiple inner spaces as a single space. Consequently, inconsistencies
arise between the input value, ID, and display name. This commit trims the value
from the initial to maintain consistency.

As a result, `option 1`, `option 1   `, `  option 1`, and `option     1` will
all be trimmed and considered the same.

task-3254884

Forward-Port-Of: odoo/odoo#170365
Forward-Port-Of: odoo/odoo#128692

### Current Behavior: - Go in the project app, click on a project and click on a task - Change the stage of the task The duration spent in the previous stage is displayed in the new stage. Note: if you refresh the page the bug will disappear. ### Cause of the issue: The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https

### Current Behavior:

- Go in the project app, click on a project and click on a task
- Change the stage of the task

The duration spent in the previous stage is displayed in the new stage.

Note: if you refresh the page the bug will disappear.

### Cause of the issue:

The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L45-L60 To be sure that these trackings will be correctly retrieved, the model used by the query are even flushed. However, these mail tracking values are only created at the end of the sql transaction because the `_track_finalize` method is part of the precommit hooks of the transaction and is hence only run during the general sql flush: https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/sql_db.py#L134-L138 https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/tools/misc.py#L1215-L1221 As such, the mail tracking values generated by the old value of the stage will only be accessible at the end of the transaction and will not be available during the computation duration_tracking run for the project task in its final stage. Leading to an incorrect computation of the field during onchanges:
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L62-L64

### Fix:

In order for the the mail tracking values generated by the old stage to be present during the final computation of our duration_tracking we trigger the `_track_finalize` precommit hook on the records for which it should be run at the end of the transaction before the execution of our query.

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

Forward-Port-Of: odoo/odoo#161688

Steps to reproduce: ------------------- - Install `website_event` module - Create an event with name `Test Event` and enable `Website Submenu` option - Click on `Go to Website` stat button - Edit the `Introduction` page by adding a new block under the event name for example - Save it and go back to backend - Create a new event with same name `Test Event` and enable `Website Submenu` option - Click on `Go to Website` stat button Issue: ------ The second event will have the edited

Steps to reproduce:
-------------------

- Install `website_event` module
- Create an event with name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button
- Edit the `Introduction` page by adding a new block under the event name for example
- Save it and go back to backend
- Create a new event with same name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button

Issue:
------

The second event will have the edited
`Introduction` page from the first event.

Cause:
------

When creating the menu, since we do not create a
page, the URL retrieved in the process will be
always the same and therefore redirect to the
edited page of the first event (since the last
part of the URL is used to retrieve the right
view).

Solution:
---------

Ensure the URL is unique by using the view key
(who is unique) as last part of the URL.

opw-3945840

Forward-Port-Of: odoo/odoo#170149
Forward-Port-Of: odoo/odoo#169770

Summary ----- When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved. Steps to Reproduce ----- 1. Set a strong currency for the company (e.g., USD) 2. Add a weak currency in the currencies (e.g., IQD) 3. Create

Summary
-----
When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved.

Steps to Reproduce
-----
    1. Set a strong currency for the company (e.g., USD)
    2. Add a weak currency in the currencies (e.g., IQD)
    3. Create an expense with a high amount (e.g., 1,000,000 for the IQD/USD pair)
    4. Set the weak currency for the expense
    5. Observe the overly rounded amount in the weak currency

Cause
-----
The error comes from the exchange rate being rounded too much and too early.

Fix
-----
Modify "digits" attribute of the "currency_rate" field to increase precision.

Note
-----
Some inaccuracy remains, but expenses rarely exceed 1000 USD for companies using weak currencies, so the number of issues should be reduced.

opw-3684727

Forward-Port-Of: odoo/odoo#167606

**Description of the issue/feature this PR addresses:** This PR addresses the orientation of chart labels in survey live session. Previously, chart labels in the survey live session struggled to display longer labels effectively. Labels are now tilted by min 20 degrees for better visibility and display of longer labels in survey live sessions chart. **Task**-3884116 Forward-Port-Of: odoo/odoo#170305 Forward-Port-Of: odoo/odoo#163288

**Description of the issue/feature this PR addresses:**
This PR addresses the orientation of chart labels in survey live session.

Previously, chart labels in the survey live session struggled to display longer labels effectively.
Labels are now tilted by min 20 degrees for better visibility and display of longer labels in survey live sessions chart.

**Task**-3884116

Forward-Port-Of: odoo/odoo#170305
Forward-Port-Of: odoo/odoo#163288

**Steps to reproduce:** - Install Invoicing - Go to "Invoicing / Configuration / Settings" - Deactivate "Document Digitalization" - Create an invoice - Upload a PDF via paperclip button or drag and drop in the chatter **Issue:** The preview box appears but it is empty. **Cause:** In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post

**Steps to reproduce:**
- Install Invoicing
- Go to "Invoicing / Configuration / Settings"
- Deactivate "Document Digitalization"
- Create an invoice
- Upload a PDF via paperclip button or drag and drop in the chatter

**Issue:**
The preview box appears but it is empty.

**Cause:**
In "onUploaded" function of Chatter component, the parent view is not reloaded once the attachment is uploaded because "hasParentReloadOnAttachmentsChanged" property is False. This property depends on "post_refresh" option.

**Solution:**
Add "post_refresh" option for "message_ids" field in the view as it is done when "account_invoice_extract" module is installed.

opw-3887671



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

Forward-Port-Of: odoo/odoo#170351
Forward-Port-Of: odoo/odoo#169612

Steps: ========== - Install the point_of_sale and Razorpay payment provider modules. - Create an online payment method for the Razorpay payment provider. - Add the created payment method to the shop. - Open the shop, place an order, and use the Razorpay payment method. - Scan the QR code for payment and complete the payment with public users. Issue: ========== - An error occurs stating 'Email must be a valid email address,' causing the task to be blocked. Cause: ========== - The

Steps:
==========
- Install the point_of_sale and Razorpay payment provider modules.
- Create an online payment method for the Razorpay payment provider.
- Add the created payment method to the shop.
- Open the shop, place an order, and use the Razorpay payment method.
- Scan the QR code for payment and complete the payment with public users.

Issue:
==========
- An error occurs stating 'Email must be a valid email address,' causing the task to be blocked.

Cause:
==========
- The email for public users is not found.

FIX:
==========
- Add an empty email address option for public users.

task-3992084

Forward-Port-Of: odoo/odoo#169974

This PR aims to fix an issue with the Facebook snippet not being dynamically responsive for mobile views. Steps to reproduce 1. Drop inner content facebook (dynamic content) anywhere 2. Go to mobile view 3. Try to scroll horizontally. As you can see, facebook iframe is overflowing Before v16, the mechanism for mobile view was different. The switch between mobile and desktop views caused snippets/pages to be re-render because a new dialog for mobile was opened every time. Starting fro

This PR aims to fix an issue with the Facebook snippet not being dynamically responsive for mobile views.

Steps to reproduce
1. Drop inner content facebook (dynamic content) anywhere
2. Go to mobile view
3. Try to scroll horizontally.

As you can see, facebook iframe is overflowing

Before v16, the mechanism for mobile view was different. The switch between mobile and desktop views caused snippets/pages to be re-render because a new dialog for mobile was opened every time. Starting from version 16, we have removed the dialog and introduced a mobile frame. As a result, the rendering now occurs only when the start function is called. Consequently, the params width does not change when we switch to mobile view.

![2024-04-29_14-34](https://github.com/odoo/odoo/assets/157009134/75a5fb69-8a46-4908-8814-0673084ed1d0)

After this PR, the snippet will be re-render every time the window resizes, ensuring that the width adjustment is responsive. This enhancement also allows parameters to be provided at the time of rendering.

![2024-04-29_14-35](https://github.com/odoo/odoo/assets/157009134/30a5c2f9-1e47-4902-a7c1-89506a541a26)

Task-2736174

Forward-Port-Of: odoo/odoo#170292
Forward-Port-Of: odoo/odoo#163739

Currently we send the currency code as an integer and this must be sent as a string 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#170482 Forward-Port-Of: odoo/odoo#169253

Currently we send the currency code as an integer and this must be sent as a string

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#170482
Forward-Port-Of: odoo/odoo#169253

This traceback occurs when the user tries to activate stripe through onboarding without installing `website_payment`. To reproduce this issue:- 1) Install `sale` 2) Now switch to a new company by creating a `new company` 4) With the new company try to `activate the stripe` from the `sales Onboarding` 5) A traceback occurs Error:- ``` ValueError: Invalid field 'website_id' on model 'payment.provider' ``` As you can see `website_id` field is defined in `website_payment` at [1]

This traceback occurs when the user tries to activate stripe through onboarding without installing `website_payment`.

To reproduce this issue:-

1) Install `sale`
2) Now switch to a new company by creating a `new company` 
4) With the new company try to `activate the stripe` from the `sales Onboarding` 
5) A traceback occurs

Error:- 
```
ValueError: Invalid field 'website_id' on model 'payment.provider'
```

As you can see `website_id` field is defined in `website_payment` at [1], 
but it is used in the `payment` module [2]. Which leads to the above traceback
when `website_payment` is not installed.

[1]
https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/website_payment/models/payment_provider.py#L12-L16

[2]
https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/payment/models/res_company.py#L48-L53

sentry-5504774122

Forward-Port-Of: odoo/odoo#170550
Forward-Port-Of: odoo/odoo#169953

This commit introduces the possibility to add a key/value to the state, but omit it on the URL, a new function `addKeystoOmit` was added to this effect. Note that, this key will also be added in the state that is sent to the browser history. Allowing to retrieve the complete state (including the omitted keys) when clicking the back button on the browser. Forward-Port-Of: odoo/enterprise#65052

This commit introduces the possibility to add a key/value to the state,
but omit it on the URL, a new function `addKeystoOmit` was added to this
effect. Note that, this key will also be added in the state that is sent
to the browser history. Allowing to retrieve the complete state
(including the omitted keys) when clicking the back button on the
browser.

Forward-Port-Of: odoo/enterprise#65052

### Issue: The VAT lines in tax reports do not populate correctly. ### Steps to reproduce: - Activate l10n_es module - Go to Accounting > Reporting > Statement Reports > Tax Report - Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)' - In the report, only Spain and partners without countries have a NIF number ### Cause: A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain. In addition, other lines

### Issue:
The VAT lines in tax reports do not populate correctly.

### Steps to reproduce:
- Activate l10n_es module
- Go to Accounting > Reporting > Statement Reports > Tax Report
- Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)'
- In the report, only Spain and partners without countries have a NIF number

### Cause:
A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain.

In addition, other lines related to the NIF are not populated as they should.

### Solution:
Add conditions to populate the NIF lines as the specs demands it.
Specs: https://sede.agenciatributaria.gob.es/static_files/AEAT/LSI.xlsx (second point)

opw-3918623

Forward-Port-Of: odoo/enterprise#63923

Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- See community commit Adding extra tests in test_whatsapp opw-3861847

Current behaviour:
---
Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil.
(Adding a 9 to mobile phone numbers)

Cause of the issue:
---
Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, 
phone numbers aren't formatted, thus patched metadata not being applied.
See format_number in phonenumbers "Early exit for E164 case"

Fix:
---
See community commit
Adding extra tests in test_whatsapp

opw-3861847

Forward-Port-Of: odoo/enterprise#65336

Issue Currently, internals users are shown all the open shifts when they arrive on the planning app, even if the shift's role is not one of the user's role. Fix - If the employee doesn't have any roles, show all open shifts. - If the employee has role(s), show the open shifts with that role or no role. To do this, we modify the open shifts filter (which is set by default for internal users) to only show open shifts matching the user's role in the default Gantt view. opw-3888507 Forwar

Issue
Currently, internals users are shown all the open shifts when they arrive on the planning app, even if the shift's role is not one of the user's role.

Fix
- If the employee doesn't have any roles, show all open shifts.
- If the employee has role(s), show the open shifts with that role or no role.
To do this, we modify the open shifts filter (which is set by default for internal users) to only show open shifts matching the user's role in the default Gantt view.

opw-3888507

Forward-Port-Of: odoo/enterprise#62607

This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied. The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button. task-3692048 | Light mode (`:focus` state) | Dark mode | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img al

This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied.

The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button.

task-3692048

| Light mode (`:focus` state) | Dark mode |
|--------|--------|
| <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/8354c78f-6525-4aef-9057-fdb706b3cd0d"> |

Forward-Port-Of: odoo/enterprise#64801

Steps to reproduce: - Install Helpdesk - Create two internal user with admin access to Helpdesk - Log as the first user and create a ticket for the second user with empty phone Issues: An access error is shown as we do not have the rights to write on the partner phone. To fix this issue a sudo was added as well as a filter in the inverse to make sure we skip ticket without a partner phone in the inverse. opw-3989614 Forward-Port-Of: odoo/enterprise#65289 Forward-Port-Of: odoo/enterpri

Steps to reproduce:
- Install Helpdesk
- Create two internal user with admin access to Helpdesk
- Log as the first user and create a ticket for the second user with empty phone

Issues:
An access error is shown as we do not have the rights to write on the partner phone. To fix this issue a sudo was added as well as a filter in the inverse to make sure we skip ticket without a partner phone in the inverse.

opw-3989614

Forward-Port-Of: odoo/enterprise#65289
Forward-Port-Of: odoo/enterprise#64860

Forward-Port-Of: odoo/enterprise#65297

Forward-Port-Of: odoo/enterprise#65297

Following the doc https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf , InitgPty/Id is not required in the XML file. We used to block the generation if we had no value to put in it; not anymore. opw-3985622 Forward-Port-Of: odoo/enterprise#65255 Forward-Port-Of: odoo/enterprise#65214

Following the doc https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf , InitgPty/Id is not required in the XML file. We used to block the generation if we had no value to put in it; not anymore.

opw-3985622

Forward-Port-Of: odoo/enterprise#65255
Forward-Port-Of: odoo/enterprise#65214

**Steps to reproduce:** - Install Rental module - Check gantt view in Rental > Schedule **Current behavior before PR:** We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted w

**Steps to reproduce:**
	- Install Rental module
	- Check gantt view in Rental > Schedule

**Current behavior before PR:**
We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour.

So what is happening is that '_read_group_product_ids'
https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20
is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids'

**Desired behavior after PR is merged:**
After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders.

**Other solution:**
We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'.

opw-3959031

Forward-Port-Of: odoo/enterprise#65232
Forward-Port-Of: odoo/enterprise#63720

This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc). If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](ht

This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`.

The width of the elements was too small and the `overflow` value broke the layout on mobile view.
The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc).

If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](https://github.com/odoo/enterprise/pull/63271).

task-3358275
Related to task-3326263

| Before | After |
|--------|--------|
| <img width="408" alt="Screenshot 2024-05-27 at 14 19 32" src="https://github.com/odoo/enterprise/assets/108661430/56ac88f0-22e4-498c-a5f2-ea9ef9316a80"> | <img width="407" alt="Screenshot 2024-05-27 at 14 31 49" src="https://github.com/odoo/enterprise/assets/108661430/be2bdb9a-c1de-4280-bf07-2d5257d74c3d"> |
| | <img width="408" alt="Screenshot 2024-05-27 at 14 32 00" src="https://github.com/odoo/enterprise/assets/108661430/fecb7a25-04c3-48d0-a555-67c2a4aa45d4"> |

Forward-Port-Of: odoo/enterprise#45256

This will add an input type: gratification for the luxembourg payslips. If there is a gratification in the other inputs, the rules will be added to the payslip and the gratification is computed in the same way as the 13th month. Task: 3794333 Forward-Port-Of: odoo/enterprise#64473 Forward-Port-Of: odoo/enterprise#63800

This will add an input type: gratification for the luxembourg payslips. If there is a gratification in the other inputs,
the rules will be added to the payslip and
the gratification is computed in the same way as the 13th month.

Task: 3794333

Forward-Port-Of: odoo/enterprise#64473
Forward-Port-Of: odoo/enterprise#63800

Problem --- In the accounting dashboard, when going to Bank > Payments draft and cancelled payments are not filtered out by default. This makes the amount displayed on the kanban card inconsistent with the sum of the payments that are shown by default. opw-3978180 Forward-Port-Of: odoo/enterprise#65274

Problem
---
In the accounting dashboard, when going to Bank > Payments draft and cancelled payments are not filtered out by default. This makes the amount displayed on the kanban card inconsistent with the sum of the payments that are shown by default.

opw-3978180

Forward-Port-Of: odoo/enterprise#65274

Currently the tax lock date is not checked correctly in a test when posting a move. This problem is solved in the related community PR. This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date. community PR: https://github.com/odoo/odoo/pull/170475 Forward-Port-Of: odoo/enterprise#65262

Currently the tax lock date is not checked correctly in a test when posting a move.

This problem is solved in the related community PR.

This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date.

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

Forward-Port-Of: odoo/enterprise#65262

When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles. In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates. Steps to reproduce the issue: 1. Log in as "Admin". 2

When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles.

In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates.

Steps to reproduce the issue:

1. Log in as "Admin".
2. Install `website_helpdesk_knowledge` module.
3. Go on the Helpdesk module.
4. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card.
5. On the dropdown menu, click on the "Settings" option.
6. On the "Help Center" section, click on the "Knowledge" option.
7. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option.
8. Save the changes.
9. Go on the Website module.
10. On the website navbar, click on "Customer Care" nav bar.
11. The interface should list article templates.

=> TO BE: The system should not list any templates.

To fix that issue, we will simplify the search domains and exclude the templates from the search results using the `is_template` field.

Reference: https://github.com/odoo/enterprise/pull/48691

task-3987469

Forward-Port-Of: odoo/enterprise#64468

…ter its parent web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown. That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available. This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module. After this commit, the upsell feature is ava

…ter its parent

web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown.

That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available.

This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module.

After this commit, the upsell feature is available on the views that did not have it before.

Forward-Port-Of: odoo/enterprise#64942
Forward-Port-Of: odoo/enterprise#64776

We are unable to update the 'create date' and 'write date' through the ORM method. Therefore, I used a patch. task-4004191 Forward-Port-Of: odoo/enterprise#65151

We are unable to update the 'create date' and 'write date' through the ORM method.
Therefore, I used a patch.

task-4004191

Forward-Port-Of: odoo/enterprise#65151

**Steps to reproduce:** - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Create some invoices/bills and credit notes using different types of taxes - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "Generic Tax Report" - Click on "VAT Record Books (XLSX)" to download the report **Issues:** 1) Credit notes appear as positive in the report 2) Withholding taxes (having type "Retencion") are not handled. They should appear in the dedica

**Steps to reproduce:**
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Create some invoices/bills and credit notes using different types of taxes
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "Generic Tax Report"
- Click on "VAT Record Books (XLSX)" to download the report

**Issues:**
1) Credit notes appear as positive in the report
2) Withholding taxes (having type "Retencion") are not handled.
They should appear in the dedicated column.
3) Intra-European bills have a tax that is reverted. So the tax amount
should be 0, but it is not reverted in the report.
4) If an invoice has 2 lines that use 2 different taxes of type
"Recargo de Equivalencia", one of them will not appear in the report.
5) Advanced combinations of taxes on several invoice lines are not supported.

**Solution:**
This fix changes the way of generating the Libros Registro de IVA report.
Before this fix, the report was generated based on the tax lines.
One line of the report was corresponding to a regular tax line, which didn't
support advanced combinations of taxes on several invoice lines.
This fix analyzes the taxes repartition on the invoice lines and tries to respect it when generating the report.
A line of the report corresponds to a combination of taxes of different type:
(IVA + surcharge tax + withholding tax)

**Limitation:**
Having 2 taxes of the same type on the same invoice line is not supported.
The total and the tax amount will be correct but not the tax rate because
a report line has only one column to display each type of tax.

opw-3844967

Forward-Port-Of: odoo/enterprise#65230
Forward-Port-Of: odoo/enterprise#64681

**Current behavior:** Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation. **Expected behavior:** These extra lines will get the o_faulty class. **Steps to reproduce:** 1. Create a picking in the Inventory app, mark it as to-do 2. In the Barcode app, go to the picking and scan the product 3. After scanning the original demand quantity, scan it again 4. See that it

**Current behavior:**
Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation.

**Expected behavior:**
These extra lines will get the o_faulty class.

**Steps to reproduce:**
1. Create a picking in the Inventory app, mark it as to-do

2. In the Barcode app, go to the picking and scan the product

3. After scanning the original demand quantity, scan it again

4. See that it doesn't get the o_faulty class

**Cause of the issue:**
The lineIsFaulty() method is checking defunct properties to determine whether they should get this css class.

**Fix:**
Update the check so it uses an existing property.

opw-3904661

Forward-Port-Of: odoo/enterprise#65200
Forward-Port-Of: odoo/enterprise#63285

Current behavior in gstr1 report: - For invoices and credit notes, if there are nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table. After fix: - Now, the journal items are considered for their respective GSTR summary tables only. - For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table. task-3866787 Fo

Current behavior in gstr1 report:
- For invoices and credit notes, if there are  nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table.

After fix:
- Now, the journal items are considered for their respective GSTR summary tables only.
- For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table.

task-3866787

Forward-Port-Of: odoo/enterprise#65105
Forward-Port-Of: odoo/enterprise#61433

Steps to reproduce ================== 1. Go to the Accounting module 2. Open Vendor Bills 3. Click on the Scan button with debugger mode ON => Hence gives traceback Cause of the issue ================== The Issue was due to the `BillQrScan` component doing the props validation same as the `Dialog` component, the `slots` object is a mandatory prop for Dialog component but not needed for `BillQrScan`. This commit solves the traceback generating due to props validation on `BillQrScan

Steps to reproduce
==================
1. Go to the Accounting module
2. Open Vendor Bills
3. Click on the Scan button with debugger mode ON

=> Hence gives traceback

Cause of the issue
==================
The Issue was due to the `BillQrScan` component doing the props validation same as the `Dialog` component, the `slots` object is a mandatory prop for Dialog component but not needed for `BillQrScan`.

This commit solves the traceback generating due to props validation on `BillQrScan` component.

Forward-Port-Of: odoo/enterprise#65047

With this commit: https://github.com/odoo/odoo/pull/166896/commits/90088bd97ec096fa8c360868e3a1addef91bd4ce We automatically add the country of the chart template to the company if the company does not have one by default. This change had a side effect that in the context of the test "TestPeSales," the boolean field l10n_latam_use_documents on the journal was now set to True. The consequence of that was that the constraint _check_l10n_latam_documents was breaking since this constraint chec

With this commit: https://github.com/odoo/odoo/pull/166896/commits/90088bd97ec096fa8c360868e3a1addef91bd4ce

We automatically add the country of the chart template to the company if the company does not have one by default. This change had a side effect that in the context of the test "TestPeSales," the boolean field l10n_latam_use_documents on the journal was now set to True.

The consequence of that was that the constraint _check_l10n_latam_documents was breaking since this constraint checks that for the posted moves that use documents, the move must have a document type and a document number.

task: 3945833

Forward-Port-Of: odoo/enterprise#64991

Steps to reproduce: 1. Open the split tool, select a few pages, and create an expense for instance 2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred Technical reason: When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value. After this commit: No traceback will occur and if it can't

Steps to reproduce:
1. Open the split tool, select a few pages, and create an expense for instance
2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred

Technical reason:
When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value.

After this commit:
No traceback will occur and if it can't find the previous or next selected
page, it focuses on the first page by default.

Task-3874151

Forward-Port-Of: odoo/enterprise#62244