If a field is inherited from another model, the attribute context_dependent
was not propagated correctly.
Example of bug:
>>> product = self.env['product.product'].search([], limit=1)
>>> product.name
'Whiteboard Pen'
>>> product.with_context(lang='fr_FR').name
'Whiteboard Pen' # cache used
>>> template = product.product_tmpl_id
>>> template.name
'Whiteboard Pen'
>>> template.with_context(lang='fr_FR').name
'Marqueur pour Tableau Blanc'
>>> product._fields['name'].context_dependent
False
>>> template._fields['name'].context_dependent
True
Fixesodoo/odoo#33641Closesodoo/odoo#33722
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The compute method of a recursive field must be invoked on single
records even when several records are marked to recompute.
closesodoo/odoo#33529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Creating field indexes might not always be possible. For instance,
adding an index on an existing Char/Text field will fail if the column
contains values longer than 8192 bytes (PostgreSQL limit for BTrees).
Instead of failing miserably during the schema modification, simply log
the problem and continue.
closesodoo/odoo#32416
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
Use `env.registry` instead of `env` to get the comodel as a class instead of an
instance, which saves one call to `_browse` each time we access a relational
field. This saves time because of the cost of `object.__new__` and prefetch
update in `_browse`.
The definition of `attachment_ids` on model `email_template.preview` is wrong,
because its table/columns refer to the model `mail.template`. As the field is
only used to preview a result in a wizard form, it does not need to be stored.
closesodoo/odoo#29349
In the case of attachment_ids, comodel._fields[inverse] can be res_id,
an integer field. Such fields do not have a default ondelete attribute.
opw 1945926
closesodoo/odoo#31864
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
On a field created through a _inherits, the fields on the child model did not
benefit from the parent _modules information.
If two models are created in module base
class Partner(models.Model):
_name = 'res.partner'
class User(models.Model):
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one('res.partner')
and a second module auth_signup adds a field on the parent model
class ResPartner(models.Model):
_inherit = 'res.partner'
signup_token = fields.Char()
Both res.users and res.partner should have an ir.model.data create
base_setup.field_res_partner__signup_token was correctly created but
base_setup.field_res_users__signup_token was not created
The reason is was, in the call to _reflect_model, since 574f4c3deb, the
creation of ir.model.data is based on the field._modules
However, the field res.partner.signup_token did not propagate its _modules value
to the related field res.users.signup_token
With this patch, both ir.model.data are created.
This allow a proper uninstallation of fields as well as translation.
- Set a TZ on the user different from UTC
- Export a record containing a datetime, e.g. the Order Date of a SO
- Import the file
The Order Date is changed on the record.
The data export is always in UTC, but the data import takes into account
the user TZ, which explains the difference.
There is no good way of solving this in stable. We have 3 choices:
1. Do nothing: the flow export then import the same data is broken, as
explained above.
2. Export in the user TZ: if the file is imported in a third-party
software, we break the flow.
3. Import in UTC: if the file is generated from a third-party software,
we break the flow.
Whatever the choice is, we either break a flow or keep an inconsistent
behavior. We choose option 2, assuming that in most cases the user wants
to export the data in his TZ, therefore keeping the values displayed. We
only do it in v12 in order to mitigate the impact on existing
installations. A proper fix should be discussed for v13.
opw-1915631
closesodoo/odoo#29576
This commit allows for not copying the currency_field attribute
of a monetary field when the monetary field is related,
and when the currency_field attribute is not explicit
Before this commit, the currency_field attribute on the related monetary
was set as the one on the distant model
After this commit, the currency_field attribute takes the field on the
current model
Though the test may appear like an incoherent use case,
it is on the contrary totally legit, as web_studio allows it
OPW 1903113
closesodoo/odoo#28144
Introduce official support for SVG files in the framework, including the
following parts:
1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].
2. Make /web/image controller compatible with SVG
3. Add support for SVG files for company logo, which uses a dedicated
controller.
4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.
5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)
6. Add tests for the SVG upload cases and for the non-admin uploads.
[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_SecurityCloses#26635
With this commit, any *explicitly* related fields will be `readonly=True`
by default.
*Implicitly* related fields (i.e. _inherits fields) however will keep the
source field's `readonly` attribute.
The rationales behind this patch are:
* Enforce good practices, as the most common use-case for
related fields is the same as for compute fields: to read data.
* Avoid errors where some user saves a form view which contains
a related field that the user doesn't have write access to.
compute_sudo has no effects on non stored computed fields.
It was technically already said in the previous lines (REcomputed) but
it was not particularly explicit
closesodoo/odoo#31320
When trying to upload a file with no ASCII name, it raised a
traceback saying: "UnicodeEncodeError: 'ascii' codec can't encode character ..."
opw:1886602
During an onchange, setting a many2one field automatically updates its inverse
one2many field. If the update raises an exception, catch it and put it in
cache, so that it is re-raised when the value is read from the cache.
Note: all costs are according to cprofile on my machine, as a fraction
of total time to import, python-flamegraph has somewhat different cost
distributions, YMMV. Profiles use test-import of a 2500 partners file,
with name, country, street and 0~4 tags, all randomly
generated/assigned.
Costs were profiled as split 8.5%/32%/57% between data conversion,
creating records (Model.create/Model._create) and populating stored
computed fields for a total import time (unprofiled) of 1mn (±2s or
something).
For the creation step, 27% (of total runtime) were assigned to the m2m
(fields.Many2many.create), almost all of which (25%) was assigned to
accessing a record's id in a listcomp in a loop.
Optimisations:
* optimise the case where we're only adding / creating values:
represent the relation as a dict of sets instead of a set of pairs;
commands 5 and 6 will only operate on the current record's value,
instead of traversing all pairs in the relation
* optimise accessing the value of an id field by hand-inlining the
various bits, this is mostly obviated by the other previous
optimisations (number of Id.__get__ calls reduced from 5.4 millions
to 0.55) but given how common accessing a record's id is (and
how it's usually considered to be free) it's still a good idea: cost
of accessing the id field was reduced by 75% (0.55 million accesses
went from 3.32% of total runtime to 0.83%)
Without profiling, time to import my test file went from ~1mn to ~45s.
Now that Date/Datetime fields use python naive datetime, we want
to prevent developper to call or assign aware datetime to
fields. Moreover, if so, the timezone will be stored in the
database, but when reading Datetime fields, we expect naive datetime.
Comparing naive and aware datetime objects leads to errors.
This commit forces developpers to use naive datetime when saving
data in database.
As example, we have to erase the timezone of dates in calendar
modules. We also regroup the 2 assignations in one call to
`write` for performance reason.
Thanks to @dbeguin and @RomainLibert for spending some time
on this bug.
Florent de Labarre