If any missing or partially incorrect values cause
an exception other than a psycopg2 error, we should
still catch it, rollback that record and report
the error, rather than letting bubble and fail
without any feedback to the user.
Fixes#1485
When a record is created, the magic fields (id, create_date,...) are first removed from the vals as the user should not set a value for these.
However if a value for this is given in default value (e.g. defined in an ir.value), the creation would crash (sql error : column specified more than once) as the magic column would be added again.
These parameters are (or should be) irrelevant for
a search_count(), and they could actually break the
result or make it significantly slower (e.g applying
`order` on large tables).
This fixes a performance regression introduced by
0f43032b.
We could also raise an error offset/limit are
passed in combination with count, but that seems
unnecessary.
Also switched to "SELECT count(1)" for the count
query, as it is simpler and just as fast.
We'd get the same perf with * or any constant value,
as in "SELECT count('me in')", but let's keep it
simple ;-)
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.
This was added in master-apiculture at f1f16a8 to
permit special function fields that return
structured JSON-like data.
This is unnecessary and caused typing problems, for
example for the type field of ir.model.fields, or
when you decide to store them.
It is simpler to explicitly declare these fields
as fields.Char and have them serialize their results
to JSON strings, or to declate them as fields.Binary
and return any opaque data they want.
element.{text,tail} are either ascii-compatible `str`, or `unicode`
when non-ascii-compatible. This could force the implicit decoding
of utf-8 encoded contents when joining template bits, breaking
the rendering.
Fixes#1085, and related to #1130
An ir.value without condition should not match when searching with a condition.
When a field with change_default on it is modified, the method get_defaults is called with the new value. This means that manually modifying a field with this trigger would put back the default value (opw 611193).
The goal is to avoid any kind of prefetching
of other fields when copmuting the default
company, as this will sometimes happen in the
middle of a database update, when the default
company is used for setting the default value
of new columns. In that case the db schema
may not fully match the in-memory model, leading
to an SQL error.
- 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;
replace ormcache_context by ormcache: use the context in the cache key is useless
set skiparg=3 (default skiparg=2) so the uid is not used in the cache key: the filestore path is the same for all database users
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.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Loading the menus is the most expensive
operation for an average page load, and
the result does not change often.
The menu filtering already uses a separate
cache based on groups, but the rest of the
loading includes reading actions and
translating menu names, which is also
expensive.
Added a cache keyed on user + user
lang, plus relevant cache invalidation
when any of the following are touched:
access rights, user data including
groups and language, menus or mail.group
subscriptions.
The menu filtering cache is still
useful in parallel has it is invalidated
under different conditions.
User.has_group() is cheap but still
called very often, so it is an easy
win as well, and also frequently
used when rendering page templates.
Raphael Collet
Olivier Dony
Martin Trigaux
dhr-odoo
Christophe Simonis
Christophe Combelles
xmo-odoo
Denis Ledoux
Mathieu Benoit
Richard Mathot
sebalix
rlu-odoo