When importing translations with a csv, the state of the translations was
always set to "To translate" even if the state was "Translated"
due to function _inverse_source.
PS: Making self.source when self is considered as record set could lead to an error.
The return in this function was not needed.
In old API this function was called just for one record.
So this function expect only one record at each call.
opw:747877
It calls `onchange_state()` on `res.partner` which was removed on
(24aba60).
It was added to `res.users` long ago (009ea40) to support a `state_id`
field on the view `res.users.simplified.form` that is no longer there
since v8.0.
The method is then never called and was crashing if called.
Closes#17772
Closes#16973
Steps to reproduce:
1) Go to Settings -> Technical -> User Interface -> Views
2) Create a new view and give only name, leave fields View Type and arch_base empty.
3) Exception occures
Current behaviour:
- The user gets an exception with a full stacktrace.
Expected behaviour:
- The user should get a warning
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
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.
The context is not in the kwargs when the integrity error is raised from
a rpc request. So the user lang was lost and the sql error message was not
translated.
The part treating the callable message in sql error is depracated.
opw:743259
In a scenario with the following views:
Mod A, view 1*
|-- Mod B, view 2
\-- Mod B, view 3*
view 3 can not rely on the elements added by view 2 in xpath
If view 3 is a primary view, view 1 must be fully resolved first (apply view 2)
before resolving view 3.
Next commit describes a real use-case with product.
Linked to #16541 and #16428
The GeventServer process was not enforcing the
configured memory limits. In the unlikely event
of a service handling hundreds of concurrent
longpolling requests on hundreds of different
databases, this could render the Registry LRU
ineffective in keeping a low memory footprint.
Even after being evicted from the LRU, these
hundreds of registries would still be referenced
by their in-progress requests, so the memory
would not be freed. An Odoo 10 registry can
typically take 15MB of memory, so this could
become a problem.
In function name_get on model "delivery.carrier", the field name
is taken from "product.template" and the translations were just
available on model "product.product".
The translations for the "product.template" records were not available
in the .pot file because there was no external identifiers created for
the "product.template".
Now when creating the external identifier of a record, all the external
identifiers of the inherits models of this record are also created.
In this way, all the translations will be created.
opw:728682
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`.
When adding a field on a model, only the _inherit were checked, not the _inherits.
This commit fixes the following bug:
1. install `sale` (adding the field `sale_order_count` on `res.partner`)
- field `sale_order_count` is created on `res.partner`
- the ir.model.field is tagged with module `sale`
2. install `point_of_sale` (adding another field on `res.users`)
- field `sale_order_count` is created on `res.users`
- the ir.model.field is tagged with module `point_of_sale`
When installing sale, the model res.partner is returned in the list of impacted
models, on which _create_fields method is called but not res.users.
A direct consequence of this bug is that, the fields translations are in the
wrong module. May fix some uninstallation bugs too.
Closes#16104
The start command takes the default dbname from the path.
But when running inside a virtualenv, it is a better default to take the
dbname from the virtualenv's path.
Nicolas Martinelli