The selection of records in cache for prefetching was moved to method
_read_from_database() by xmo at rev 785018cc in order to fix an access right
bug. But this introduced an issue: to explicitly avoid prefetching, you should
use read() instead of browsing records. We revert the change by xmo, without
reintroducing the bug (which apparently was fixed by another way).
When a new ir.model.field is created, add the new field in the fields_by_model (cache of custom fields). This is required as the __init__ method would not retrieve the new field if fields_by_model is already set.
Otherwise, the _columns would not contain the new fields and we could not access it without restarting the server (e.g. the installation of a module adds ir.model.fields and use it in the a view.
Comparing an id and a browse record will always fail so the exception would have always been raised when changing a model (e.g. updating a module with custom fields).
through a server action, try to correctly set the value to write on a given
fields according to its type. For example many2one fields should receive an
int, not a unique containing the id of the new value.
It turns out TTFontFile can throw not only TTFError (generic) and KeyError, but also ValueError (unknown cmap) and maybe others.
Just catch Exception, warn that the font couldn't be loaded and report why.
Sometimes a node can't be translated using the website Translate
mode. The translation is added to the Application term list but
the id of the view is not correct.
This happen when a translatable node is a children of a inherited
node whose branding could not be kept. data-oe-source-id was left
over because it was not registered in MOVABLE_BRANDING
one2many and many2many fields depends on the security rules.
For instance, on products, with the taxes_id many2many fields, you only see the taxes of your own company, thanks to the multi company security rule
With related *2many fields, if you browse it with superuser, you will have all records of the one2many fields, even those you are not allowed to see, as superuser ignores security rules.
For instance, taxes_id of product.product is a related of taxes_id of product_template (through the inherits on product.template), and you should see the same taxes on the product template and on the product product (variant). This is not the case if the fields is read using the superuser
Antony Lesuisse
Christophe Simonis
andreparames
Xavier Morel
Leonardo Donelli
Fabien Meghazi
Denis Ledoux
Samus CTO
Raphael Collet
Martin Trigaux
Desai Binjal
Thibault Delavallée
xmo-odoo