When a product is a kit and a discount is applied thanks to a pricelist,
the discount is counted twice if the invoice is created from the stock
picking.

This is because the pricelist will modify the price unit, but moreover
the discount will be applied a second time by the method
`_compute_price` of the account move line.

opw-676838

Our usage of domain on fields One2many seems to trigger an obscure behaviour on
onchange.

With the following (simplified) config:

    Message(models.Model):
        _name = 'test_new_api.message'
        important = fields.Boolean('Important')

    Discussion(models.Model):
        _name = 'test_new_api.discussion'
        name = fields.Char('Name')
        important_emails = fields.One2Many('test_new_api.emailmessage', 'discussion',
                                           domain=[('important', '=', True)])

    Email(models.Model):
        _name = 'test_new_api.emailmessage'
        _inherits = {'test_new_api.message': 'message'}

        discussion = fields.Many2one('test_new_api.discussion', 'Discussion')
        message = fields.Many2one('test_new_api.message', 'Message')

Steps:
- We change 'name' on discussion, triggers an `onchange()` call
- we ends up filling cache on virtual record (on secondary fields, we calling
  record.mapped('important_emails.important'))
- we get a cache miss ('important' field not provided, only 'important_emails' ids,
  i.e with no change on existing records)
- we fill the cache, this mark 'important' field as modified
- because of commit 5676d812 and because 'important' is that case is a related (i.e
  computed) field we triggers cache recomputation
- as there is no way to recompute 'important_emails' for virtual record (no real
  ID) we ends up with empty 'important_emails' generating removal of existing records.

=> Finally changing any value for 'test_new_api.discussion' that trigger an onchange
will always reset 'important_emails' to empty

Fixed by Raphael Collet <rco@odoo.com>, and test by Xavier Alt <xal@odoo.com>.

Do not redefine the view arch but do a proper inherit.
It was a problem as the redefinition removed some fields (headers,..).
It was also a problem if crm_profiling was uninstalled as the redefinition was
not removed.

Closes #12454

[FIX] account: on ir_sequence, number_next_actual must always be read instead of number_next which might contain wrong value in case of 'standard' sequence. This was causing a crash on creating a new invoice, if demo data were installed and the user went to settings\accounting to do some modification. Issue #12471

The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.

Courtesy of Luc De Meyer. Was PR #10551

If I need to do researchs to find a quotation, the goal of having a userfriendly
software may be missed.

The word 'Research' isn't usually used in this context.  'Searching' is better.
Closes #11517

Closes #12463

Closes #12467

The `related_usage` field of `purchase.order`
is a related field to the location `usage` field,
which is defined in order to display/hide
some other field in the PO according to the location usage

This is purely a technical field, which is set only
to change the form view according to the location
usage.

This is not expected to change the location usage
through this field, this field must therefore
be set to readonly.

A change on the location usage could happen because
of the `onchange_picking_type_id`:
If the user changed the picking type, and then the location,
the usage returned by the `onchange_picking_type_id` was
applied on the location, and this must not have happened.

In addition, since `related_usage` is a related to the location
usage, it should be changed as well when the location is changed.
(in the new api, this is no longer required, the related field
is updated automatically).

This revision therefore adds an onchange on the location as well,
to handle this.

opw-676428

Do not force to use "<name> (copy)" when duplicating

Closes #12397

[FIX] anonymization: default anonymization fields

res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists

Closes #11806

[FIX] anonymization: allow anonymization on HTML fields

Was missing in the (old) list of fields

[CLA] Sign CLA of leblanc-simon

Done at #11806

In case of local_redirect with
* forward_debug=False
* qwery={'debug': True}

the debug mode should be removed.

cf discusion on #12107 and dd4980b0

Partial backport of ef198302. The error message cannot be included for
compatibility reason, but the browser will highlight the field in red,
which should be enough to locate the error.

opw-677121

Fixing the error ValueError: "name 'date_from' is not defined"
while evaluating '[date_from, date_to, employee_id, contract_id]'

This commit close #12383, close #8883, close #3116

