Before this commit, @mode=primary would be sorta-ignored[0] if the current
view and its parent had the same model: the current view would *still* get
applied (as an extension) when asking OpenERP for its parent. This commit
makes mode=primary views behave regularly, they are *never* applied when
asking for their parent, only when asking for them or their children.
This allows "forking" views, and using extended views in some contexts without
breaking or duplicating the original view
[0] there was actually a problem when asking for the current view directly,
first its parent would be resolved by applying it, then it would be
applied to resolve itself, the view would thus get applied twice (oops)
Not used yet, only defined its relation to inherit_id:
not inherit_id + primary -> ok
not inherit_id + extension -> error
inherit_id + primary -> ok
inherit_id + extension -> ok
Server-side, view extension is done via xpath. This includes "template" views
full of HTML.
HTML elements often have a bunch of classes, sometimes even semantic
(!). XPath is generally great, but specifically lousy at dealing with
space-separated values: in standard XPath 1.0 to know if an element has a
class 'foo' the predicate is:
contains(concat(' ', normalize-space(@class), ' '), ' foo ')
and this has to be fully duplicated if there's a second class involved.
Things are slightly better with EXSLT/XPath 2.0 and tokenize, but still not
great:
tokenize(@class, '\s+') = 'foo'
and the equality check is very weird when unaware of XPath's evaluation rules.
``hasclass`` makes this much simpler to deal with: to get any ``foo`` node
with the class ``bar`` is as simple as:
//foo[hasclass('bar')
and it can take multiple class, as with e.g. jquery it will return elements
with all specified classes.
Beware though, the predicate function will be called once for each element to
check, since it's implemented in pure python and not profiled elements should
be filtered as much as possible before this point.
This was problematic on some views where two views with the same priority could be chosen depending on the server, postgresql version and the age of the captain
When the registry is updating, the view verification only validates the views
from initialized modules. Not taking the current module allow update of views
that have also an inherited view in the same module. The verification of the base view
must not try to apply the old inherited view against it as it may not be applicable
anymore.
After module update, we re-validate all the views of this module. This is needed because
a module can declare two (or more) inherited views that are correct when applyed alone,
but not when combined with others.
bzr revid: chs@openerp.com-20140418141550-7b57b1xl4fx0rgqq
about the columns in kanban view. This allows to display the 'create a new column', as well as 'edit' or 'delete'
options on column in kanban view, based on the users' access rights.
bzr revid: tde@openerp.com-20140417114033-39rez93cmcwask69
Christophe Simonis
Denis Ledoux
Xavier Morel
Martin Trigaux
Fabien Pinckaers
Fabien Meghazi
Jitendra Prajapati
Antony Lesuisse
Christophe Simonis
Stephane Wirtel
Darshan Kalola
chm@openerp.com