It was considered important to precise that image fields without
limitations weren't checked
at all and could therefore contain non image content (and precise some
other things on Image fields).
Forward-port of #51200closesodoo/odoo#51259
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If the original field is defined with a selection list, overrides with
method or methods names fall back on the list.
closesodoo/odoo#51232
X-original-commit: 272ba8d2238d1d1b87f47b114b55e6eed25314a8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The supported case of check_company on `res_company` model fields was
not considered when specifying a default domain on `check_company=True`
fields.
closesodoo/odoo#48674
Nb: It is already correctly supported in the `_check_company()` method.
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The following loop crashes on the second iteration:
for record in records:
record.display_name # access non-stored computed field
record.unlink() # delete record
The cache has been invalidated by `unlink` on the first iteration, so
the field is computed. The computation is done on the whole recordset,
which fails with a `MissingError` because of the first record. The fix
is to retry the recomputation on the single record in this case.
closesodoo/odoo#50910
X-original-commit: 7f33ebf528b1415452ce549e3329c3fe89be0ad8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When setting a many2one field, the corresponding one2many fields are
updated in cache. When such a one2many field has a domain, the
evaluation of the domain may require to fetch some fields from the
database. If the `towrite` cache has not been updated yet, the many2one
field is overridden by the database value.
Fix by setting the `towrite` cache before updating inverse fields.
closesodoo/odoo#50788
X-original-commit: c1ebfe05a66cfebc7ced36e25db5f6ff4bfb2d46
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Consider a sales order with a single line. Edit the sales order: remove
the line, and add another line with the same subtotal. When saving, the
total of the sales order is 0.0.
Here is the explanation: the form view performs a `write` on the sales
order, and modifies the lines with a command `2` (remove line) and a
command `0` (create line).
After deleting the first order line, the cache is emptied, and a call to
`flush()` forces the recomputation of the total. The value is computed
to be 0, and assigned to the field. The assignment converts the value
for the cache, without prefetching the currency field (optimization),
and puts 0.0 in cache. The assignment then converts the value for the
database, which prefetches most fields on the sales order: the cache is
now inconsistent and contains the old value V, while the database is
then updated with 0.0.
After creating the new order line, the total is once again recomputed.
Its value is V, and because the cache also contains that value, no
update is performed to the database, which remains at 0.0!
The fix consists in avoiding the prefetching of fields when accessing
the currency field to round a monetary value.
opw-2223134
closesodoo/odoo#49741
X-original-commit: 048ea2f20a0a2fa6d629cbe262cbbe765248d36f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* add a `raw` computed field, though only update some of base to use
it (addons for which that makes sense can be migrated progressively)
* avoid working with base64 data when it's possible to work with the
actual data
* improve datas (base64 encoded content): should depend on bin_size
closesodoo/odoo#47212
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The method `_init_column` for the field `alias_id` of `mail.alias.mixin`
requires the reflection of models, because `mail.alias` records have a
many2one field to `ir.model`. The actual initialization of the column
is thus performed in post-init phase (after reflection). Therefore, the
NOT NULL constraint cannot be added right away.
X-original-commit: 2e3400f149ce4ed4c00bc49a519f58993b49bc51
This greatly reduces the number of queries to add foreign keys (notably
for many2one fields).
This saves 6.5% of the total installation time.
X-original-commit: 13a2666b4da09fc0ec7608a974dadde45f76fd7a
Reduce the number of queries to create and drop indexes.
This saves 1.5% of the total installation time.
X-original-commit: 0e1e480da9d971575feba64038c4fa518ebe102b
Simply avoid browsing records for models, and use classes instead.
This saves 1% of the total installation time.
X-original-commit: 35ebaea098edeb3d34f77305b09cb36e56ea5a92
This optimization is no longer necessary. Thanks to Python 3.6's new
implementation of dicts, the memory footprint difference between slots
and dicts is now around 5%, which is no longer worth the complexity and
performance cost.
This saves 2% of the total installation time.
X-original-commit: c7f17770803744cbbb741fc11265ee914641aed7
Simplify the code to retrieve fields on a class.
Simplify the class attribute that lists the class' proper fields.
Optimize `model._add_inherited_fields()`.
Optimize `resolve_mro` by using classes instead of recordsets.
This saves 3.5% of the total installation time.
X-original-commit: 89ab71905cb6c5d3beda5eac357f8592e31aaef8
Repeated calls to `registry.setup_models()` will eventually introduce
many duplicates in the those attributes, which may slow down the
determination of computation triggers.
X-original-commit: 735e65f7ca45616881336121d10a874412446dcf
Co-authored-by: Xavier Morel <xmo@odoo.com>
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
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* = event, website_event_track, website_sale, website_hr_recruitment,
website_livechat, website_sale, website_slides
The option to sanitize or not the forms was not available, this will
allow better flexibility on whether forms should be sanitized or not on
an HTML field.
Also we use this new param to allow forms to be added on some already
existing html fields where forms where sanitized out.
task-2209554
closesodoo/odoo#47318
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Let A and B be two different modules.
- A defines a required Selection field F of model M and B extends
it through the `selection_add` argument.
- Create records of model M and have some of them have any of the
options introduced by module B selected for field F.
- Uninstall module B.
The result will be records of Model M with an option for field F that no
longer exists, this makes the registry inconsistent and prone to
crashing (it is sufficient to access the form view of such a record to
trigger a crash).
This commit introduces a mechanism similar to the `ondelete` argument
found in Many2one fields, the argument name is the same but it's
different both in behaviour and in implementation.
The `ondelete` mechanism for Selection fields is enforced for **any**
Selection field with required set to `True`, this means that the
developer is required to set a cleanup behaviour for when their module
is uninstalled. For possible cleanup options, see fields.Selection's
docstring.
As far as implementation goes, everything is implemented in Python
unlike with Many2one fields where the behaviour is delegated to
PostgreSQL.
The `ondelete` setting will be processed during
`ir.model.fields.selection.unlink()` to ensure that the registry is left
in an appropriate state after module uninstall.
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
closesodoo/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.
closesodoo/odoo#47353
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, when a user try to import data with a XLSX file, the
file was mistaken by an SVG file. This issue arises because a XLSX file
from import isn't encoded in base64, and for testing if the file is an
SVG file it will be decoded. base64.b64decode by default (when validate
is False), will remove all characters that are in the base-64 alphabet
from the input prior to decode. So in our case, when the non encoded
XSLX file is force decoded the results starts, unluckily, with '<' and
it's mistaken by an XML/SVG file. Note that, the XSLX file is wrongly
tested because a XSLX file is just a ZIP file, and all the ZIP files
start with PK\x03\x04, and P is the first byte of a base64 encoded XML
file.
Now, only files that were previously encoded into base64 are decoded to
be tested. The validate = True parameter in base64.b64decode will raise
a binascii.Error if there are a non-base64-alphabet characters in the
input, this will allow us to know if the input was or wasn't base64
prior encoded. As base64.b64decode with validate = False, removed the
non-base64-alphabet characters this allows to decode input files
compatible with RFC 2045 (MIME). The files compatible with this standard
will have a newline character (b'\n') after every 76 bytes of the
output, and end with a newline. To keep backwards compatibility, we
remove the newlines and the carriage return from the input before the
decoding.
opw-2194468
closes#36081closes#31849closes#33543closesodoo/odoo#47906
X-original-commit: 65d709c9ab386d646f682c494cfb21cb06ec8034
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Before this commit, x2m fields were described as 'sortable'
This was odd since:
- When actually sorting on one of those fields through the webclient
the sorting was gibbrish
- Even the orm silently warned in the log that
the field was not a sql column and therefore was not sortable
After this commit, only a field which is column (and a few other conditions)
can be sorted
Task 1863492
closesodoo/odoo#46921
X-original-commit: dd3094378fc322447d1aef994f6bace3f0c24288
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Remove a leftover special case of the ORM from a former version.
This fixes a performance issue, where an onchange recomputes a field on
one2many lines one by one.
X-original-commit: 16a75d85741db8a1f87c1d26503a9bb75197cf83
This makes the behavior of `onchange()` consistent in the case of
inherited models (with `_inherits`).
closesodoo/odoo#45910
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
time.clock is deprecated since python 3.3 and no longer exists in python 3.8
time.process_time was introduced in python 3.3
Replace "is" by "==" as this produces a SyntaxWarning in python 3.8
Fixesodoo/odoo#41313closesodoo/odoo#44502
X-original-commit: f03b4cb5576f264b6845242ba112f02422af4f5f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit executing m2m commands in batch would lead to undesired
results, such as duplicating the related records on every subsequent record of
the batch.
Indeed since [1] the `create` and `unlink` are called in a loop, but their
content was not reset at each iteration.
[1] 9920f20e4cclosesodoo/odoo#43950
X-original-commit: 0800f64b011c8f020c0d7dd6e1c149aebd1a4627
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Previously, mapped was following a very naive approach, which was simply
calling the field name passed as input for every record in a recordset,
sequentially.
The problem with this approach is that we will potentially recompute the
same fields multiple times for differents records, when this could be
done once per field for ALL records, and store this value in cache for
further access.
Another potential problem is that we don't take advantage of the ORM's
prefetching to fetch all the records that are not in cache at once,
instead of doing the same query for every record in the recordset.
Yet another problem is the conversion of each cache value to a record
format and then combining all of the individual records into a single
recordset, which, depending on the size of the recordset, can take an
unbelievable amount of CPU time.
With this new implementation of `mapped()` we take care of all of these
problems:
This is done by first delegating `mapped()` from the model to the field,
this mapped takes a recordset as input and it will try to batch compute
and prefetch as much as possible for the entire recordset, but it will
not keep these values for the actual output, it just stores everything
in cache and then at the end, retrieves everything from the cache to
guarantee the same order.
After the mapped, the conversion from cache format to record format is
delegated to the new `convert_to_record_multi` which will fetch all the
ids and then perform a single browse to encapsulate all of the records
into a single recordset with the least amount of overhead possible.
Part of Task 2170344
closesodoo/odoo#42611
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Computing the `cache_key` turned out to be a big factor during the
lifespan of a `BaseModel.mapped` call and a lot of this time is spent
computing the same `cache_key` over and over.
These unnecessary computations can be easily reduced to a couple by
moving the `cache_key` method on the environment (instead of the field)
and by implementing a memo for that method. The rationale is that the
`cache_key` of a field does not change for a given environment.
The result of this patch is up to 50% faster `Field.__get__` which in
turn means a GLOBAL gain in performance, especially for methods /
functions that rely heavily on `__get__` such as `BaseModel.mapped`.
closesodoo/odoo#42674
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Consider an x2many field with `context={'active_test': False}`. The
value of that field should always contain inactive records, as the
field's own context overrides the context of the current record.
closesodoo/odoo#42824
X-original-commit: a2fc37adc179fb8bfc11251137334f0a43c58135
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Assume F and G are computed by the same method on a missing record R.
During recomputation of F on R, the compute method is called but fails
because R is missing. Both fields are re-marked to compute (because
computation failed), then F is discarded (because R is missing). Then
comes G's turn: G is accessed on R and the computation fails. Both
fields are re-marked to compute (because computation failed), then G is
discarded (because R is missing). Now F is marked again to compute: the
process never ends.
To avoid this situation, discard all fields to recompute on missing
records.
closesodoo/odoo#42234
X-original-commit: 78bf4dbaa1c4adfa1dac68a4d79b87800003ac05
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
Makes it way easier to realise that a cache access blew up because of
a @depends_context('active_ids'), which returns a list, which is not
hashable.
closesodoo/odoo#41863
X-original-commit: 5d2ce1fb3f2f14c9274924d3f4052279671a0c3b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Those cases are already checked in models._check_company() but not considered
when defining the default domain on `check_company=True` fields.
* Consider res_users relational field
Companies allowed for user = user.company_ids
* Consider company-dependent fields
Companies allowed = self.env.company
closesodoo/odoo#40906
X-original-commit: a8de9509823c213dad2f5e8ff44ceb670f81ea70
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This is a performance fix. It avoids the cost of XML/HTML translations
for fields that may not be necessary when prefetching fields on records.
This patch marks such fields as non-prefetchable by default.
The code that changes the attribute `translate` on HTML fields (from
`translate=True` to `translate=html_translate`) has been adapted to
allow the setup of textual fields to mark the field as non-prefetchable.
Jairo Llopis made a comparative benchmark: evaluating `name_get` on
`event.event` records. The method needs the field `name` and without
the patch, the prefetching mechanism reads the translated HTML field
`description` as well. This patch speeds up the benchmark from 5800ms
to 800ms (see https://github.com/odoo/odoo/pull/37967#issuecomment-538364011).
closesodoo/odoo#40771
X-original-commit: e5ee5e5b65f85d66c8d59594ead9eece172c4282
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Pedro Baeza <pedro.baeza@tecnativa.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>
From now on, if one wants to force following operations to happen in a given company,
use with_company(company) or with_company(cid) to update the environment.
Before this commit, when modifying a Many2one in a form view to add a
new record, it will create the new record, and calculate the inverse
and write it in all the records of the list. This will call the write
method in all records even if they weren't changed.
Now, the inverse is set to be modified only if it's different from the
current value.
opw-2091842
closesodoo/odoo#40258
X-original-commit: 417cee7f0fdb7ed7eb424178efb656b967fa0a5e
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
Victor Feyens