Manually adding a line should not trigger the computation of the field, just like modifying the line fields that occur in the field's domain. In other words, the dependencies of the field should be limited to the ones declared on field or its compute method. closes odoo/odoo#71027 X-original-commit: 9000a50582db827ff12acdecf8ef91749122452d Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Consider a model with a field F and a computed editable field G that depends on F. Assume we open a form view, and both F and G have a default value. The first onchange should return F and G with their respective default values. In other words, the field G should not be recomputed even if its dependency F was assigned a default value. The use-case that showed the issue is batch payments. When adding a new payment in the one2many field of a batch, the new payment should use the batch's payment method by default. The default value for the payment's method is assigned by context on the one2many field in the view. Before this patch, the new payment's method was given by the computation of the field, and its default value was ignored. Side note: another test was fixed, but that's because the test was not consistent with the way Odoo 14.0 manages defaults and onchanges.
When performing the onchange for the first time on a new record, if a field has a default value, it could be two times in the `todo` field list to compute. closes odoo/odoo#63983 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a form view is opened, the first call to `onchange` should always compute fields, even if their dependencies have no default value. Make sure it is the case for main records, and for records inside one2many fields. The latter case was actually not working as expected. closes odoo/odoo#63627 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This fixes the issue introduced by revision fd50ba9fb838067fab0b920470cf79b9c94d785c
The way computed fields are invalidated depends on the order of the dict
passed as a parameter to method onchange(). This causes some unexpected
behavior when dealing with computed editable fields: the user loses the
value in that field because of the onchange.
Explanation: during the onchange, the modified field is cached by
record._update_cache(changed_values, validate=True)
If the field is a one2many, 'value' contains an update command for each
modified line. Because of 'validate=True', the assignment triggers
field computations on the lines, which are already handled by another
call to onchange(). In case anything on the parent model modifies some
line, the whole one2many values are returned to the user, and
accidentally recomputed fields show up in the interface.
closes odoo/odoo#62060
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Consider models `M` and `L`, with a one2many field `M.l_ids` with inverse `L.m_id`. Consider also a computed field `L.foo` that depends on `L.m_id`. The field `L.foo` is not computed correctly by `onchange` on a new line in the form view of `M`: its value is forced to `False` because it has no default, and is not recomputed by `onchange` since the field `L.m_id` is never triggered an `onchange`. Modify the method `onchange` to not force fields without a default to `False`, and return all fields.
Before this commit, a lot of leftover import shims existed in the codebase for py2-py3 compatibility, these are no longer needed since Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL. With this commit, these shims are dropped, making the code cleaner, easier to read and with one less dependency. Queue -> queue -> py2-py3 compatibility xmlrpclib -> xmlrpc.client -> py2-py3 compatibility ConfigParser -> configparser -> py2-py3 compatibility itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility urllib -> urllib.request -> py2-py3 compatibility __builtins__ -> builtins -> py2-py3 compatibility _winreg -> winreg -> py2-py3 compatibility mock -> unittest.mock -> merged into CPython The debian/fedora packages and requirements.txt have been updated accordingly closes odoo/odoo#44601 Related: odoo/enterprise#8141 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose of this commit is to let computed stored editable fields being copied if their field class allows it. Indeed the value of those fields is computed based on some triggers but can also be updated manually by users. When copying a record, it makes sense to consider that this value is what the user expects and allow its copy, if the original field allows it. Either it was computed, and copied value will be correct without having to call computation again (well, provided all dependencies have been copied, too), or it was updated and the copied value will be the one the user entered. Without this fix, an edited field is not copied, and will be recomputed, which may look like an inconsistent value. Task ID 2209163 closes odoo/odoo#48383 X-original-commit: 4b274d3b4101fbae154a572cdf40d23838899773 Signed-off-by: Olivier Dony (odo) <odo@openerp.com> Signed-off-by: Raphael Collet (rco) <rco@openerp.com> Co-authored-by: Raphael Collet <rco@odoo.com>
The use case is a cache miss of a stored field with compute on a new record with origin. The field should be computed only when explicitly triggered, i.e., when a dependency has been modified. Otherwise it should be fetched from the origin record. closes odoo/odoo#47353 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>