Before this commit, the messaging rpc method ignored some parameters when passed as `kwargs`. This PR allow the following arguments to be passed either in `args` or `kwargs`: - `create`: `vals_list`. - `write`: `vals`. - `read`: `fields`. - `readGroup`: `fields/groupBy/domain`. - `search`: `domain`. - `search_read`: `domain/fields` Forward-Port-Of: odoo/odoo#104190

Before this commit, the messaging rpc method ignored some parameters
when passed as `kwargs`.

This PR allow the following arguments to be passed either in `args` or
`kwargs`:
- `create`: `vals_list`.
- `write`: `vals`.
- `read`: `fields`.
- `readGroup`: `fields/groupBy/domain`.
- `search`: `domain`.
- `search_read`: `domain/fields`

Forward-Port-Of: odoo/odoo#104190

[FIX] account: don't cross exchange rates when reconciling an invoice with a refund Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one. This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the account

[FIX] account: don't cross exchange rates when reconciling an invoice with a refund

Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one.

This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the accounts properly.

By not swapping the rates anymore, we avoid the creation of these journal items.

OPW 2888592


[FIX] account: fix exigibility of cash basis rounding corrections in exchange move

When reconciling an invoice using cash basis taxes with multiple payments, it is possible that some base or tax amount falls victim of rounding errors (for example, a tax amount of 9.99 would become 4,49 when paying the invoice with two payments of half its amount, hence loosing one cent).

In this case, when the invoice gets fully paid, we fix that by using adjustment lines in an exchange difference entry (even in monocurrency).

The bug we fix here is that the lines added into this exchange difference entry were never considered as tax exigible, and hence never appeared in the tax report, even though they should. This was due to the fact tax exigibility is recomputed automatically when creating the entry, so the value needs to be set afterwards.

OPW 2888592

Forward-Port-Of: odoo/odoo#104362
Forward-Port-Of: odoo/odoo#103554

In some reports, the aggregation engine could face a problem if the number of elements of an addition (for instance) were too numerous. If they were separated by spaces or \n, the addition would not occur and the error message would not be clear. Trimed the spaces before dealing with said formula. Forward-Port-Of: odoo/odoo#104518

In some reports, the aggregation engine could face a problem if the number of elements of an addition (for instance) were too numerous.

If they were separated by spaces or \n, the addition would not occur and the error message would not be clear.

Trimed the spaces before dealing with said formula.

Forward-Port-Of: odoo/odoo#104518

The tour snippet_cache_across_websites is at some point switching between websites. The selector would be taking the second option in the website list, which may not be correct if a module is adding a website in its demo data. This change aim to always switch from website 1 to website 2, without caring about any other potentially existing website. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104466

The tour snippet_cache_across_websites is at some point switching between websites. The selector would be taking the second option in the website list, which may not be correct if a module is adding a website in its demo data.
This change aim to always switch from website 1 to website 2, without caring about any other potentially existing website.

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

Forward-Port-Of: odoo/odoo#104466

This will bind `http.request` before `_get_session_and_dbname()` is called - doesn't change anything for core as `_get_session_and_dbname` can't fail; - but it enables custom modules to override `http.db_filter()` with a more complex logic that would need to access `http.request` PS: btw @Julien00859 thanks a lot for the effort you put into splitting the httpocalypse into different commits; I didn't grasp everything yet but the exhaustive explanations are a delight to read! --- I confir

This will bind `http.request` before `_get_session_and_dbname()` is called
- doesn't change anything for core as `_get_session_and_dbname` can't fail;
- but it enables custom modules to override `http.db_filter()` with a more complex logic that would need to access `http.request`

PS: btw @Julien00859 thanks a lot for the effort you put into splitting the httpocalypse into different commits; I didn't grasp everything yet but the exhaustive explanations are a delight to read!

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

Forward-Port-Of: odoo/odoo#104573

When a report was set to only accept tax exigible items (typically for the generic tax report), its children did not inherit this behavior by default. Because of that, the localized tax reports and OSS reports didn't filter the items properly. Forward-Port-Of: odoo/odoo#104591

