When importing bank statements, a rainbow man is shown but with no action button
The active model is account.bank.statement.import in this context

Before this commit, the rainbow man was staying with no possible action

closes odoo/odoo#30723

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

- Activate: 'Order-Specific Routes' and 'Dropshipping'
- Create a stockable product in AVCO + AUTO
- Purchase the product at $10 and validate the receipt
  => One product @ $10 in stock
- Sell the product via dropshipping
- A PO is generated, change unit price to $20, validate
- Validate the picking

The product in stock has now a cost of $15, i.e. the dropship impacted
the cost of the product.

Now if the product in stock is sold, the product will go out at a cost
of $15. This will lead to a wrong accounting valuation (0 product in
stock with -$5 in stock).

opw-1922289
opw-1935272
opw-1937672

closes odoo/odoo#31786

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.

It is now correctly hidden.

Fixes #30580
opw-1937833

closes odoo/odoo#31743

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When comparing product, there was already an exceptions that would not
list the attributes if they were only "create_variant=False" type.

But if we mix attribute create_variant False or not on a product, we
could get an error.

With this changeset, create_variant=False attribute are ignored also
when mixed with create_variant=True attributes.

opw-1946361
closes #31680

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Sequel of cc54194e.
The mentioned fix only worked when the user was public.

The problem arises when calling the function `_get_fpos_by_region()`
in `sudo` without specifying the company and this happens, for instance,
in every `onchange_partner_*` function of a sale order.

We propose to add the `force_company` key in the context of the sale
order to ensure the right company when selecting the fiscal position.

closes odoo/odoo#31751

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

- Fixes incorrect user type assignments on some accounts
- Fixes incorrect account assignments on taxes
- Adds a few accounts that Japanese companies would typically need
- Changes some account codes to make the structure more consistent
- Updates descriptions of some taxes to make them appear more natural
  on PDF reports

closes odoo/odoo#30780

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Groups with more than 3 digits exist, but none of the accounts are
"hanging" from them. For example, the group of accounts 1030 and 1034 is
103, even though 1030 and 1034 groups exist. The account structure
should concur with the account group structure.

closes odoo/odoo#28420

Signed-off-by: Josse Colpaert <jco-odoo@users.noreply.github.com>

This reverts commit 1cdf2bda.
$(':focus') seems not working depending on browser version but
we don't know yet exactly why.

opw-1948266

closes odoo/odoo#31807

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since 8da3750c, logger does not need to
be muted anymore.

This reverts commits c3764265 and
1693a27f.

Have a list view, apply a group_by and a filter with a sort parameter

Click on one record to access the form view
Have a x2m within it

Before this commit, the x2m records were loaded with a context containing
the keys orderedBy and group_by
It seems harmless at first, but even conceptually those keys should not be here
- they apply on a list of records, and not to individual ones
- they may contain field names not existing in the x2m model
Hence, when accessing another list view through an action button, the list
will try to be orderedBy or group_by with the given context
Which is plain wrong in the first place and may cause crashes

After this commit, the context of a record datapoint (representing a single record)
is stripped from the keys

Read the opw for a concrete use case
OPW 1943583

closes odoo/odoo#31706

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

- Create a fiscal position FP which maps the deposit product account to
  another account
- Create a SO, use the fiscal position FP.
- Create a downpayment

The account is not mapped following the fiscal position.

opw-1947069

closes odoo/odoo#31781

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Reverts 2b1d3ff8 introduced in 10.0 via

It was relatively useful in Odoo 10.0 because in Python 2 the exception
was missing a root cause traceback. But Python 3 includes exception
chaining by default, so it comes for free.
See [PEP3134](https://legacy.python.org/dev/peps/pep-3134/

)

On top of being redundant in P3, it can also break some testcases
by causing an extra ERROR log entry, even when the final exception is
expected and caught. So it's simpler to remove it.

closes odoo/odoo#31699

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

Authorize.Net is phasing out the MD5 based hash use for transaction response
verification in favor of the SHA-512 based hash utilizing a Signature Key.

Instead of hashing with md5 the transaction key, it is now required to hash
the signature key (binary format) with SHA-512.

Support for MD5 will be dropped the 7th March 2019 for sandbox environment and
the 28th March 2019 for production environment, initially planned for the 14th.

Note that as of February 11, 2019 authorize removed the ability to configure or
update MD5 Hash setting in the Merchant Interface.
Merchants who had this setting configured have been emailed/contacted.

opw-1943030

Usefull links:
https://developer.authorize.net/support/hash_upgrade/
https://support.authorize.net/s/article/What-is-a-Signature-Key
https://support.authorize.net/s/article/MD5-Hash-End-of-Life-Signature-Key-Replacement
https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how



closes odoo/odoo#31642

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

The text was in a value tag, making it untranslatable

Closes odoo/odoo#30774

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Include cristinamartinrod in CLA of Tecnativa

Needed for odoo/odoo#30774

When creating a cart on the website, the website company was not
considered which could end up with the selection of a fiscal position
linked to a wrong company since the method is called in sudo.

closes odoo/odoo#31673

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

This widget does not exist anymore since the merge between the all widgets
(new view refactoring).

closes odoo/odoo#31643

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Before 11.0 the kanban view used to have its own widget registry. It is not the
case anymore, but there are still leftovers from the past. For example, the
widget `kanban_label_selection` is still used in many views, even though it is
now called `label_selection`.

As we are in a stable version, a fallback has been added for it in the field
registry.

Similar to odoo/odoo@5401c15

Closes odoo/odoo#30904
Closes odoo/odoo#25928

To avoid exception:
  TypeError: Mixing apples and oranges: gamification.badge() - gamification.badge.user(1,)

when rule_auth of a badge is set to `having`.

opw-1945440
closes #31436
closes #31595

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Issue introduced in commit : 7c63f39db086f68fdce5b7d97bdcded74c125178

opw-1947735

closes odoo/odoo#31600

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

This commit introduced a regression in web_studio, discovered at opw-1947380

A fix in web_studio will be integrated too but the regression is the proof this
commit should not have been integrated in 11.0.
While the new behaviour introduced at d855e391 makes more sense, it is still
a change of behaviour that should not target a stable version.

For the problem raised at opw-1887162 that d855e391 was trying to fix, a
workaround should be used instead.
For instance, setting a widget='html_frame' allows to translate in the website
editor that handles this correctly.

In master, the new behaviour can be maintained and eventual regressions will be
investigated there.

closes odoo/odoo#31585

Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>

Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.

The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again

The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view

... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).

Sources:
https://www.service-public.fr/professionnels-entreprises/vosdroits/F23570
http://www.douane.gouv.fr/articles/a11024-tva-dans-les-dom



This commit allows a Dom-Tom based company to export the FEC file out
without needing to have a normalized French TVA set on the company

OPW 1946623

closes odoo/odoo#31543

Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>

It seems that our beloved administration is not happy with the FEC file
ending with an empty new line

Hence, this commit makes the FEC file last line end without \r\n characters
and there is no empty new line

OPW 1943302