When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
close#9925
In the `product.template` model,
when searching products within a category that doesn't exist,
all products were returned, while none should be returned.
For instance,
In Sales > Products,
In the search input, search with internal category:
"A category that doesn't exist",
all products were returned.
opw-649548
The current code when applying negative operator on an expression used
recursion which in extreme case is not best friend with python.
e.g: on instance with a lot of wharehouse, some simple action could lead
to a domain with lot of elements which could easiliy go over the python
maximum recursion limit.
This commit fixes this by replacing recursion with iteration.
We have a stack of negation flags and loop on each token of the domain
as follow :
- when we iterate on a leaf, it consumes the top negation flag,
- after a '!' operator, the top token negation is inversed,
- after an '&' or '|' operator, the top negation flag is duplicated on
the top of the stack.
closes#9433
opw-653802
Postgresql has a limit of 64 characters for tables, columns names
as well as for aliases names.
When generating an alias name, e.g. for group by and order
by clauses, if the alias is longer than 64 characters,
use hashing to force the alias length to be within this
64 chars limit.
Fixes#8094Closes#8142
Consider the following setting:
- on model A, field F is computed, stored, and depends on field G
- on model A, field one2many G to model B, with inverse field H
- on model B, field many2one H is inherited (_inherits) from model C
- on model C, field many2one H is stored
When adding records of model B, the field F must be recomputed. In order to
determine which records to recompute, one searches model A with a domain like
[(G, 'in', ids)]. In expression.py, this is resolved with an SQL query like
select H from B where id in {ids}
This query fails, since the field H is not stored in model B. This happens in
general if H is not stored (it may be any computed field). In that case, one
should instead browse records from B, and read field H through the ORM.
A test case has been added: it introduces a many2one field in a parent model,
and a one2many field using the inherited many2one on a child model. The test
checks whether one can search on the one2many field.
When setting a custom filter with as domain
[(0, '=', 1)]
the domain was rejected, because (0, '=', 1) wasn't
considered as a valid leaf, while it is.
This is because the Javascript converts this domain
using list instead of tuple
[(0, '=', 1)] -> [[0, '=', 1]]
And therefore, comparing the "list" leaf
to the TRUE/FALSE leaf tuple failed.
Ensuring "element" as a tuple solves the issue.
opw-640306
These revs. introduced an API change in the _name_search method.
Indeed, the 'operator' attribute used to have 'ilike' as default value.
This cannot be changed, as every modules overriding this method
overrided it using the signature with operator='ilike'
For instance, _name_search method of addons/base/ir/ir_model.py
expects having 'ilike' as operator.
As it was not anymore the case,
it leaded to a crash when performing a name_search call on the model ir.model,
like when adding a new custom field to a model, from the web client.
opw-626161
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Clarify the semantics of field attributes:
- field.store is True when the field is actually stored in the database;
- field.column is the column corresponding to field or None.
The various field definitions correspond to:
- new-style stored field: field.store and field.column
- new-style non-stored field: not field.store and not field.column
- old-style regular field: field.store and field.column
- old-style function field: not field.store and field.column
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
This comparison is flawed by nature but can be a useful
shortcut sometimes. It was using wrong boundaries and
would also loop for operators not explicitly handled
by the code (there was no `else` block). It is still
not possible to handle time zone conversions properly,
so this is only an experimental feature.
bzr revid: odo@openerp.com-20140404133827-5owdendpsr083a17
Jeremy Kersten
Denis Ledoux
Raphael Collet
Thomas Rehn
Olivier Dony
Christophe Simonis
Samus CTO
Mohammed Shekha
Christophe Simonis
jba
Martin Trigaux
Denis Ledoux
Quentin (OpenERP)
Thibault Delavallée
Vo Minh Thu