- 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
This can be used to distinguish template views expected to be
available as web pages, and thus directly linkable. By opposition to
non-web views and template sections (reusables).
bzr revid: xmo@openerp.com-20130821121206-ebxsxrmyogcv7pnv
* don't serialize subtrees to string all the time
* don't add XML root and prefix by string munging
* extract trigger and moved branding attributes to constants
* reduce unnecessary nesting
* don't brand sub-elements of head
bzr revid: xmo@openerp.com-20130802104208-rirrsgtxp2lydd7m
A view for a given model can inherit from a root view specified for
another model. When applying the modifying views to the root view,
only the views with the same model as the child view must be
considered. This patch restore that behavior.
bzr revid: vmt@openerp.com-20130701145334-ojp1plqjveym7cj7
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
from unknown modules fixes this transient problem,
and also means that manually created inherited
views will be validated during module init too.
bzr revid: odo@openerp.com-20130703215704-x732bepiifvf4g3n
* Formally make model not required
* Remove idiotic default values on type and arch
* Make type not required (it's a function field!)
bzr revid: xmo@openerp.com-20130426145113-cf0t0xx24lk9mtgs
* view['model'] required for base_model_name handling, force its read
as with arch (nb: arch could actually be made optional, if it's not
being read can skip most of the inheritance complexity no?)
* if model=None in get_inheriting_views_arch, it generates domain to
SQL `model is NULL`, except model required on ir.ui.view so unspec'd
models are `''` (the empty string) not NULL => inherited views never
found.
Righter move might be to formally make model non-required on view.
bzr revid: xmo@openerp.com-20130426090237-u3rojvx4gow6uue1
Also only case which should result in the id not existing is the
initial record, if a view_id is explicitly provided. So the loop can
avoid it's, it's traversing through an m2o so if the m2o value is not
null the next record in the chain should always exist.
bzr revid: xmo@openerp.com-20130423135739-jve1fe2it8q4gkwh
> Note that this method is deprecated as of ElementTree 1.3 and lxml
> 2.0. It returns an iterator in lxml, which diverges from the
> original ElementTree behaviour. If you want an efficient iterator,
> use the element.iter() method instead. You should only use this
> method in new code if you require backwards compatibility with older
> versions of lxml or ElementTree.
bzr revid: xmo@openerp.com-20130422091958-413qo439qqgv296u
super() finds the MRO parent of the provided class to resume the
execution chain from there, so the class being defined should be
provided.
Here view called super(osv.osv, self).create so if osv.osv (Model) had
a create() defined (which luckily it does not) it would've been
skipped.
bzr revid: xmo@openerp.com-20130415105744-cfx47t01oc7loyes
- as the custom views are still in place when validating the new arch, they would
hide the new arch and prevent proper validation (if custom views are set for uid 1)
- conversely, if the RNG validation has changed, the old view customizations may not
pass the updated validation rules, and cause spurious validation errors
bzr revid: odo@openerp.com-20120924104026-z7bjzzq80ifxy1oc
This will allow improved validation of inherited
views, which is not possible when only the raw
arch is validated on its own - without context
many things cannot be verified.
Calling fields_view_get() also catches early all
mistakes that require dynamic validation, like
wrong XPath expressions (parent view contains
no match).
In order to have current addons pass the improved
validation the RNG had to be fixed to support
the new @modifiers attribute added by fields_view_get()
itself on many view elements, and a few missing
valid attributes, like @invisible on <filter>
and <group>. The latter had never been used
as part of the view architecture but appear
as a result of the handling of @groups
restrictions on view elements, and must
be allowed by the RNG schema.
bzr revid: odo@openerp.com-20120614144633-31c642s7q7f28o6b
As of 7.0, RNG validation is not possible for form views
that have a version attribute equal to "7.0", due to the
allowed usage of HTML syntax mixed with the regular OpenERP
view syntax. RNG validation is still enabled for regular
form views (@version missing or less than "7.0"), and for
all other views types.
Validation of 7.0 form views should be improved with the
addition of an assertion-based schema, still to be done.
The above is also complemented with an explicit call to fields_view_get()
during view installation, in order to immediately verify
that the updated view hierarchy does not cause any
issue when loaded along with its related views (i.e
parent and siblings, for inheriting views).
In addition to that, fields_view_get() will now only
consider loading views that belong to modules that have
already been loaded. This avoids a lot of validation errors
during a module update operation, which runs on top of
an existing database with all previous views visible,
even those whose module is not loaded yet.
bzr revid: odo@openerp.com-20120611122758-qcw9xdhupl24busq
Antony Lesuisse
Jojo le bricolo
Christophe Matthieu
Thibault Delavallée
Xavier Morel
Fabien Meghazi
Fabien Pinckaers
Christophe Simonis
Olivier Dony
Fabien Pinckaers
Martin Trigaux
Vo Minh Thu
Raphael Collet
Quentin (OpenERP)
Cecile Tonglet
Nhomar Hernandez
Divyesh Makwana (Open ERP)
Jigar Amin - OpenERP
niv-openerp