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
Thibault Delavallée
Fabien Meghazi
Xavier Morel
Christophe Simonis
Christophe Matthieu
Olivier Dony
Fabien Pinckaers
Fabien Pinckaers
Antony Lesuisse
Martin Trigaux
Vo Minh Thu
Raphael Collet
Quentin (OpenERP)
Cecile Tonglet
Nhomar Hernandez