Odoo/odoo/addons/base/tests, branch 14.0

[FIX] core: fix filtered_domain for hierarchical terms

2021-05-25T16:15:33+00:00

The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').

To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:

    assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])

The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404
fails, therefore the result of `filtered_domain` is empty.

Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.

Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`.  Then

    b1.filtered_domain([("friend_id", "child_of", b1.id)])

throws an exception of the form shown below:

    ValueError: Invalid field 'parent_id' in leaf "

[IMP] mail: allow to force the FROM headers of the outgoing mail server

2021-05-17T11:14:53+00:00

Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.

Specifications
==============
This is done with 2 system parameters.

If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.

If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.

Otherwise we do not encapsulate the email (same behavior as before this
commit).

Task 2367946
See odoo/odoo/pull/61853

closes odoo/odoo#70854

X-original-commit: 044532aed6f796cd93e37556b4a8ce47d2c23a7c
Signed-off-by: Thibault Delavallee (tde) 
Signed-off-by: Olivier Dony (odo)

[IMP] various: update query counters according to latest runbot run

2021-05-06T15:29:12+00:00

Base: seems related fields take only 1 extra query instead of 3

Crm: assignment seems to have been slightly improved. Some randomness still
happens.

Hr Holidays: seems it was further improved beyond space frontier

Test mail: those tests were a bit random, seems random is gone (hopefully)

Test mail full: updated local counters

Test mass mailing: seems we gained one query, updated local counters

closes odoo/odoo#70486

Related: odoo/enterprise#18180
Signed-off-by: Thibault Delavallee (tde)

[FIX] base_vat: Don't always pass VAT check when validating the VAT of a partner without country_id

2021-04-02T09:45:24+00:00

Before this, when making a partner without any country_id, any VAT could be set to it, which was inconsistent with the module's purpose.

closes odoo/odoo#68492

X-original-commit: 4c962437bd59a1e9302d8034e8870880994eb713
Related: odoo/enterprise#17358
Signed-off-by: Cedric Snauwaert (csn) 
Signed-off-by: oco-odoo

[FIX] core/expression: fix distribute_not over thruty leafs

2021-04-01T15:30:21+00:00

A domain with a negated thruty leaf raises an exception here
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L614
due to
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L670
and the fact that `FALSE_LEAF != (1, "!=", 1)` and `TRUE_LEAF != (0, "!=", 1)`

Current wrong behaviour:
```
>>> distribute_not(['!', TRUE_LEAF])
[(1, '!=', 1)]
>>> is_leaf((1, '!=', 1))
False
```

This issue was noticed when adapting domains for fields that have been
removed during migration. Example (extract of) traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/13.0/odoo/http.py", line 624, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  ...
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 677, in __init__
    self.parse()
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in parse
    self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in 
    self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 562, in __init__
    self.check_leaf(internal)
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 618, in check_leaf
    raise ValueError("Invalid leaf %s" % str(self.leaf))
ValueError: Invalid leaf (0, '!=', 1)
```

closes odoo/odoo#68657

X-original-commit: e20c23658d15a135e5f35b0e8dec6e3202cecaab
Signed-off-by: Christophe Simonis

[IMP] base: improve qweb barcode widget

2021-03-29T06:27:14+00:00

When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.

Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.

With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.

e.g.: `'img_alt': 'Barcode'` will result in `

[FIX] base: make the tests of sorted ir.filters work

2021-03-17T11:56:10+00:00

Before this commit ir_filter tests were calling model.search() with an
array as order. It was not a problem because none of the tested filters
was actually using the sort and the falsy empty array was therefore
ignored by model.search().

After this commit ir_filter test calls model.search() with a string as
order.

task-2453416
See https://github.com/odoo/odoo/pull/65554

closes odoo/odoo#68012

Signed-off-by: Xavier Dollé (xdo)

[FIX] base: tools: float_split_str: avoid traceback when rounding to 0 places and add some test cases

2021-03-16T13:21:42+00:00

closes odoo/odoo#67949

X-original-commit: 42d409f180381316c97abd0c0ef5a062656e6122
Signed-off-by: Olivier Dony (odo) 
Signed-off-by: oco-odoo

[FIX] base: reset _rec_name if x_name field is deleted

2021-03-15T07:04:39+00:00

Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:

    - Install studio
    - Create an app (create a new custom model M)
    - Uninstall studio
    -> Uninstall fails because field display_name of the custom model M
    depends on field M.x_name which has been removed due to the
    uninstall process.

To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:

    - We trigger the uninstall of studio, this triggers the uninstall of
    any modules that depend on it, namely studio_customizations which is
    the module in which all customizations done with studio live in.

    - We gather all data belonging to the studio_customization and we
    start deleting in the following order: ...,
    ir.model.fields.selection, ir.model.fields, ..., ir.model

    - During the unlink process, we first remove the actual fields from
    the model instances before deleting their database reflections, this
    is done in the ir.model.fields._drop_column() method, it is this
    method that will delete the x_name field but **not** the
    display_name field, since it is a base field and not a custom one.

    - After the deletion of the fields in memory, we call modified() to
    mark fields that might've depended on the fields we just modified so
    that they can be recomputed later.

    - The call to modified will in turn access field_triggers, but since
    we're in a new registry and field_triggers is a lazy property, it
    will be computed right at this moment, this means that it will call
    resolve_depends on the display_name field which still exists, and
    this field has a dependency on the x_name field that we just
    deleted! This is what will trigger the crash.

With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:

    - Before the aforementioned commit, the field_triggers attribute was
    computed during the registry's setup_models(), in the case of an
    uninstall this call to setup_models was done way before the
    uninstall step of the registry (Step 3 is the last to call
    setup_models before Step 5).

    - This means that the old behavior was technically a bug, because
    right after removing x_name from the model, the field_triggers still
    contained a dependency from display_name to x_name, the former being
    no-longer present in memory.

With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.

opw-2452498
opw-2478589

closes odoo/odoo#67747

Signed-off-by: Adrian Torres (adt) 
Co-authored-by: Raphael Collet

[FIX] tools: prevent call to pillow exif_transpose image method

2021-02-09T11:32:23+00:00

In a previous fix [0], the call to exif_transpose was kept to allow
rotation of images format different than `JPEG`.

After a small test, it appeared that the call would crash if the image
in another format had the same `LensInfo` tag.
So it's safer to not call this method at all.

With this commit, the rotation tag is retrieved disregarding the file
format by using the `getexif` method if available, falling back to the
private method for Pillow < 6 support.

As a bonus, a test is also added with a small embedded `JPEG` image,
crafted with an `Orientation` exif tag and, for reference,  the
`LensInfo`tag that caused so much trouble.

The fix referenced in [0] was not forward-ported as it was only moving
the code the is completely removed in the present.

[0] b83c48d5c48954193

closes odoo/odoo#65793

X-original-commit: 38f696dfa5134d93b5a3a1c0647aa8f8c1bd18c9
Signed-off-by: Christophe Monniez (moc)