Combining a list of elements containing only the monoid's unit should return the
unit.
Since the unit is skipped, it would return an empty domain instead of the unit,
meaning that (0, '=', 1) could not be used in a group rule.
To test this, create a record rule on a model M with domain (0, '=', 1)
that applies to group G.
Log in with a user in group G and access model M; you can read everything
(provided no other record rule applies) whereas you should see nothing.
Because of expression.AND(global_domains + [expression.OR(group_domains)])
we want the empty domain to still be left untouched, even if it violates
the OR's unit rules (i.e. OR(empty, OR(R)) = OR(R) <=> OR(empty) = unit).
Meaning that no group rule would reduce to having a (0, '=' 1) group rule.
So in the end we don't really care about all that algebraic nonsense.
closesodoo/odoo#28765
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.
The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().
See tests for a clearer view of the use cases.
Fixes#30113, #26540closesodoo/odoo#31202
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Before this rev:
* Take 2 domains that contain at least two leaves, and at least one of
them must use the implicit `&` operator
e.g.:
d1 = [('so_line', 'in', [91]), ('amount', '<=', 0.0)]
d2 = ['&', ('so_line', 'in', []), ('project_id', '!=', False)]
* Perform osv.expression.OR() between both domains
Expected result:
d3 = ['|', d1, d2]
Actual result (after normalization):
d3 = ['&', '|', d1, d2]
This is because, since the `&` is implicit for the first domain, when we
OR it, we give it an explicit `|` operator, so when we pass this domain
through the normalize_domain function, d1 no longer contains an implicit
`&` operator but instead the implicit operator is the one between d1 and
d2, therefore giving us a completely wrong domain.
The `combine` function states that it only accepts normalized domains,
however neither the OR nor AND functions do, this leads to a lot of
developers putting non-normalized domains into these functions, and
there's no error checking or anything that obviously indicates that the
domain is incorrect, so we might as well normalize all domains being
passed since it's already pretty optimized.
This replaces the former modified preorder tree traversal (MPTT) with the
fields `parent_left`/`parent_right`. Each record is associated to a string
`parent_path`, that represents the path from its root node to itself. The path
is made of the node ids suffixed with a slash:
a node | id | parent_path
/ \ a | 42 | 42/
... b b | 63 | 42/63/
/ \ c | 84 | 42/63/84/
c d d | 85 | 42/63/85/
This field provides an efficient implementation for parent_of/child_of queries:
the nodes in the subtree of record are the ones where `parent_path` starts with
the `parent_path` of record. It is also more efficient to maintain than the
MPTT fields, and less sensitive to concurrent updates, because the value of
`parent_path` does not depend on sibling nodes.
This commit introduces a new way to hide a column in a x2m list view.
The attribute 'tree_invisible' can be add in the field attrs in the x2m
view definition. This attribute can use the 'parent' key to make a reference
to the parent record (e.g. 'parent.id').
Make it easier to take advantage of subqueries whenever possible.
Also remove some weird semantics of the operator `not in`: searching with the
domain `[(F, 'not in', [])]` was returning the records with relations, instead
of all the records. The new semantics makes `[(F, 'not in', ids)]` equivalent
to the complement of `[(F, 'in', ids)]` in all cases.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Otherwise when the subquery is somehow injected in the parent
query (didn't find where but...) it's b-prefixed and treated as a
binary rather than a sub-query somehow, which fails.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* cross-version metaclass spec
* more formally deprecate browse_record and browse_null since they
were using metaclasses anyway
* update docstrings referencing the latter
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
Christophe Simonis