Odoo modals are supposed to be instantiated thanks to the Dialog JS
class. This allows to not duplicate modal structures and to properly
handle multi modals (which bootstrap is not supposed to).

Problem since commit 7dcb8fea:
The support for inline modals has been broken without providing a
solution for all cases. Indeed, some modals are placed directly inside
form view xml. See an example here:
https://github.com/odoo/odoo/blob/dd0533897e397dfd78ad456fea42a5a12db51246/addons/website_twitter/views/website_twitter_settings_views.xml#L24

While waiting for a new way to instantiate these inline view modals,
this commit restores their deprecated support.

Commit 8911be11 moved code from website_portal_sale to
a new sale_payment module, in order to move code down and ease its use in
variou addons. However a called method was forgotten in the process leading
to some issues when using sale_payment. This commit fixes that.

PURPOSE
=======

It's confusing as it's not used. We had a customer with two exact same rules; he complained to the
support today because Odoo decided to use the other rule. (he was confused because he thought
priorities were based on sequences as there is a sequence field that allow drag & drop)

Order is based on "applied_on, min_quantity desc, categ_id desc", not on sequences. (since v9
and it's better that way; but we forgot to remove the sequence field)

SPECIFICATION
=============

Remove field

That will avoid to have thousand separator.

Task-33646

For now, these tests do not work with another CoA than the generic one.
Depending on your testing infrastructure, they may or may not pass.
We skip then invalid CoA's and plan to make them work in master.

On the 6 June, the rate from EUR to USD change
in demo data. This cause problem in test, when
comparing amount.

We choose to not used currency rate defined in
demo data and that are time-dependent.

Rather than use a fixed height, make the logo fill the navbar height.

The import_module() method does not need to be public,
so let's mark it private. It's not called by anyone
except import_zipfile().

After 76cd8d25 it would
fail anyway because addons_path would not be prepared by
import_zipfile().

Before this fix, if the start field is readonly, the user could not create
an event. With this commit, it is also ensured that the context sends the
right default values to the view

In case of a MemoryError, there is no error message, the user gets a
"Database restore error: "

without any details.

Instead fallback to the repr.

This way, a wrong password is
"Database restore error: Access denied"
and a memoryerror

"Database restore error: MemoryError()"

Closes #17393

On a pricelist, if multiple rules were set with the same
set of rules condition, the choice of which rule/item
is used was random, according to the postgres database
state.

Adding the `id` in the order force to always use the same
rule/item (the first that was created).

opw-744865

OPW 744859

with the new views, we removed the many2many_kanban widget on many2manys, since it is the default behaviour anyway, but we also removed it for a few one2manys.  And this is a mistake, some one2manys have to behave like many2manys.

(PR #17190)

[MERGE] payment, website_(portal_sale/quote): separate payment and account code from portal_sale/quote

This commit separate code from website_portal_sale, website_sale and
website_quote in order to extract common code, separate payment code
from sale model and controller code and ease reusing of payment code
in various addons.

Main features are

 * move account-related code from website_portal_sale to a new
   website_account module
 * move payment related to sale in a new sale_payment module
 * factorize JS code to handle payment through form and tokens
 * use generic sale payment code in website_sale and website_quote

Refer to individual commits for more details on the branch content.
This commit Closes #16956.

Indeed payment module already adds a website_published button to ease
acquirer management directly in payment without link to website. The
mixin added in website_payment adds a website_url field that has no use
for payment acquirers and is not used at all in the current codebase.
As there is no website url the website publish button method is not
different than the one already implemented in payment. There is
therefore no need for this override, lessening model code in
website payment.

Online quote now uses JS code from payment module in order to make online
payments. Front-end template is updated to use o_payment_acquirer_button
generic class for payments and data is added to be managed by payment.js.
This allows to remove some strange code parsing the url to find the order
ID and token instead of using rendered values.

A payment controller is removed because it was only a shortcut to another
one. In transaction controller token parameter is renamed to access_token
to avoid confusion with payment token and match the payment and website
sale naming.

Online Quote controller now uses tools method from sale_payment module
like website_sale. This way it is now standardized and moved out of
controllers that should not perform so much model-level computation.

Previous commit added tools method related to sale transactions and
token management. This commit makes website_sale use them.

This commit adds tools method in sale_payment related to sale order
confirmation, token and transaction management. Purpose is to be able
to use them in frontend sale module like eCommerce and Online Quote and
have it standardized at model-level instead of done custom in controllers.

JS code managing transaction creation through acquirer 'Pay Now' form
button is improved in order to be less website-sale dependant. It now
takes parameters for access token and URL to call in Json. Class used
to bind JS is now o_payment_acquirer_button in order to be more generic.

eCommerce module is updated accordingly. Future commits will probably
make Online Quote (website_quote) use it.

Indeed this code is difficult to understand and uses unnecessary
variables. Both confirm_so and generate_and_pay_invoice methods now work
on payment.transaction records as they belong to that model. Finally
less code is put in the try/except of confirm_so to avoid hiding real
errors and issues.

One interesting thing would be to correctly manage so confirmation errors
and mail sending errors. This is currently not done and will maybe be
done in future commits.

Access token field is moved directly in sale module. Indeed future commits
will improve customer portal and access tokens will be used in other module
than website_quote. This commit already moves the field.

Moreover some strange code in website_sale already uses access_token even
if it does not exist in that module. Moving the field solves that issue.
Finally so_token defined in stripe is renamed to access_token to have the
same naming through all addons.

- Create an excluded tax of 20 %
- Create a customer invoice of 1000
- Create a payment of 900
- Make the matching between the invoice and the payment:
  Write-off of 83.33, with the 20 % tax

Error: 'Cannot create unbalanced journal entry'

After commit 89cbef85, the tax are by default not created
automatically anymore. We should make sure to pass the context key
`apply_taxes`.

opw-744266

When disabling the customer portal
in the general settings
(or uninstalling the `portal_sale` module directly),
the model `sale.order` no longer has a method
`get_signup_url`, and it therefore leads
to the fail of the email template rendering which is
still referencing this method.

Besides, the `access_url` is actually used only if
`is_online` is True,
(see the `% if is_online:` few lines later)
and in this case `get_signup_url`
was not used at all.

Therefore, we can assume `None` is a good alternative,
as the resul of `get_signup_url` was actually no longer
used.

opw-710481

If you have two invoices with a same product,
 - one having 1 unit of a product,
 - the other -1 unit of a product,

The sum of these quantities will be 0, and it will lead
to a division by zero in the former sql request.

The nullif should be applied on the sum, not on the line quantity.

opw-745073

This try except block was added in another era, where the piece of code
in the block was far less ambitious (and not for good reason since
adding a try except block because of a malformed mail template seems
overkill).

Even worse, this block actually prevented errors from bubbling, which
could have adverse effects.

Example: a long transaction confirmation (several seconds since it
implies S2S communication, invoice creating/validation, etc.) is
rollbacked because a mail message is recorded on the quote during
the processing time. The quote confirmation then crashes because of a
concurrent update error in postgres. This try except block does not
re-raise the error, which means that instead of retrying the operation
like the ORM would normally do, we have an incomplete traceback in the
system (since the error message crashes itself) and the transaction is
not validated (as far fetched as it may seem, this is in fact how this
bug was discovered).

This try-except block offers no gain in error logging (on the contrary,
since we have lost the initial error-causing statement) and prevent the
orm from correctly managing errors.

This commit removes it and let the orm handle the errors like a grown up
man; either crash for real (because it should crash to know if there's a
problem) or retry the transaction if it's a serialization issue.

opw-744629