The setup of relational fields may be problematic, as they may refer to unknown
models via custom relational fields. In a partial setup, do not try to skip
the field setup, but let it go and silently catch any exception if it crashes.
In the case of custom fields, the field's parameters were set up without the
field being present in the class hierarchy. Because of this, the parameter
inheritance mechanism was missing the field itself. As a consequence, custom
selection fields ended up without selection, for instance :-/
The ISO week-year notation can produce confusing values
when the first week of the year is so short that it
becomes week 0 and is considered the last week of the
previous year, depending on the locale.
For instance, using ISO notation:
'W53 2015' == dates.format_date(
date(2015,1,1), format="'W'w YYYY", locale='en_GB')
'W53 2005' == dates.format_date(
date(2006,1,1), format="'W'w YYYY", locale='de_DE')
This is surprising but actually valid.
However it definitely yields wrong output when combined with
months formats:
'January 2014' == dates.format_date(
date(2015,1,1), format="MMMM YYYY", locale='en_GB')
As a result we must always use `y` to denote the year in
any date format, *except* when it is combined with the
week number `w`, in which case we must use `Y`.
See the documentation at:
http://babel.pocoo.org/docs/dates/#date-fields
Compute methods could give results that should not be considered as default
values. For instance, a related field usually defaults to a null value, which
is then set to the field with its inverse method by create(). This may violate
a non-null constraint if the original field is required. Therefore, compute
methods are no longer used to determine default values.
The method _prefetch_field() was accidentally prefetching fields to recompute;
which was skipping the actual recomputation, since a value was put in cache.
But sometimes the field's value was fixed by an extra recomputation of the
field. Here we remove the extra recomputation and fix the cache corruption.
An issue occurs when a constraint is checked before computed fields are marked
for recomputation: the constraint will read the field's current value, which
may be wrong. If the field is marked soon enough, the constraint will trigger
the recomputation and use a correct value.
Because of the parameter overriding mechanism implemented by fields, it is no
longer necessary to copy field objects. It is even better to no copy them in
the case of related fields.
This solves a subtle issue: in the following case, the class Bar should
override the default value set by Foo. But in practice it was not working,
because _defaults is looked up before field.default.
class Foo(models.Model):
_name = 'foo'
_columns = {
'foo': fields.char('Foo'),
}
_defaults = {
'foo': "Foo",
}
class Bar(models.Model):
_inherit = 'foo'
foo = fields.Char(default="Bar")
The change makes field.default and the model's _defaults consistent with each
other.
Consider the following example:
class Foo(models.Model):
_name = 'foo'
_columns = {
'state': fields.selection([('a', 'A')]),
}
class Bar(models.Model):
_inherit = 'foo'
state = fields.Selection(selection_add=[('b', 'B')])
The attribute 'column' of the field does not have the full selection list,
therefore the column object cannot not be reused, even a copy of it. The
solution is to systematically recreate the column from the field's final
specification, except for function fields that have no sensible way for being
recreated.
When processing data files during a module installation/upgrade, not all fields
are set up yet, in particular relational custom fields. Make fields_get()
ignore those fields, so that views can be created/updated and validated,
provided they do not refer to those fields...
Replace the query "SELECT min(id) FROM xxx" by "SELECT 1 FROM xxx LIMIT 1".
Both requests are as efficient, and the second one does not crash if column
'id' is missing.
The method was expecting that name_get() returns complete and in-order values.
Because of this, some records in the recordset could end up without a value.
The method onchange() executes onchange methods in cascade. Suppose onchange()
is called and a field F=1 in the form. If an onchange method set F=2, that
value is put in the result variable. If another onchange method set it back to
F=1, the binding F=2 must be removed from the result variable.
Fixes#2309
Cascading onchanges can be caused by a related field computed in cache. This
causes a bug in sale order lines, were setting the uom field forces reading
product fields, which are inherited from product templates. The inherited
fields are computed as related fields, which marks the product record as dirty.
This subsequently triggers an onchange on the product field, which resets the
uom field!
This fixes issue #2146. The inverse of a one2many field can be an inherited
field (_inherits). In that case, we cannot read its value with a simple
database query. Instead, we let the related field read it, but for performance
considerations we disable the prefetching of other fields.
Add an attribute 'related_sudo' (True by default) for related fields.
A related field is computed as superuser if related_sudo is True.
Add explicit related fields 'name' and 'email' on 'res.users', as these should
be readable by the public user with module website_forum.
This fixes a bug which is usually triggered in module account_followup, but
does not occur deterministically. Some recomputations of computed fields are
apparently missing. Environment objects containing recomputations todos and
kept alive by a WeakSet, are removed by the Python garbage collector before
recomputation takes place. We fix the bug by moving the recomputation todos in
a non-weakref'ed object.
The selection of records in cache for prefetching was moved to method
_read_from_database() by xmo at rev 785018cc in order to fix an access right
bug. But this introduced an issue: to explicitly avoid prefetching, you should
use read() instead of browsing records. We revert the change by xmo, without
reintroducing the bug (which apparently was fixed by another way).
When the context contains 'recompute': False, the recomputation was not even
prepared. Now both create() and write() prepare the recomputation by invoking
method modified(). The flag only controls whether method recompute() is invoked.
In addintion, the former flag 'no_store_function' was converted to the flag
'recompute', so that both create() and write() use the same flag.
Fixes#1456
At the end of _prefetch_field(), a check is made to ensure that the cache
contains something for the field to prefetch. The check was incorrect because
the cache was checked for a regular value only.
The result of _convert_to_write() is intended to be pass directly to
`write()` or returned to the client (`onchange()` and `default_get()`.
`NewId` is as special value that must not be stored into the database
or exposed to the client.
On one2many fields writing in an existing record (not when creating new record), the computed stored fields of the one2many were not re-computed correctly
Computed stored fields were marked as modified only if no_store_function was not set to True in the context. no_store_function is set when writing one2many records on an existing record.
Now, these computed stored fields are marked as to be recomputed, but are recomputed later, at the end of the existing record write
After commit f28be81, boolean columns may have more
NULL entries than before. In the (rare) cases where
a boolean column was used for an ORDER clause
(e.g. in the /shop page of website_sale), this
causes a change of the resulting ordering.
By coalescing NULL values to false in SQL,
we make the ordering consistent with what the
framework does for domain expressions with booleans,
and when reading boolean values, that is, NULL is
the same as False.
Boolean fields always default to False in 8.0,
even when they do not have explicit default values.
This causes extra queries in the form:
UPDATE <table> SET <bool_field> = false
WHERE <bool_field> IS NULL;
Those are not necessary as the ORM automatically
folds NULL booleans to False, and can be very
expensive on tables with several million rows,
as the whole table may sometimes need to be
rewritten (can take dozens of minutes)
Some many2one fields happen to have several corresponding one2many fields,
typically with different domains. It is also the case for the field 'res_id' of
mail.message, where each model inheriting from mail.thread defines a one2many
based on that field. The fix ensures that when a relational field is updated,
all its inverse fields are invalidated.
The default values are computed by evaluating fields on a new record. The fix
retrieves values from the cache earlier, because in some cases, the evaluation
of a field invalidates a formerly evaluated field.
management to access documents in notification emails, as well as for the
'view quotation' link in portal_sale module.
models: added a get_access_action method: basically, returns the action to
access a document. It uses the get_formview_action by default (form view
of the document). However for some documents we want to directly go to the
website, leading to an act_url action for some documents. This method allows
this behavior.
portal_sale: get_signup_url now uses the mail.action_mail_redirect method
instead of directly redirecting towards a portal menu. This allows to fall
back on a standard behavior.
portal_sale: get_formview_action updated, to match actions tailored for
portal users.
website_quote: get_access_action of sale order updated. If the sale order
has a template defined, the returned action is an act_url (website view
of the quotation), not the form action anymore.
mail: fixed signature + company signature in notification emails. Even without
user signature, the company signature + access link should be correct.
portal: signup url in notification emali was not using the mail redirection
as action. It is now the case.
Singleton object was required while access model properties, but search returns multiple results and hence caused traceback while accessing record.property
The existing code was buggy when writing on *2many fields with a list of
commands: the value was converted for the cache, but taking an empty recordset
as the current value of the field.
It is not useful to try to create foreign keys when the destination model is
a PostgreSQL view for example.
We already do this kind of verifications but ir.actions and transient models
but did not for _auto.
When a new record is returned as the value for a many2one on a new record, the
method Many2one.convert_to_write() now returns a NewID, and default_get() then
discards that value from its result. This makes it consistent with its former
behavior.
Manual rebase of #1547
Can be defined to False in any model to completely
disable translations for this model, when they are
irrelevant. This is useful e.g. for test classes
that use attributes that would normally be translatable.
- display_name uses name_get and not the other way around:
name_get should not call _compute_display_name, _compute_display_name should call name_get.
The previous behaviour was not backward-compatible with the old api.
All the models redefining name_get would have 2 different behaviors between name_get and display_name.
- Do not set an inverse function to display_name:
In most cases, writing on display_name writes on _rec_name (if any, not mandatory).
If the display_name computation is redefined, we need to redefine as well the inverse method to avoid unexpected behaviour
This required to also modify tests in base_import as readonly fields are avoided.
- Remove search method on display_name:
For the same reason as for the first point, it could be good that searching on display_name use name_search (and not the other way around).
However doing this would be very inefficiant (need to do the search, without limit, extract the ids of the name_get result just to generate
a subdomain ('id', 'in', [...]). As in most cases it would anyway mean to search on the _rec_name it's better to directly do so.
- Changing label to avoid mismatch:
In view displaying the list of fields or when a match is made on the label of a field (e.g. when importing csv file,
matching is made on both label and technical name), the fact that display_name field has '
Calling it 'Display Name' will avoid most errors.
- remove display_name definition from website_forum_doc,ir_model:
These fields are doing the same thing as the display_name of the new api, we can remove them.
We need to keep the one for res.partner as it's a stored field.
When computing defaults we may end up with
a falsy value that is not None (e.g. '' or False)
That value will be cast to None when being
saved in the database, depending on the column type
(e.g. saving False on a many2one actually stores NULL).
Improve the test to consider the value being written
*after* that conversion, to *really* avoid nonsensical
and expensive queries such as:
UPDATE table set col = NULL WHERE col IS NULL;
In the previous implementation of the new API fields,
both fields.Selection and fields.Reference were performing
early validation of their `value` as soon as it entered
the cache, either by being read, written, or computed.
This is a source of trouble and performance problems,
and is unnecessary, as we should consider that the database
always contains valid values. If that is not the case it
means it was modified externally and is an exception that
should be handled externally as well.
Revalidating selection/reference values can be expensive
when the domain of values is dynamic and requires extra
database queries, with extra access rights control, etc.
This patch adds a `validate` parameter to `convert_to_cache`,
allowing to turn off the re-validation on demand. The ORM
will turn off validation whenever the value being converted
is supposed to be already validated, such as when reading it
from the database.
The parameter is currently ignored by all other fields,
and defaults to True so validation is performed in all other
caes.
16d6744 turns out to not be great, because it filters out the todos for
prefetched fields (rather than those just for the field being asked) there are
situations where it ends up not fetching the records it was originally asked
for and breaks a bunch of stuff e.g. unreconcile line in bank statements
Force the ids explicitly asked for back in the fetched set, so that the
prefetch is at most a noop, rco will have to take an actual look at it.
A todo would only filter out records selectioned by the same field's caching,
it should filter out on the whole prefetching selection or an other field
could/would just add it back to the set of records to fetch (and lead to Bad
Things).
Note: this probably deserves a test somehow, but I'm not quite sure how the
todos thing works so...
If expansion of the recordset is done during _prefetch_field, if one of the
prefetches (not the base record(s) but one of those selected by
BaseModel._in_cache_without) can't be read by the current user (due to an
access rule or for field reading reasons, or whatever) the whole read is
failed, even if the record which was specifically asked for could be read on
its own.
By only expanding the read set in _read_from_database, the cache is correctly
set but read() and _prefetch_field() only check the records explicitly asked
for for AccessDenied, prefetched records will only be asked if they are ever
accessed.
fixes#1013
This should fix an issue discovered by tde when reading all fields on a record
on which you don't have access right:
- _read_from_database() fetches result and store it in cache
- read() retrieves values from cache, starting with field 'create_date'...
- ... which is not in cache, so prefetch that field, read it, which goes into
an infinite loop
The problem is that _read_from_database() finds out that you don't have access
on the record, and stores a FailedValue in cache on all fields... except magic
fields. Fix the problem by storing the FailedValue on all fields but 'id'.
* Either further operations don't really care (e.g. ``str.join`` takes any
iterable)
* Or they do their own seq (``browse`` calls ``tuple()`` on iterable params)
Fixes#966
* As a preallocation optimization, ``list()`` calls ``__len__`` on its
parameter if it's available
* Before Python 2.7.4, WeakSet has a bug[0] where ``len()`` is unsafe: it is
done by iteration and weakrefs may be removed from the underlying set during
the iteration
As a result, the safety feature of listifying a WeakSet to ensure we have
strong refs on all items during iteration may blow up.
Wrapping the weakset in a ``iter()`` makes ``__len__()`` invisible and ensures
we're within the IterationGuard[1].
Which now that I think about it means we *should* be able to safely iterate
weaksets in the first place and may not have needed to listify them...
[0] http://bugs.python.org/issue14159
[1] http://hg.python.org/cpython/file/b6acfbe2bdbe/Lib/_weakrefset.py#l58
Likely caused by a type incoherence e.g. providing an id as string when the
table uses integer ids. Postgres performs an implicit conversion from string
to integer[0], this wasn't much of an issue in the old API, whatever cache was
there would simply not be used, but because the new API's cache is part of its
behavior it has a semantic impact and can lead to infinite recursion.
[0] more precisely from quoted value, which is untyped
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
Raphael Collet
Olivier Dony
Denis Ledoux
Christophe Simonis
Samus CTO
Richard Mathot
Thibault Delavallée
Mohammed Shekha
Martin Trigaux
Christophe Matthieu
Xavier Morel
xmo-odoo