Due to a compatibility problem between the new API
implementation and the @ormcache decorator, the
context parameter of ir.attachment._filestore()
was dropped at rev. 0beb14f0d2
However the need for caching this method has
disappeared in Odoo 8 (it used to require a
DB query). So it is even better to drop the
@ormcache decorator altogether, and keep the
context parameter.
This avoids a useless change of method signature,
even if that was on a private method.
Make sure pass a list of ids instead of a single id to write calls.
Some models (e.g. blog.post, fixed at 12fc5ea) are assuming that it got a list
of ids and is not checking the type.
Always pass a list of ids as it's the expected format for the orm.
When trying to duplicate a database, while
having opened connections to it, postgresql throws
```
OperationalError: source database "duplicate_test"
is being accessed by other users
DETAIL: There is 1 other session using the database.
```
Connections must be dropped before trying duplication
using TEMPLATE to avoid this.
Commit 540b753bf8 introduced
support for resources stored as ir.attachment records in
asset bundles too.
This is specifically useful for customizations.
However the HTTP route for reaching those resources
when they are *not* in a bundle was originally created
in the `website` module (as a special handling for
404 requests)
This means that these dynamic resources would only
be partially supported when `website` is not installed,
causing various problems:
- missing resources in debug mode where bundles are skipped
- errors when trying to define new client-side Qweb templates
via XML resources - which are loaded with a direct request
- ...
This commit moves back the supporting code to the web module.
The `mimetype` column is not present in ir.attachment without
the `website` module, but sniffing it based on the attachment
name works fine at serving time too.
Closes#6002
The implementation of `ormcache` does not work on methods that take a `context`
parameter. Because of the decorator `decorator`, the arguments of the call are
passed positionally to the method `ormcache.lookup`, and positional arguments
are used in the cache key.
The fix consists in removing the `context` parameter from the faulty methods,
either directly, or by caching a private method called by the public method.
Since revs 53582c2ea6 & f65c913027,
this was no more possible for portal users to read groups
on purpose, for privacy reasons.
fields_get of res.users model is overriden, for
the access rights form view features
(The groups selections and checkboxes).
At each call to fields_get, which happens at each call
to fields_view_get on the res.users model, operations are
done on the model res.groups (basically, to
build the selection groups and checkboxes). So,
each time a view of model res.users is displayed,
whatever the view, operations on res.group model were performed.
The thing is, these operations on res.groups
are actually needed only for the user access rights
view, or at least only for users having the group
Administration > Access rights. These group operations
aren't needed for the preferences view, nor for portal users.
We therefore avoid to do these if the user is not part of the
Administration > Access rights group, which lead to
performances improvment, and solves the fact
portal users couldn't access their user preferences view.
opw-627391
In ormcache, those statistic numbers were counted per cached method for all
registries. We introduce separate statistic counters, and create a counter per
(database, model, method). The existing attributes that are no longer used
have been removed.
The registry size is now assumed to be around 10Mb, and ormcache size is
proportional to the maximum number of registries. Statistics about ormcache
usage is shown to the log when receiving signal SIGUSR1.
In `__getattr__`, remove the test on accessing `_attrs`. This situation should
never happen, since the attribute `_attrs` is set in method `__init__()`.
Introduce slots on all field classes for common attributes; slots take much
less memory than a `__dict__`. The other attributes are stored in a dictionary
`_attrs`; all fields with an empty value for `_attrs` (common case) share the
same empty dictionary. This saves quite some memory (around 4.5Mb per
registry), given the number of field instances created for a registry.
Another mechanism is used for the default values of attributes, since slots
cannot be assigned on classes.
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.
Nicolas Lempereur
Raphael Collet
Olivier Dony
Robert Rübner
Jos De Graeve
Christophe Simonis
FalcoBolger
Goffin Simon
Denis Ledoux
Dharmraj Jhala
Thomas Groutars
Fabien Pinckaers
Nicolas Martinelli
Julien Laloux