The expense dashboard has its global filters restored after they were removed by mistake in an earlier change. This helps users filter dashboard information as intended in the current version.

Partial revert of #109033 (for some reason, `robodoo r-` did not kill the staging and the PR got merged)

The global filters were removed in 16.0 because the pivot "9" does not exists in this dashboard.
But it exists in master.
See #104125




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

Accounting reports no longer show an unnecessary leading comma when cash basis is the only remaining filter option. This small correction makes the report controls look cleaner and avoids confusion for users who disable most filters.

When deactivating most of the filters in the accounting reports, the cash basis appeared as the only option and started with a comma. This PR fixes this minor issue by correcting the condition of this comma.

task-3101548

Appraisal report records now open in a proper read-only form instead of the generic default form. This prevents users from seeing a create option that could trigger an error, making navigation from the Gantt view smoother and more reliable.

currently for the model hr.appraisal.report no form view is defined and thus on clicking records from the gantt view, the record is opened with default form view, with create button. And when user clicks this create button exception is raised. 

to avoid, this adding form view for hr.appraisal.report model

![Screenshot from 2022-12-03 08-07-59](https://user-images.githubusercontent.com/27989791/205424921-afb354ac-1885-4b6d-bfdf-f9b756b031a4.png)

The chat icon in the form view was not properly aligned in the public profile. Forward-Port-Of: odoo/odoo#109004

The chat icon in the form view was not properly aligned in the public profile.

Forward-Port-Of: odoo/odoo#109004

From https://www.odoo.com/documentation/16.0/applications/finance/accounting/receivables/customer_invoices/electronic_invoicing.html It is said that Peppol BIS Billing 3.0 (UBL) is supported by companies whose countries are part of the EAS list Refernce: https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/ Austria is in the EAS list opw:3083502 Forward-Port-Of: odoo/odoo#108926

From https://www.odoo.com/documentation/16.0/applications/finance/accounting/receivables/customer_invoices/electronic_invoicing.html

It is said that Peppol BIS Billing 3.0 (UBL) is supported by companies whose countries are part of the EAS list

Refernce: https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/

Austria is in the EAS list

opw:3083502

Forward-Port-Of: odoo/odoo#108926

An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records. since https://github.com/odoo/enterprise/pull/34994 opw-3111577 enterprise: https://github.com/odoo/enterprise/pull/35232 Forward-Port-Of: odoo/odoo#108672

An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry

This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records.

since https://github.com/odoo/enterprise/pull/34994

opw-3111577
enterprise: https://github.com/odoo/enterprise/pull/35232

Forward-Port-Of: odoo/odoo#108672

Current behavior: Partial and reversed payments were not taken into account for the product margin calculation. Steps to reproduce: 1. Create a product with a common avco setup. 2. Go to purchase 1 unit at 10 dollars. 3. Upon confirming the invoice your cost is updated in the product margin report. 4. Create a partial payment on the bill. This creates issues as the product margin report is looking for paid or open not partially paid so it won't show up in the cost calculation. 5. Once t

Current behavior:
Partial and reversed payments were not taken into account for the product margin calculation.

Steps to reproduce:
1. Create a product with a common avco setup.
2. Go to purchase 1 unit at 10 dollars.
3. Upon confirming the invoice your cost is updated in the product margin report.
4. Create a partial payment on the bill. This creates issues as the product margin report is looking for paid or open not partially paid so it won't show up in the cost calculation.
5. Once the bill is fully paid then it shows up in the cost section of the product margin report again as its payment status moves to Paid.
6. Create a sales order for the unit at 100 dollars.
7. Invoice for the full amount then cancel it by creating a full credit note to put the original invoice in reversed status. This will have only the credit note show up in the turnover calculation as it is in paid status while the original invoice doesn't have a paid or open status so it isn't taken into account.

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

Forward-Port-Of: odoo/odoo#100022

The test was skipped because the expense dashboard was broken when the test was merged. See https://github.com/odoo/odoo/commit/17afe2987e4146b85187b31a34caf7146d5a7cf2 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#109017

The test was skipped because the expense dashboard was broken when the test was merged.
See https://github.com/odoo/odoo/commit/17afe2987e4146b85187b31a34caf7146d5a7cf2

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

Steps to reproduce the issue -Go to Document and create a spreadsheet document SD (for example Sales Commission) -Display SD and notice that there is some data in it -Add lang Czech and set it on your profile -Display SD Bug: There is no data in SD The issue arise because `read_group` values are already translated to the user's language. e.g. let's we group by `create_date:month`, in Czech, we get `"create_date:month": "září 2022"` (september 2022). The previous strategy to map

Steps to reproduce the issue

-Go to Document and create a spreadsheet document SD (for example Sales Commission) -Display SD and notice that there is some data in it -Add lang Czech and set it on your profile
-Display SD

Bug:
There is no data in SD

The issue arise because `read_group` values are already translated to the user's language.

e.g. let's we group by `create_date:month`, in Czech, we get `"create_date:month": "září 2022"` (september 2022).

The previous strategy to map the `read_group` result to the PIVOT functions[1] was to let momentJS parse the result, then format it to the PIVOT function format. However, we can't realistically assume momentJS can parse any date in any language.

About the adapted tests:
The tests were actually wrong because the mock server is also wrong. The mock implementation of `read_group` returns days formatted as "2022-09-08" ("yyyy-MM-dd") instead of "08 Sept 2022". Because the business code didn't expect this format, it resulted with wrong values.
See odoo/odoo#105546

[1] PIVOT function argument is "09/2022" for september 2022

opw-3052858

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

Forward-Port-Of: odoo/odoo#108990

Forward-Port-Of: odoo/odoo#108990

Also load emoji data on focusing composer. Forward-Port-Of: odoo/odoo#108993

Also load emoji data on focusing composer.

Forward-Port-Of: odoo/odoo#108993

Since 2013 we have a kind of a url hack that allows to redirect to the initial URL after installing a lang through the website, see [1]. It was even tested in python unit test with [2] but sadly it was still broken by a combination of [3] and [4] which actually broke it at the javascript level: the python view was correctly still outputing the correct URL and the python part was correctly handling that return URL when passed, but the javascript was not actually passing the URL from the view/h

Since 2013 we have a kind of a url hack that allows to redirect to the initial URL after installing a lang through the website, see [1].

It was even tested in python unit test with [2] but sadly it was still broken by a combination of [3] and [4] which actually broke it at the javascript level: the python view was correctly still outputing the correct URL and the python part was correctly handling that return URL when passed, but the javascript was not actually passing the URL from the view/href to the python side as the lang install wizard was now called through JS instead of a normal backend URL redirect (since the website frontend > backend imp at [4]).

Step to reproduce:
- Go to any page other than the homepage
- Click on footer > add a language
- Add a language
- You are redirected to the homepage always instead of the URL you came from

[1]: https://github.com/odoo/odoo/commit/5cfbcc3aff5a28022b397ec7a28ebaca6db43673
[2]: https://github.com/odoo/odoo/commit/269aa594111a152ad4b7714856ea745bfef57155
[3]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
[4]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

Forward-Port-Of: odoo/odoo#108478

Before this commit, it was not possible to have two vimeo videos playing at the same time on the same page. Steps to reproduce the bug: - Drop two blocks containing an image - Replace the two images with vimeo videos - For each of these videos, enable the autoplay feature => Only one of these videos is played automatically. When you play the other one, the first one is paused and vice versa. It is impossible to have both videos running at the same time. This commit allows to correct this

Before this commit, it was not possible to have two vimeo videos playing at the same time on the same page.
Steps to reproduce the bug:
- Drop two blocks containing an image
- Replace the two images with vimeo videos
- For each of these videos, enable the autoplay feature

=> Only one of these videos is played automatically. When you play the other one, the first one is paused and vice versa. It is impossible to have both videos running at the same time. This commit allows to correct this by allowing to play several vimeo videos at the same time when they have the autoplay feature activated. Note that if the option is not enabled, the behavior remains similar to before, only one video can be played at a time.

opw-3107447

Forward-Port-Of: odoo/odoo#108871
Forward-Port-Of: odoo/odoo#108766

Reproduction: 1. Install Accounting, l10n_sa 2. Create/Switch to a company located in Saudi Arabia 3. Go to Accounting -> Customer Invoice, and create a new invoice with a customer with language preference set to Arabic 4. Choose any product, and set the Payment terms as Immediate Payment 5. Confirm the invoice and print it, the payment term on the left end of the invoice is in Arabic, which should be in English Reason: in Odoo 16, the rendering of “t-field” loses the provided context be

Reproduction:
1. Install Accounting, l10n_sa
2. Create/Switch to a company located in Saudi Arabia
3. Go to Accounting -> Customer Invoice, and create a new invoice with a customer with language preference set to Arabic
4. Choose any product, and set the Payment terms as Immediate Payment
5. Confirm the invoice and print it, the payment term on the left end of the invoice is in Arabic, which should be in English

Reason: in Odoo 16, the rendering of “t-field” loses the provided context because the values are rendered with the env context instead. The change is introduced by https://github.com/odoo/odoo/commit/880954ebfc1106411b7f7a7d60aee05dfae60893 here: 
https://github.com/odoo/odoo/blob/810a1d29bfa7c497627a37e0cec64df51b75bb4b/odoo/addons/base/models/ir_qweb_fields.py#L120

Fix: Using “t-out” instead of “t-field” for html fields in the template to keep the forced context of en-US. Similar fixes are done for other html fields in this template, e.g. fiscal_position_id.note, narration. These fields’ types were changed from Char to Html here: https://github.com/odoo-dev/odoo/commit/23483865b1508346f5a5e178f4a436fe1a9d9f55

Related commit:
Change in ir_qweb_fields.py : https://github.com/odoo/odoo/commit/880954ebfc1106411b7f7a7d60aee05dfae60893 
Change of field type: https://github.com/odoo-dev/odoo/commit/23483865b1508346f5a5e178f4a436fe1a9d9f55

opw-3085284

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

Forward-Port-Of: odoo/odoo#108995

Rendering the clickable cells is not a negligeable operation. And it happens at every rendering (every scroll operation). Especially, detecting which functions the cell contains. The slow operation is parsing formula. On the "CRM Leads" dashboard, depending on the visible cells: Before: 10+ms (almost the full 16ms allowed to reach 60fps) After: ~2-3ms --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#109047

Rendering the clickable cells is not a negligeable operation.
And it happens at every rendering (every scroll operation).

Especially, detecting which functions the cell contains.
The slow operation is parsing formula.

On the "CRM Leads" dashboard, depending on the visible cells:
Before: 10+ms (almost the full 16ms allowed to reach 60fps)
After: ~2-3ms

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

Forward-Port-Of: odoo/odoo#109047

Steps: - Install knowledge on a fresh db - Install and set fr_BE language - Open knowldge - Traceback The traceback occurs because `emoji_registry.js` fails to load `emoji_data.js` because of some translated string that contains non-escaped characters for JSON opw-3110823 Forward-Port-Of: odoo/odoo#109061

Steps:
- Install knowledge on a fresh db
- Install and set fr_BE language
- Open knowldge
- Traceback

The traceback occurs because `emoji_registry.js` fails to load `emoji_data.js` because of some translated string that contains non-escaped characters for JSON

opw-3110823

Forward-Port-Of: odoo/odoo#109061

Before this commit: - helpdesk list view ticket name is not editable. So in this commit make the name field editable. task-2992368 Forward-Port-Of: odoo/enterprise#32493

Before this commit:
- helpdesk list view ticket name is not editable.

So in this commit make the name field editable.

task-2992368

Forward-Port-Of: odoo/enterprise#32493

test_same_name_currency is doing currency tests, expecting the root user currency to be USD. But in some builds, it may not be the case as the root user currency would be the same as the default company, which can change depending on the modules installation. In the nightly that has the issue, l10n_au is installed which cause the currency of the root user to be AUD. The solution is to use the self.env.user instead, as it is created by the accounting test setUpClass and is using the generi

test_same_name_currency is doing currency tests, expecting the root user currency to be USD.
But in some builds, it may not be the case as the
root user currency would be the same as the default company, which can change depending on the modules installation.
In the nightly that has the issue, l10n_au is installed which cause the currency of the root user to be AUD.

The solution is to use the self.env.user instead,
as it is created by the accounting test setUpClass and is using the generic chart template, so its currency will be USD.

Forward-Port-Of: odoo/enterprise#35385

Before this commit, Helpdesk > Dashboard targets only accept inputs with a dot as a decimal separator, even in languages that use a comma and also it does not support the decimal places values. For Ex: if the user enters 25.56 it will only display the 25.00 so decimal was converted to an integer by default. So in this commit, check for the integer values and display only integer values instead of float on the dashboard and updated test cases according to that. task-2942432 Forward-

Before this commit, Helpdesk > Dashboard targets only accept
inputs with a dot as a decimal separator, even in languages
that use a comma and also it does not support the decimal places
values. For Ex: if the user enters 25.56 it will only display the
25.00 so decimal was converted to an integer by default.

So in this commit, check for the integer values and display only
integer values instead of float on the dashboard and updated 
test cases according to that.

task-2942432

Forward-Port-Of: odoo/enterprise#35317
Forward-Port-Of: odoo/enterprise#30405

The test_dashboard_stats in hr_payroll had many conditional asserts as the expected values were dependent on the current day. To simplify the test cases it was decided to split one test into multiple tests testing each possible assertion using freezetime. task-3116501 Forward-Port-Of: odoo/enterprise#35396 Forward-Port-Of: odoo/enterprise#35383

The test_dashboard_stats in hr_payroll had many conditional asserts as the expected values were dependent on the current day. To simplify the test cases it was decided to split one test into multiple tests testing each possible assertion using freezetime.

task-3116501

Forward-Port-Of: odoo/enterprise#35396
Forward-Port-Of: odoo/enterprise#35383

Steps to reproduce the issue -Go to Document and create a spreadsheet document SD (for example Sales Commission) -Display SD and notice that there is some data in it -Add lang Czech and set it on your profile -Display SD Bug: There is no data in SD The issue arise because `read_group` values are already translated to the user's language. e.g. let's we group by `create_date:month`, in Czech, we get `"create_date:month": "září 2022"` (september 2022). The previous strategy to map

Steps to reproduce the issue

-Go to Document and create a spreadsheet document SD (for example Sales Commission) -Display SD and notice that there is some data in it -Add lang Czech and set it on your profile
-Display SD

Bug:
There is no data in SD

The issue arise because `read_group` values are already translated to the user's language.

e.g. let's we group by `create_date:month`, in Czech, we get `"create_date:month": "září 2022"` (september 2022).

The previous strategy to map the `read_group` result to the PIVOT functions[1] was to let momentJS parse the result, then format it to the PIVOT function format. However, we can't realistically assume momentJS can parse any date in any language.

About the adapted tests:
The tests were actually wrong because the mock server is also wrong. The mock implementation of `read_group` returns days formatted as "2022-09-08" ("yyyy-MM-dd") instead of "08 Sept 2022". Because the business code didn't expect this format, it resulted with wrong values.
See https://github.com/odoo/odoo/pull/105546

opw-3052858 

[1] PIVOT function argument is "09/2022" for september 2022

Forward-Port-Of: odoo/enterprise#34010
Forward-Port-Of: odoo/enterprise#33862

Before this commit, if a picking type uses "Move Entire Packages", the lines are grouped by package in the pickings but not in picking batch. This commit fixes that, grouping the batch's lines too if the batch's picking type also use "Move Entire Packages". task-3010914 Forward-Port-Of: odoo/enterprise#32506

Before this commit, if a picking type uses "Move Entire Packages", the lines are grouped by package in the pickings but not in picking batch. This commit fixes that, grouping the batch's lines too if the batch's picking type also use "Move Entire Packages".

task-3010914

Forward-Port-Of: odoo/enterprise#32506

…parate folder as it has nothing to do with the bank_recon components Forward-Port-Of: odoo/enterprise#35063

…parate folder as it has nothing to do with the bank_recon components

Forward-Port-Of: odoo/enterprise#35063

An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records. since https://github.com/odoo/enterprise/pull/34994 opw-3111577 Forward-Port-Of: odoo/enterprise#35232

An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry

This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records.

since https://github.com/odoo/enterprise/pull/34994

opw-3111577

Forward-Port-Of: odoo/enterprise#35232

Fixed the condition that is checking if a url is a YouTube url. When the url is not a YouTube url, the "match" method returns null. So the condition in the return would consequently throw "TypeError: Cannot read properties of null (reading 'length')". To reproduce the error, create a link document ("ADD A LINK"), put a non-youtube url. Then, click on another document of the page. OPW-3113765 Forward-Port-Of: odoo/enterprise#35361

Fixed the condition that is checking if a url is a YouTube url.

When the url is not a YouTube url, the "match" method returns null. So the condition in the return would consequently throw "TypeError: Cannot read properties of null (reading 'length')".

To reproduce the error, create a link document ("ADD A LINK"), put a non-youtube url. Then, click on another document of the page.

OPW-3113765

Forward-Port-Of: odoo/enterprise#35361

Forward-Port-Of: odoo/enterprise#35357

Forward-Port-Of: odoo/enterprise#35357

Converted row['partner_commercial_partner_id'] to string in order for it to be subscriptable. When exporting a XAF report an error was raised when partner_name and partner_commercial_company_name was empty. [:50] was then subscripting row['partner_commercial_partner_id'] which is an integer. OPW-3085277 Forward-Port-Of: odoo/enterprise#35295

Converted row['partner_commercial_partner_id'] to string in order for it to be subscriptable.

When exporting a XAF report an error was raised
when partner_name and partner_commercial_company_name was empty. [:50] was then subscripting row['partner_commercial_partner_id'] which is an integer.

OPW-3085277

Forward-Port-Of: odoo/enterprise#35295

lines_to_export is a stored computed field which by default has compute_sudo=True. Because of this the multi-company record rules are not applied. This also stops manually calling _compute_lines_to_export in the test and instead leaves it to the ORM so we can properly test this. opw-3100845 PR note: it's possible to add `compute_sudo=False` to the field as well, but this way avoids changing a field definition. Forward-Port-Of: odoo/enterprise#35349 Forward-Port-Of: odoo/enterprise#3529

lines_to_export is a stored computed field which by default has compute_sudo=True. Because of this the multi-company record rules are not applied.

This also stops manually calling _compute_lines_to_export in the test and instead leaves it to the ORM so we can properly test this.

opw-3100845

PR note: it's possible to add `compute_sudo=False` to the field as well, but this way avoids changing a field definition.

Forward-Port-Of: odoo/enterprise#35349
Forward-Port-Of: odoo/enterprise#35298