Also use a `set()` to avoid processing assets multiple times when
creating moves from lines

The class modal-open on body tag allow to scroll on the modal content
which is useful if the content is taller than the window viewport.

When closing the modal, this class is removed but there may be another
modal open on which we will not be able to scroll to view
buttons/content if too big.

This commit check if a modal is still opened after closing an editor
modal and in the affirmative add back the modal-open class.

opw-674475

note : was already present in 8.0 with ec47493f, it is also present for
web.Dialog (but the modal of the editor do not inherit from web.Dialog)

Steps to reproduce:

-go to runbot 8.0 and connect
-go into human ressources/job positions
-pass into list view and click on the first item
-click on the url to open this record into the website (website_published)
-go back (back into the browser)
-you're now into the form view again and then next step is to click on the button
"next" to access the following record
-click on the url of website_published

Before the fix:

wrong record, this is the previous one that is into the href

After the fix:

correct record with the correct id into the href

Closes #11800
opw:675832

In the report "Invoice Analysis", the view under the report is grouping
lines by invoice and also by product on this invoice.

Thus, quantities in the pivot view are not the real quantity of invoice
lines, but of invoice lines with different products.

eg:

invoice a:
- line 1: product X
- line 2: product Y
- line 3: product X

in the report there would appear to only be 2 invoice line, whilst there
is in realy three (this information is accessible via "# of Lines").

closes #11954
opw-676651

Used case:

-Configure admin as multi-company user
-Create 2 fiscal positions (one for company "Odoo BE" and one for company "Odoo US")
-Set admin on company "Odoo BE"
-On supplier (Asustek) configure fiscal position Odoo BE
-Set admin on company "Odoo US"
-On supplier (Asustek) configure fiscal position Odoo US
-Configure a product (Laptop E5023) with:
   *route "Buy"
   *supplier (Asustek) without company
   *reordering rules (min qty: 20, max qty: 40)
-Set admin on company "Odoo BE"
-Run scheduler via the cron

Behavior before the fix:

-Fiscal position on the created PO is the fiscal position for "Odoo BE" (and PO is for the company "Odoo US")

Behavior after the fix:

-Fiscal position on the create PO is the fiscal position for "Odoo US".

Closes #11537

opw:673288

The state given to authorize requests should be the state code and not
the state name.

source:
https://support.authorize.net/authkb/index?page=content&id=A1454&actp=RSS

opw-675634

When recomputing stored function fields, the `write` may trigger a
cache invalidation which lead to a recompute of all the recordset
values, even the ones already saved in database.

 - Only invalidate cache for fields and records we modify
 - Rewrite query to be more efficient
 - Avoid o2m commands to be more efficient; write directly on reverse m2o

With new api, this call is not wanted anymore. The cache is cleared
automatically, no need to clear the whole cache; that's a little bit
overkill and reduce performances.

Fixes #11987
Close #11988
opw-676422

[FIX] account: multi-currency reconciliation use case as defined in opw 640248. Since the reconciliation changed, the bugfix made for saas-6 isn't valid anymore and was actually, the root cause of the same bug appearing in v9.

When a PO is copied, the date planned of the order lines should be
recomputed based on the order date.

opw-675480

When a PO is copied, the date planned of the order lines should be
recomputed based on the order date.

opw-675480

When reversing stock moves by clicking on "Reverse" in stock.picking
form view, only the stock moves not scrapped must be reversed.

opw:672236

This applies commits 313bc91c and
2ad4bd48 to Trial Balance report.

opw-676061

Avoid that an invoice for 'SO042' matches with the invoices of 'SO04'.
The use of the like is required as it may contains more than one reference to an
invoice.

opw-676921

9f541d29 made it so that date_order on
pos.order records is set using the creation_date of the clientside Order
record to avoid weird date_order values when syncing to the server is
not done immediately.

The downside of this approach is that creation_date is set during Order
creation on the client. A user that has an open POS will also have an
open order. So if it takes one hour before the first order can be made
then the date_order will reflect this.

To avoid this we will instead use a validation date, which will be set
when the user clicks on the green 'Validate' button.

Because this is a stable release we won't change the name of the key in
the JSON data that gets sent to the server. This means that from the
server point of view nothing changes.

