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.
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)
Each REPL python shell behave differently depending on the exit method.
Force a rollback at the end to avoid inconsitent behavior.
Thanks to Harry Jollenbeck for the report: https://www.odoo.com/groups/59/26318707
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
In monetary field refactoring (3407fb70e4) there was a small issue that
made context lost so the language use to render the field could be
different from the one to render the view.
For example: if the user has english, and print a report using the lang
of a partner in language spanish, the report would use spanish to format
number for all fields but monetary (which would use english).
opw-708197
When a language is deactivated, it may still be referred to in a default value.
A ir.value is created at the database setup to specify the default language.
If a user deactivate the default language but not the ir.value, the creation of
a res.partner would fail as trying to set an unknown value to a selection field.
This commit removes the default value when deactivating the linked language.
The patch is minimal for the bug. A more generic solution would be to verify the
ir.value when calling the default_get method.
This is however a risk of performance degradation (e.g. during a csv import) for
a rare scenario.
The dynamic selection scenario is probably on relevant to res.lang.
A similar problem can occur with many2one fields but is difficult to fix without
performance degradation.
Closes#16009Fixes#15979Fixes#3854
In f65475d6 one2many fields of default view in a form view were propagated
to the ORM so the value received from an onchange was not empty.
These new steps test this on a tree view embedded in a form view, or a
tree view originating from a default view by testing onchange adding row
or updating values of a one2many.
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
In stable version, the right fix would be to put an attribute ondelete=cascade
on the field model of ir.model.constraint.
In 10.0, the ir.model.constraint are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
If the company currency is not active (that should not happen but nothing
prevents it, probably happening with some CoA installation), the variable
company_currency_format is undefined and an error is raised.
Closes#15799
Raphael Collet