When a report was set to only accept tax exigible items (typically for the generic tax report), its children did not inherit this behavior by default. Because of that, the localized tax reports and OSS reports didn't filter the items properly.

Forward-Port-Of: odoo/odoo#104591

Description of the issue/feature this PR addresses: Before this PR when you select a pos.payment in custom, it raise. It doesn't make sens to use api.model here @pimodoo @rco-odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#99237

Description of the issue/feature this PR addresses:
Before this PR when you select a pos.payment in custom, it raise.
It doesn't make sens to use api.model here

@pimodoo @rco-odoo 




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

Forward-Port-Of: odoo/odoo#99237

*: web_editor Since [1], it was not possible to edit a company team snippet image anymore as soon as the page was saved once. Indeed that commit added o_not_editable/contenteditable="false" on the parent column to make sure no text can be added in that column and contenteditable="true" on the images so that they are still editable (even though HTML-specs-wise adding contenteditable="true" on images probably does not mean much as images are self-closing tags, our editor understand that a

*: web_editor

Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.

This fixes the problems with an ugly patch. We'll review what to do in
master.

Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.

[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3

opw-3031217
opw-3032482
opw-3035289

Forward-Port-Of: odoo/odoo#104335
Forward-Port-Of: odoo/odoo#104156

Previously, when copying a report with top-level aggregation lines that reference other top-level lines, the codes in the aggregation formula where not correctly replaced. This commit solves the issue, so reports can be correctly copied. Task: [3046355](https://www.odoo.com/web#id=3046355&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104

Previously, when copying a report with top-level aggregation lines that reference other top-level lines, the codes in the aggregation formula where not correctly replaced.

This commit solves the issue, so reports can be correctly copied.

Task: [3046355](https://www.odoo.com/web#id=3046355&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

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

Forward-Port-Of: odoo/odoo#104448

The domain of the datasources was not recomputed on the deletion of a filter that impacted it. Furthermore, the issue was also present when a client would UNDO/REDO some revisions. Task 3002004 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#103422

The domain of the datasources was not recomputed on the deletion of a filter that impacted it. Furthermore, the issue was also present when a client would UNDO/REDO some revisions.

Task 3002004

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

Before this PR, the mail bot would have answered to every incoming messages including system notifications. Answering to system notifications makes no sense and leads to the answer being formatted as a notification since the mail bot copies the message type of the message being answered. This PR fixes the issue by preventing the mail bot from answering anything else than comments. task-3044856 Forward-Port-Of: odoo/odoo#104281

Before this PR, the mail bot would have answered to every incoming
messages including system notifications. Answering to system
notifications makes no sense and leads to the answer being formatted
as a notification since the mail bot copies the message type of the
message being answered.

This PR fixes the issue by preventing the mail bot from answering
anything else than comments.

task-3044856

Forward-Port-Of: odoo/odoo#104281

**Description of the issue/feature this PR addresses:** Currently no form view is defined for the model **mail.link.preview and mail.message.reaction** and field labels where in small letters. So the UI is not looking good as odoo renders dynamic form view. **Current behavior before PR:** Missing form view for multiple models. And for the mail.message.reaction model, all the fields are readonly fields, so there is no point of showing the create and edition buttons. ![Screenshot from 20

**Description of the issue/feature this PR addresses:**

Currently no form view is defined for the model **mail.link.preview and mail.message.reaction** and field labels where in small letters. So the UI is not looking good as odoo renders dynamic form view.

**Current behavior before PR:**
Missing form view for multiple models. And for the mail.message.reaction model, all the fields are readonly fields, so there is no point of showing the create and edition buttons.

![Screenshot from 2022-10-21 11-30-23](https://user-images.githubusercontent.com/27989791/197152224-eb8a1375-b02b-4206-8dd0-51339cee70fd.png)

**Desired behavior after PR is merged:**
Clean form view

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

Forward-Port-Of: odoo/odoo#103732

To reproduce: - Define an asset from a related purchase with a Miscellaneous journal - Access the asset from the smart button of the bill form view - Click on the button to modify the asset - Change the amount - Confirm - An error pops, saying that we're trying to create invoice line with the wrong journal. The problem is the context says you are trying to create bill lines while you are trying to create depreciation lines. We should just remove this information when clicking on the sm

To reproduce:
- Define an asset from a related purchase with a Miscellaneous journal
- Access the asset from the smart button of the bill form view
- Click on the button to modify the asset
- Change the amount
- Confirm
- An error pops, saying that we're trying to create invoice line with the wrong journal.

The problem is the context says you are trying to create bill lines while you are trying to create depreciation lines.
We should just remove this information when clicking on the smart button.

t-2878986

Forward-Port-Of: odoo/enterprise#33243
Forward-Port-Of: odoo/enterprise#28181

Whenever an employee has a simple holiday pay to recover, the amount to recover is only depending on the number of days and is not capped. If the employee earns less in his/her new company, the holiday pay amount to recover should be capped to the employee cost for the number of days to recover. Example: If an employee has 3000€ of simple holiday pay, 10 days to recover and costs 250€ per day in his/her previous company. Before this commit, the total amount to be recovered is divided b

Whenever an employee has a simple holiday pay to recover, the amount to recover is only depending on the number of days and is not capped.

If the employee earns less in his/her new company, the holiday pay amount to recover should be capped to the employee cost for the number of days to recover.

Example:
If an employee has 3000€ of simple holiday pay, 10 days to recover and costs 250€ per day in his/her previous company.

Before this commit, the total amount to be recovered is divided by the number of days to recover. Meaning that 300€ will be taken from the holiday pay each day the employee is on leave.

After this commit, the amount deducted from the simple holiday pay equals the number of days taken multiplied by the daily cost of the employee.
Since the employee costs 250€/day, the maximum amount deducted from the simple holiday pay is 2500€ after the 10 days of leave are taken.

task-2984607

Forward-Port-Of: odoo/enterprise#33454
Forward-Port-Of: odoo/enterprise#32017

The domain of the datasources was not recomputed on the deletion of a filter that impacted it. Furthermore, the issue was also present when a client would UNDO/REDO some revisions. Task 3002004 Forward-Port-Of: odoo/enterprise#32884

The domain of the datasources was not recomputed on the deletion of a filter that impacted it. Furthermore, the issue was also present when a client would UNDO/REDO some revisions.

Task 3002004

Forward-Port-Of: odoo/enterprise#32884

Forward-Port-Of: odoo/enterprise#33441

Forward-Port-Of: odoo/enterprise#33441

The DPIVA export was using the locale in order to translate the month name in es_MX. This would cause issue as it depends on the installed locales, which means the test based on it may fail depending on the machine. Forward-Port-Of: odoo/enterprise#33388

The DPIVA export was using the locale in order to translate the month name in es_MX.
This would cause issue as it depends on the installed locales, which means the test based on it may fail depending on the machine.

Forward-Port-Of: odoo/enterprise#33388

Fixes two issues in the "bill" tab on the asset form: - The list view opened with "add a line" have many irrelevant fields shown, so we will make a new one without these. - The same "add a line" would show all types of moves, while only the Vendor Bills and Vendor Credit Notes are relevant in this context. Forward-Port-Of: odoo/enterprise#32622

Fixes two issues in the "bill" tab on the asset form:
    - The list view opened with "add a line" have many irrelevant
      fields shown, so we will make a new one without these.
    - The same "add a line" would show all types of moves, while
      only the Vendor Bills and Vendor Credit Notes are relevant
      in this context.

Forward-Port-Of: odoo/enterprise#32622

Purpose ======= The sick time off amount is counted twice if: - There is no attendances - Sick time off and sick time off without guaranteed salary - Part time working time that allows having half days of absences Forward-Port-Of: odoo/enterprise#33323 Forward-Port-Of: odoo/enterprise#33308

Purpose
=======

The sick time off amount is counted twice if:
- There is no attendances
- Sick time off and sick time off without guaranteed salary
- Part time working time that allows having half days of absences

Forward-Port-Of: odoo/enterprise#33323
Forward-Port-Of: odoo/enterprise#33308