As its documentation notes[0], Jinja2 only processes unicode template
data (or pure ASCII, which will implicitly decode to unicode).
The scaffolding system would read raw scaffolding data in memory (both
templates and passthrough non-templates), but fail to decode templates
before handing them to Jinja, blowing rendering up if templates
contained non-ascii.
Fix#11331 by always decoding templates from UTF8 before handing them
to jinja. This is backwards-compatible, ascii templates work as they
used to, non-ascii UTF8 templates now work correctly, non-ascii
non-UTF8 templates what are you doing?
[0] http://jinja.pocoo.org/docs/dev/api/#unicode
To reproduce the bug:
- Create a partner.
- Set it state "Alaska".
- Country becomes "United States".
- Set a country for YourCompany, such as Spain.
- Create a partner.
- Set it state "Alaska".
- Country remains blank.
Also, `node.xpath("//field")` was running over every `<field>` in the
view, not just those inside the `<div class="address_format">`. Now it
only traverses the right nodes, which renders every affected view
faster.
The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.
To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".
But with f7fe753 when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).
With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.
closes#11224
related to: #11216, opw-660269
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
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
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.
This is related to revision 80b373f.
The above revision leads to the inability
to import new records without any `xml_id` set
Technically speaking, this is because
you cannot concatenate `False` with `'_'`, in
`xml_id + '_'`
opw-668962
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
The recursion was based on an incorrect assumption: the cache of the target
environment is initially empty. If another computation left some value there,
the copying is incomplete, and that causes bugs in onchanges.
While the signature makes sense in an old API context (sort-of) it's
very easy to misuse in a new API context as one'd expect `has_group` to
use the subject (recordset), not the user in the environment, compounded
by ``env.user`` being browsed as administrator, resulting in the
"obvious" ``env.user.has_group(foo)`` checking if the
administrator (rather than the current user) has the specified group.
Adds a divergent v8 version of has_group which first checks if it's
called on a non-empty recordset, and in that case use the recordset id,
otherwise fallback on the context user (to handle new API conversions
which used the "correct" call convention rather than the obvious one).
fixes#9649
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 record is exported, an external ID, in the form of __export__.<model>_<id>
is created on this record.
When the translations are generated (e.g. "synchronise terms" wizard), the
translations may be duplicated for records that have been exported. If a
translation is submitted before the export (when the record had no external ID
yet), a new empty translation is created as the module differs in the import.
Creating a new translation may be a problem as the new term (equal to the source
term) will be used as the translation value.
Fixes 9480
According to PEP302, the signature of `Finder.find_module` should be
`find_module(fullname, path=None)`.
Ever since it was introduced in 64ec5f36df the addons import hook
defines the second parameter as mandatory, which is an issue for
systems relying on the specified behaviour (and not needing to
provide a path) like the stdlib's `pkgutil.find_loader`.
fixes#10670
Borrowing a cursor each time you access `field.digits` may be costly, because
of the connection reset. Moreover, in most cases, the cursor is not used at
all, since the decimal precision are kept in cache.
For the installation of module `product` with its demo data, the number of
cursor allocations was reduced from ~1500 to about 50!
Traversing new records in a different cache requires that all new records on
the path are copied across caches. Make the copy across caches recursive when
the first record on the path is a new record.
or in @onchange for that matter. They should already generate a warning,
but only the first time they're used.
This is done lazily because it introspects the instance/class which can
be costly when performed during the repeated setup of registry setup.
closes#5595
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
xmo-odoo
Odoo Translation Bot
Jairo Llopis
Nicolas Lempereur
Denis Ledoux
Nicolas Martinelli
Raphael Collet
Laurent Mignon
Olivier Dony
Cedric Snauwaert
Xavier Morel
Goffin Simon
Martin Trigaux
Yuriy A. Apollov
Holger Brunn
Sathors
Eric Antones