The parameter forward_debug is used to keep the debug mode during redirection.
Previous code was setting the debug to None which is ignored by werkzeug, making
the option useless.

Closes #12107

Previous commit 8f712921 searches recursively for children of a rule
category. Use `child_of` instead which is way more efficient.

opw-673222

When a rule category has children, the total of the category should
include the total of the children categories.

opw-673222

To match the behaviour on sale.order.line.
Purchase line form is expected to be open in popup (where parent is defined),
not individually when creating a line alone is not useful.

Fixes #6644
Closes #12325

Closes #12326

Otherwise inheritance is not properly propagated

Closes #12337

Closes #12347

* v5.2: Añadida retención 19,5% arrendamientos.
* v5.1: Renombrado todo lo relacionado con arrendamientos para no incluir la
  palabra "IRPF", ya que no es como tal IRPF.
* v5.0: Se ha rehecho toda la parte de impuestos para dar mayor facilidad de
  consulta de los datos para las declaraciones de la AEAT y para cubrir todas
  las casuísticas fiscales españolas actuales. Éstas son las características
  más destacadas:

  * Desdoblamiento de los impuestos principales para bienes y para servicios.
  * Nuevo árbol de códigos de impuestos orientado a cada modelo de la AEAT.
  * Nuevos códigos para los códigos de impuestos para facilitar su
    actualización.
  * La casilla del modelo viene ahora en la descripción, no en el código.
  * Posiciones fiscales ajustadas para el desdoblamiento.
  * Nuevo impuesto y posición fiscal para retención IRPF 19%.
  * Nuevo impuesto para revendedores con recargo de equivalencia.
  * Nuevas posiciones fiscales para retenciones de arrendamientos.
  * Pequeños ajustes en cuentas contables.

Closes #8453

When creating an SO line with a quotation template, the customer
lead time must be set.

opw:678039

Force the value tracking_disable to be make sure that the validation (which is
supposed to have no impact), will not send any email.

Fixes #3173

The hw_scanner module not only supports barcode readers (although that
was it's original intention). It also happens to support certain card
readers (like the MagTek Dynamag we use for Mercury) because they act
the same way as barcode scanners (like a keyboard and end sequence with
ENTER).

Before we supported Mercury there was no real reason to support multiple
devices on the POSBox, because it didn't make much sense to attach >1
barcode reader to the same POSBox. With Mercury however, this is a real
use case, as users want both a barcode reader and a card reader.

This commit implements support for this, while keeping the functionality
as close as possible to how it was before (eg. care was taken to not
break plug and play support).

When an invoice is created automatically thanks to the cron task, the
superuser is used. However, this implies that the company of the
superuser will be used for the account invoice creation, leading to
potentially incorrect taxes and fiscal positions.

opw-669714

The date was positioned inside the h1 and was badly rendered (field too small)
Fixes #2476

The test `test_balanced_exchanges_gain_loss`
failed on Jun 6, because it created a specific rate
for today's date at midnight
(e.g. on Jun 6, 201x-06-06 00:00:00) for the test purpose,
but a rate is created in the demo data for Jun 6 midnight exactly:
`base.rateUSDbis`, making the test confused about which rate
to use.

We solve this by making the test use the rate `base.rateUSDbis`,
modifying the rate for its own need, instead of creating a new
rate.

This is similar to revision 54140331

opw-673716

HTML content should be escaped before being sanitized. Any content (link, image,
code,...) that is acceptable in usual mail.message but should not be interprated
when posted on a comment of the forum.

Fixes #3737

If we take the below facts:
 - The country select is set as disabled
   when Shipping is set to "Ship to the same address"
 - The disable property of select inputs is
   removed when shipping is set to
   `create a new address`:
   In `website_sale.js`:
   ```
   $selects.attr("disabled", value <= 0 ? null : "disabled" ).prop("disabled", value <= 0 ? null : "disabled" );
   ```

We can safely assume that the select input "State / Province" was supposed
to be set as `disabled` in the first place, not as `readonly`

Before this revision, State / Provice was greyed when choosing
"Create a new address" for shipping, and selecting the United States
(but the select input was still usable, though, it was just greyed)

opw-675739