The optimization consists in using tuples for attributes `inverse_fields`,
`computed_fields` and `_triggers`, and to let them share their value when it is
empty, which is common. This saves around 1.8Mb per registry.
This saves about 400Kb per registry by not allocating those lists, which are in
most cases empty. The removal of the attribute will also simplify a bit the
management of free attributes.
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.
Sometimes, the expected mro of the model is not the same as the one built with
a binary class hierarchy. So we reorder the base classes in order to match the
equivalent binary class hierarchy. This also fixes the cases where duplicates
appear in base classes.
Instead of composing classes in a binary tree hierarchy, we make one class that
inherits from all its base classes. This avoids keeping intermediate data
structures for columns, inherits, constraints, etc. This saves about 600Kb 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.
The ormcache is now shared among registries. The cached methods use keys like
(DBNAME, MODELNAME, METHOD, args...). This allows registries with high load to
use more cache than other registries.
This will allow to speed up our migration platform: as funzip can pipe
the output of the first file of the archive, even if the file is not
fully unzipped yet. This is useful to plays with dump.sql without waiting
for the full archive decompression.
When a `noupdate` record is processed during an update,
the update_dummy method marks the record as "seen" so
it won't be deleted at the garbage collection step,
and seen as an obsolete external ID.
This needs to be done also for the parent records via
_inherits, because they have also received an implicit
external ID at creation, and must not be garbage
collected, even if their `noupdate` flag (db side)
is not set because the flag was added later.
This rare problem could be reproduced by creating a product
in a module, then referencing it in e.g. a sales order,
then updating the module after changing the product
record to be in a `noupdate` block.
At the end of the update the implicit product.template
record would be garbage collected, and trigger a cascade
deletion of its children - blocked by the SO reference
to the product.
The invalidation in registry was done only if the field's model was already in
registry. This situation is not the case when you create a custom model with a
custom field.
When deleting a server action, its fields_lines were not deleted.
It causes an issue for example in this case:
Create a new custom field on any model
Create a server action with
Action To Do: Write on a Record
Base model: model of the custom field
Add a line in the value mapping,
using the custom field you just created
Delete the server action
Delete the custom field => Throws an error because
required field col1 is not defined
on the ir_server_object_lines object
When opening a record from a many2one,
the context is not propagated to fields_view_get.
This is a problem if you set "form_view_ref" in the context for example.
opw-629628
It's always dangerous because (cascade-)deleting workitems
has a great chance of killing the workflow instances they
belong to, putting the records in the workflow limbo
permanently. (They will appear stuck as they don't have
enough workitems anymore)
In addition, in some rare cases a subflow activity is
converted into a regular activity during an update, and
nullifying the `subflow_id` column is all there is to
fixing the corresponding workitems. It will simply take
them out of their subflow, and back into the main flow.
This is the case for the modification of the purchase.order
workflow in Odoo 8 (saas-5), for the picking subflow.
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.
As custom views validation is done while `self.pool._init` is set,
filter on currently loaded modules was still applied.
As a side effect, only one custom view per base view was validated.
In case this view is depending on another custom inherited view, the
validation failed.
Now force loading all views when validating custom views.
While `apply_inheritance_specs` apply most of its changes inplace, it may
completely replace the `arch_tree` if the root node is replaced.
This new root node wasn't used for `primary` views that inherit from
another.
When the ORM is cleaning up related attachments upon record deletion, the
search() method hides the attachment of the record that is being deleted.
If the same file is used exactly once in another attachment, the reference
count will be 1 and the file will be deleted.
This should improve the performance of method read() on models with inherited
fields, like product.product. The inherited fields that are stored as columns
in parent tables (except for translated fields) are read in the same query as
the fields of the model. Those fields will be directly stored in cache under
the main model, so that no copying will take place in cache for accessing them
(this is the default implementation of inherited fields).
This makes the query construction more robust, as it handles joins for
conditions and ORDER BY clauses. It also makes it easier to read() from
several tables (like inherited fields).
Improve the performance of `name_get()` on many2one field values by making sure
that the records on which `name_get` is invoked are prefetched in cache. This
is not automatic, because `name_get` is invoked on records in another
environment (sudo mode): the prefetching in the original environment should be
reproduced in the other environment.
Add .template as extension of the template files because RPM packaging
produces an error when trying to compile the python template files,
which contains Jinja instructions.
Include *.template files in MANIFEST.in to package them.
Variable was added to an error message, then inlined in only one of the
two callsites. Undefined variable error would only appear when an error
is triggered in the actual (postgres-level) backup call.
inserted in ec9a543fixes#5241
- Translations lookup normally uses the namespace of the current
QWeb template, after merging all inherited views.
But when a QWeb template is "cloned" by a child view using
inheritance with `primary` mode, the translations are more
likely to exist for the original (parent) template, and would not
be found when using only the "child" namespace.
This patch adds support for looking up each translation
also in the parent namespace in this case, if none was found
for the child template in the first place.
- ir.translation's _get_source() now supports a list of res_id
to search for, in addition to a single res_id
- Also moved the logic of routes /website/customize_template_get
and /website/get_view_translations to the ir.ui.view model where
it belongs.
opw: 615241
Closes#5325
Custom fields can point to custom models that have not been initialized
yet (`_setup_base` not called). Ensure every models in the registry
have a `_fields` attribute.
Use a `frozendict` as a defensive check to ensure it wont be modified
before calling `_setup_base`.