Fixes #11933

The field base is obligatory according to a european law.
This field existed in saas-6.

opw:674713

Taxes should be sorted before computation, otherwise if some taxes
affect subsequent taxes, the computation will be wrong.

opw-676119

Closes #4722

Closes #11929
opw-676854

"Depreciation Account" must be renamed in "Depreciation Expense Account"
Reason: This is the account that will be shown in the Profit and Loss, the original
label "Depreciation Account" is confusing because it could mean a depreciation asset
account.

"Asset Account" must be renamed in "Depreciation Asset Account"
Reason: This makes it clear that this is an asset account that will receive
depreciation entries, without this wording it could mean that we are simply
informing the Asset module which account is the asset account, but that depreciation
entries go elsewhere.

opw:672852

If a user removes the taxes on a PO line, the product taxes will be
added back when the invoice is created.

opw-676858

When dealing with issues related to 'rescue' sessions we are very
limited in what we can do because the actual orders sent to the backend
exist only in localStorage in the browser on the device of the
user. Because of this it is important that we log some data about the
orders we receive in the backend to have an idea of what's going on.

opw-676497

[FIX] account: endless loop in exchange rate entry creation on full reconciliation fixed. ticket 676467

When several accounts are selected to print their GL, the GL of only one
is printed. This is due to two issues:
- 'active_id' is retrieved instead of 'active_ids'
- the method `get_action` is called with the wrong records. `self`
  refers to the wizard, not to the accounts selected.

opw-676061

When "Filter by Periods" is choosen in the wizard, the right periods
must be set in ctx to filter the account moves according to the right periods

opw:674593

Backport of 8423a0df

Clear the cache/environment in addition to rolling back
the cursor, in order to retry the transaction with fresh
data, not partially stale data.

If a user syncs his calendar with Google,
and a second user is created in the database by copying this first
user, the Google information of the first user was copied
(The Google account to sync, the token to use, the last
syncrhonization date, ...), which is obviously wrong.

On calendar syncrhonization, which can be done
manually or automatically with the according cron, all
events of the first user were created a second time,
as a second user synchronized the same Google Calendar.

opw-674141

A non-breaking space is used between the amount and the currency.
However, if a space is used as a separator, there is a possibility that
the amount will be split into several lines.

opw-674535

When a payment is registered on an invoice, the payment difference must
be considered differently if we receive the payment or pay a bill. This
is necessary at the creation of the 'Counterpart' entry. For example,
an invoice of 100 is considered as paid with a payment of 90. The
difference of 10 should be booked as a debit in case of a customer
invoice, but it should be booked as a credit in case of a vendor bill.

opw-675641

In event not during all day, it looks like
`start_date` could be defined, but `stop_date` not.

Despite the fact this is not such a normal state, this should
not prevent the save of the event with the
`_check_closing_date` constraint, checking that the ending
date is after the starting date
(in the case of an event not during the whole day,
this is ensured with the `start_datetime` and the
`stop_datetime`

opw-676245

On smaller screens some buttons will be hidden. An example of this is
the 'Validate' button in the stock.picking form view. It is not :visible
but it should still be possible to trigger through scanning a
'O-BTN.validate' barcode.

opw-676741

The comments field was ignored (because reasons) when exporting terms in CSV.
This was an issue when using the wizard 'Synchronize Terms' as it first export
the terms of every module in CSV.

opw-673853

When the user searches for date (or a datetime) in the search bar, the
suggested date can become completely wrong. For example, in the French
localization where the date format is DD/MM/YYYY, the system will search
for the date MM/DD/YYYY. This is even worse when the date is not fully
written: DD/MM could be converted to MM/DD/0000, which doesn't make any
sense. This is related to the moment issue
https://github.com/moment/moment/issues/1407.

The fix is to make sure that the input date has a correct format thanks
to `parse_value`. The latter converts the date into a fixed format.

Fixes #11876
opw-676604

When creating an customer invoice with a product linked to a deferred revenue
category, the account used in the invoice line must be the account_asset_id.

When creating an vendor bill with a product linked to an asset
category, the account used in the invoice line must be the account_depreciation_id.

Inspired from 0287c1e1

opw:677098