Consider fields G1 and G2 being computed fields with inverse methods that
require the value of a common dependency F, which is also a computed field.
For inversing G1 and G2, their values are put in cache, then their inverse
method is called. If the inverse method of G1 requires the computation of F,
setting F's value will invalidate both G1 and G2 in cache. Hence the value of
G2 is lost when invoking its inverse method!
The fix consists in marking G1 and G2 as being computed before invoking their
inverse method, which prevents them from being invalidated by field F.
Setting NOT NULL constraints on required fields may fail if there are
any row with unset value for this column.
The ORM handle this case by catching the exception raised and warning
user.
However, not commiting the current transaction before, will rollback
changes made before like setting default values or renaming a column.
When recomputing stored function fields, the `write` may trigger a
cache invalidation which lead to a recompute of all the recordset
values, even the ones already saved in database.
This fixes the case where the lines of a one2many field are modified several
times by onchange methods: instead of retrieving the most recent updates, we
merge them with former updates.
This solution was written as an improvement of a proposal made by Alexis
Delattre and Sébastien Beau as #11620.
When writting a value on a translatable field in a different language than
English, the submitted *raw* value was saved in the database.
This could cause the following issues:
- empty value (provided as `False` by the web client) saved as the string
'false' in the translations table
- no encoding or sanitization convertion
- ignore size parameter on the translatable field
Process the submitted translation through symbol_set method to clean it before
storing it blindly in the database.
This allows to convert `False` into `''` for empty value and fixes#10862
Related and function manual fields may not be loadable during initial
setup (partial=True) due to dependencies being not loaded. Ignore
theses fields during partial loading.
Upgrading a module in the presence of computed custom fields can fail, if a
computed custom field depends on another field from a module that is not loaded
yet. The patch simply prevents custom fields with dependencies from being
loaded in partial mode.
In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
In the case of a `raw_data` export, a boolean which has the value
`False` will not be exported correctly.
The fix handles the `False` value as a valid value for a field.
opw-666142
When generating SQL queries, `column._symbol_c` must be used as placeholder as
for the method 'set' of the column itself. Otherwise it is not possible to
define specialized columns.
When writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids. The fix simply
eliminates duplicates from ids.
When a model list is ordered on a translatable field,
a join on the `ir_translation` is done, so the order
is correctly done on the translation value rather
than the translation source (in English).
This join wasn't entirely correct: If there were
multiple translations for a same record field
(which should not happen, but which is not forbidden)
e.g. Two different translations for the name of a same product,
then this record appeared several times in the result of the query,
while this is expected to only have each record once
(Obviously, when you perform a search on products, you do not expect
to have multiple times the same products returned by the search query)
This had as side-effect, when searching records with a limit of 80
items, to return actually less than 80 items
(e.g. 72 products, with multiple translations),
and, as the limit of the search was not reached (e.g. 72 instead of 80),
the web client did not perform the `search_count`, as it does not do
it when the limit of the search is not reached (meaning there is no
more items than what has been returned by the search query), and therefore
the web client did not consider there was actually more results, more
pages of results.
In summary, the count of records of a model could be different
when performing the order on a translatable field from one
language to another.
(e.g. A database could return 150 products in English, but
only 72 in Spanish).
To solve this issue, we have required the use of the operator
`DISTINCT ON`, which provides the possibility to keep only
the first translation for each record according to a given
order (in this case, we keep the translation that has been
added the most recently)
From the PostgreSQL documentation:
DISTINCT ON ( expression [, ...] ) keeps only the first row
of each set of rows where the given expressions evaluate to equal.
The DISTINCT ON expressions are interpreted
using the same rules as for ORDER BY (see above).
Note that the "first row" of each set is unpredictable
unless ORDER BY is used to ensure that the desired row appears first
The performance of this new query is similar to the performance
of the former query.
opw-666071
This reverts commit 882bbf46e2.
This revision leads to a crash when creating a new user:
Traceback (most recent call last):
File "/home/dle/odoo/9/openerp/http.py", line 643, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/home/dle/odoo/9/openerp/http.py", line 680, in dispatch
result = self._call_function(**self.params)
File "/home/dle/odoo/9/openerp/http.py", line 316, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/home/dle/odoo/9/openerp/service/model.py", line 118, in wrapper
return f(dbname, *args, **kwargs)
File "/home/dle/odoo/9/openerp/http.py", line 309, in checked_call
result = self.endpoint(*a, **kw)
File "/home/dle/odoo/9/openerp/http.py", line 959, in __call__
return self.method(*args, **kw)
File "/home/dle/odoo/9/openerp/http.py", line 509, in response_wrap
response = f(*args, **kw)
File "/home/dle/odoo/enterprise-9/web/controllers/main.py", line 907, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/dle/odoo/enterprise-9/web/controllers/main.py", line 899, in _call_kw
return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
File "/home/dle/odoo/9/openerp/api.py", line 238, in wrapper
return old_api(self, *args, **kwargs)
File "/home/dle/odoo/9/openerp/api.py", line 369, in old_api
result = method(recs, *args, **kwargs)
File "/home/dle/odoo/9/openerp/models.py", line 5998, in onchange
record.mapped(name)
File "/home/dle/odoo/9/openerp/models.py", line 5497, in mapped
recs = recs._mapped_func(operator.itemgetter(name))
File "/home/dle/odoo/9/openerp/models.py", line 5477, in _mapped_func
vals = [func(rec) for rec in self]
File "/home/dle/odoo/9/openerp/models.py", line 5715, in __getitem__
return self._fields[key].__get__(self, type(self))
KeyError: u'in_group_18'
user_has_groups is used to check for groups in e.g. view attributes (`@groups`).
When trying to format lists of groups in views, it would break down as it would
pass e.g. `\n some.group` to `res.users.has_group`, which would look for
an xid with the module `\n some` and (oddly enough) not find it.
Theoretically could also handle that inside res.users.has_group but it seems
ever-so-slightly more risky, and has_group is only used programmatically and
should thus already be called correctly.
fixes#9797
When creating translations (click on blue flag) of a duplicated record, it used
to have the module information of the duplicated record.
It is also not useful to check the module when trying to find if a translation
exists on this record as the res_id is present in the query.
Fixes#9480
Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs. Both function have the same API:
upgrade(self, value, *args, **kwargs)
downgrade(self, value, *args, **kwargs)
The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.
Fixes#4944, #7830.
Fixes regression introduced at 4d9e36a459
that caused all custom (manual) models to be reset to "base" models.
This prevented the creation and proper use of custom models.
opw-657017
Closes#9670
Partial version of #9663
Martin Trigaux