- now using openerp.tools.safe_eval, instead of a custom eval with custom builtins
- removed undefined_handler, hardcoded to a lambda function that returns None for
a missing attribute
tools.safe_eval: added a parameter locals_builtins. This allows to copy the builtins
in the locals. This hack is due to the fact that the locals always returns None, allowing
to simplify templates. Otherwise we would have to test the existence of each variable
before actually using it.
However as the locals always return None for every key, the globals are never checked.
Copying the builtins inside the local allows to have a complete locals, but sligtly
break the globals/locals separation.
To be reviewed and approved.
bzr revid: tde@openerp.com-20140116182750-1rnw8iljt5a9gb4u
main problem, view inheritance model field would use model from the
root view (after following inherit_id links) rather than the base view
(the requested one) -> with divergent models, it was possible for the
requested view itself to never be returned.
bzr revid: xmo@openerp.com-20131212134422-uxg6h21w1jhth9ow
ir.fields architecture turns out not to be a very good or simple fit,
especially as different widgets/fields need different granularity of
customizations. Having objects dedicated to each field type/widget
makes things simpler as it allows a conversion pipeline which can be
plugged into at any point.
bzr revid: xmo@openerp.com-20131007091556-03azc2mdhcb7kmwo
Change attempted to simplify branding distribution, but based node
branding on final view. To be able to rewrite, node branding must be
based on source views positions before applying inheritance.
Reintroduce manual generation of xpath in distribute_branding as
ElementTree.getpath() can't handle it.
Note: why isn't branding distribution performed during initial views
reading (e.g. inherit_branding)? Surely that would obviate the need
for special casing and manually creating paths no?
bzr revid: xmo@openerp.com-20130919130847-3t8zfpv9m9pcibg0
When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
Thibault Delavallée
Xavier Morel
Fabien Meghazi
Christophe Matthieu
Fabien Pinckaers
Antony Lesuisse
Christophe Simonis