This reverts commit eeedd2d9f5.
This revision introduces an issue more serious than the ones
it fixes. This is no longer possible to receive an email
aimed a sale.order thread with catchall.
To reproduce the issue:
- Create a new sale order
- Send a message in the thread to the customer
- Reply to the mail received in the customer mailbox
- Traceback, AttributeError: digits
opw-640370
The computation of property `digits` was creating a new cursor to call the
function that determines digits. This technique is fragile because the current
cursor may have pending updates that the new cursor will not see.
The issue was discovered by Cécile Tonglet (cto). She observed an infinite
loop during a database migration, and a traceback inside the loop showed the
presence of the `digits` property. This change fixes the infinite loop issue.
`function` fields are fully copied via `copy.copy()`.
`copy.copy()` *do not* call `__init__` after object creation; then
restore the state via `__setstate__()` or by updating `__dict__` or via
`setattr()` when the object uses `__slots__`.
As `__init__` is not called, the newly created object does not have any
`_args` attribute. This lead to a recursive call of `__getattr__ when
`copy.copy` check the existance of `__setstate__` attribute.
When break this loop by forbidding explicitly by checking the attribute
name accessed (We cannot check the presence of `_args` in `__dict__`
because we uses `__slots__`).
See http://bugs.python.org/issue5370Fixes#6037
opw:633109
The computed value of parameter digits is no longer stored into fields and
columns; instead the value is recomputed everytime it is needed. Note that
performance is not an issue, since the method `get_precision` of model
'decimal.precision' is cached by the orm. This simplifies the management of
digits on fields and saves about 300Kb per registry.
The mappings model._all_columns takes quite some memory (around 2MB per
registry) because of the numerous dictionaries (one per model) and inefficient
memory storage of column_info. Since it is deprecated and almost no longer
used, it can be computed on demand.
For public-facing HTML content provided by the user,
`<style>` tags and `style` attributes should be stripped
automatically, as they can easily be abused to deface
pages for abusive users and spammers.
<style> tags were already stripped, the optional `strip_style`
for fields.html enables the automatic stripping of style
attributes.
This is opt-in because custom style attributes are still
desirable in trusted HTML fields.
The implementation was based on the ill-defined method `same_parameters()` that
compares arguments based on a heuristic. Instead, we now create a new column
and check whether it is equivalent to `self` by comparing the arguments
returned by `to_field_args()`. If that is the case, `self` is reused instead
of the new column.
The code refactoring also fixes the column reuse which was broken by the
introduction of the parameter `compute` in commit 9333c62. Indeed, with that
parameter, `same_parameters()` always returned False, since old-api columns do
not have that parameter by default. The parameter has been renamed to
`_computed_field`, and is no longer passed for creating columns.
When overriding a field defined as a function field, the field must either
create a corresponding column that is not a fields.function (if stored), or
have no corresponding column (if not stored).
In a workflow context (for instance, in the invoice workflow),
context is not passed.
Therefore, relying on the 'recompute' key being the context
in order to not recompute the fields does not work with Workflows.
It leads to huge performance issues,
as fields are recomputed recursively (instead of sequentially)
when several records are implied.
For instance, when reconciling several invoices with one payment
(100 invoices with 1 payment for instance),
records of each invoice are recomputed uselessly in each workflow call
(for each "confirm_paid" method done for each invoice).
With a significant number of invoices (100, for instance),
it even leads to a "Maximum recursion depth reached" errror.
closes#4905
These revs. introduced an API change in the _name_search method.
Indeed, the 'operator' attribute used to have 'ilike' as default value.
This cannot be changed, as every modules overriding this method
overrided it using the signature with operator='ilike'
For instance, _name_search method of addons/base/ir/ir_model.py
expects having 'ilike' as operator.
As it was not anymore the case,
it leaded to a crash when performing a name_search call on the model ir.model,
like when adding a new custom field to a model, from the web client.
opw-626161
For models using a datetime field as name (hr.attendance for instance), the user timezone wasn't applied in the display name.
Therefore, in the breadcrumb, the datetime was different than in the form if the user had another timezone than UTC.
Check if id is valid by searching record columns when a key error is raised
If the record has the column, the key error is actually an error on a
missing or inaccessible id.
Signed-off-by: Sandy Carter <sandy.carter@savoirfairelinux.com>
Closes#3658
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Clarify the semantics of field attributes:
- field.store is True when the field is actually stored in the database;
- field.column is the column corresponding to field or None.
The various field definitions correspond to:
- new-style stored field: field.store and field.column
- new-style non-stored field: not field.store and not field.column
- old-style regular field: field.store and field.column
- old-style function field: not field.store and field.column
This is a memory optimization: instead of setting all attributes on all
instances, set them with their default value on the class, and only set
specific ones on instances. This reduces the memory footprint of around 14Mb
per registry with modules crm, sale, purchase and stock installed.
This is a memory optimization: it reduces the memory footprint of each
registry. We have observed a reduction of 10Mb on a database with modules crm,
sale, purchase, stock.
Remove the hardcoded precision of 12 on factor and factor_inv,
to use the complete natural precision of NUMERIC types,
preserving all significant digits.
e.g. a UoM with a factor_inv of 6.0 used to be computed as:
factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0
Slightly changed the way the ORM handles float fields to allow setting `digits=0`
as a way to explicitly require a NUMERIC value but without enforcing/rounding
the values at the ORM level, i.e. a truly full-precision field.
NUMERIC type has unlimited precision but is less efficient so should not be
used as the default behaviour, which is why we keep float8 as an alternative.
Modified the view to display the product UOM factor with a 5 digits value by default.
This value is for usability purpose only, the field still accepts bigger precision, by
setting the `digits` option on the field in the form view.
This change is safe in a stable series, the `digits=0` alternative is
treated the same as the default `digits=None` everywhere in the framework,
except when creating the database field.
During the update of a module, the existing foreign keys are dropped if they have a different ondelete_rule than the one specified on the field.
The foreign keys for many2one transiant -> non-transiant are created with cascade rule by default (see `m2o_add_foreign_key_checked` method) so the check needs to be realised in the same conditions.
This fixes issue #2146. The inverse of a one2many field can be an inherited
field (_inherits). In that case, we cannot read its value with a simple
database query. Instead, we let the related field read it, but for performance
considerations we disable the prefetching of other fields.
When reading a one2many field, the inverse mapping of the lines (matching m2o -> lines of corresponding record) was instantiating each line and then triggering the prefect of fields.
To improve the performances, the inverse mapping is done in sql to avoid triggering the prefetching.