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).
The widget AddToDashboard used to make an ajax call every time the
search view is loaded. This is often useless and can be annoying when
that request is long. With this patch, the request is only done when
the user click on the widget AddToDashboard
Starting from v8.0, there's only "My Dashboard". We can assume that we
have access rights to all the actions we pin to our proper dashboard, so
we can remove this filtering. Furthermore, this was a large performance
pitfall.
product_id column of pos_order_line is a product_product
the left join of l.product_id was done on product_template, instead of product_product
It worked as long as the ids product_product were the same as product_template. Meaning that, if you used variants, this report view was screwed.
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
If a portal user has engouh karma, this is possible for him, at least graphically, to delete forum posts, even if is not the author of it.
So, he should be allowed to delete forum posts in the ACL
Raphael Collet