When doing a group_by in a tree view, and then ordering by an
aggregated field which contains at least one capital letter in its name,
you will get an error and won't be able to ordery by this field.
Why? read_group is called when sorting a group by, which calls
_read_group_raw which then goes to call _read_group_prepare, which will
return order by terms in this manner ['id asc', 'x_Test desc']
the problem with this is that postgres automatically converts
non-quoted/non-qualified column name to lowercase, of course this means
that if we have a field "x_Test" but no field "x_test", it will try to
look up "x_test" instead of "x_Test" and since the column doesn't exist,
it will throw a ProgrammingError.
This commit changes this behavior by wrapping the order_by terms generated in
_read_group_prepare with double quotes, which postgres interprets
correctly.
Fixes#21348
Cherry-Pick of c338e24ee7 as previous
forward-port has been badly done...
Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
Otherwise if a record rule is defined on a x2many field on the model, the creation will fail because
ir.translation creation check access rules on the model and in this case, the x2many relation are
not set yet.
In case of foreign language, using unicode characters, the error message may be
badly formated.
e.g.
Unknown error during import: <class 'odoo.exceptions.AccessError'>: เฉพาะผู้ดูแลร..
insted of
Unknown error during import: <class 'odoo.exceptions.AccessError'>: (u'\u0e40\u0e09\u0e1e\u0e32\u0e30\u0e1c\u0e39
opw-766580
When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
When a model contains a field translatable which has a unique
constrain, it is impossible to copy a record. Indeed, the unicity
constrain is always triggered, even if the model takes in charge the
overriding of the copy method to avoid duplication.
Introduced with commit ce7f31b0b0, with the goal to target only
XML/HTML translations. We apply this behavior in case of a callable
translate property, to target only the desired problematic use case.
opw-749481
Issue: when using `copy` in a given lang, the value of XML/HTML fields is
copied in its translated form, making existing translations useless. Fix the
value of such fields by storing their original value instead.
This fixes the following issue. Assume a custom field F is created on
`res.partner`. This field will appear on `res.users` as an inherited field,
and will be reflected in `ir.model.fields` as a 'base' field. When F is
removed from the parent model, it no longer appears on the child model in
registry, but remains in `ir.model.fields`.
The patch allows the proper removal of the no-longer-inherited field from
`ir.model.fields`.
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
When copying a record in an other language L than US, first a translation
was created for L by the create called in the copy function and afterwards,
a second translation was created by the function copy_translations
So there were two duplicated translations for L instead of one.
opw:706865
`model` field of `ir.model` may be used as related stored field.
Marking it as modified force recomputation of these, even no change
occurs (by definition).
The dictionary `_group_by_full` is replaced by a field parameter `group_expand`
that is assigned to the method name. The API of the method has been simplified
as well:
@api.multi
def _read_group_stage_ids(self, domain, read_group_order=None, access_rights_uid=None):
# the stages are given by self.ids (wrong model);
# read_group_order is the order given to read_group() on self;
# return stages.name_get(), {stage.id: stage.fold)
_group_by_full = {'stage_id': _read_group_stage_ids}
is now written:
stage_id = fields.Many2one(..., group_expand='_read_group_stage_ids')
@api.model
def _read_group_stage_ids(self, stages, domain, order):
# stages is a recordset;
# order is the order to use on stages' model;
# return a recordset which is a superset of stages
RecordSets were not preserving order when combined
with AND/OR set operators. Order was lost as well
through mapped().
This caused various recurring "heisenbugs" during
tests executions on runbot, specifically comming
in the test of stock_landed_costs.
Using OrderedSets instead of basic Sets to resolve
these operation avoids the indetermination.
This required an implementation of __or__ / __and__
for OrderedSet.
Adrian Torres