There seems to be a problem with QUnit's serialization routines when
applied to complex widgets (the view here) while running inside
PhantomJS. It does not seem to be cycles in datastructures (that is
handled) but looks related to complex objects linked from multiple
"children" (skipping any object already serialized makes the issue
disappear).
The bug leads to unbounded memory growth, and on runbot to the process
being summarily terminated (likely by the OOM killer) not even
resulting in an OOM error (which is displayed locally). The issue can
not be observed within browsers. This may be a difference in GC
strategy.
The serialization is applied by the driver on high-level comparison
methods (e.g. strictEqual) so the caller can display the structures if
desired.
Replace the strictEqual(a, b) call by ok(a === b) to avoid any risk of
such serialization.
bzr revid: xmo@openerp.com-20130801091326-u2q9e163zls4k8ad
JS objects are converted to py.object when passed in through the
evaluation context. py.object are not serializable by default (because
that doesn't really make sense), which breaks when the input is
intended as a dict and returned (e.g. o2m values, which are triples of
(int, int?, dict?)).
Intuitively, JS objects passed as part of the context should be mostly
JSON-ish and thus dicts, but that turns out not work work as some
addons use attribute accesses within contexts (e.g. parent.access in
account/account_invoice_view.xml)
=> Temporarily solve by converting raw js objects to an "attributed
dict" which acts as both a dict and an object and can be converted to
JSON.
Ideally, py.js should provide for a pluggable conversion, or should
use an attributed mapping internally. See issues 21 and 23.
lp bug: https://launchpad.net/bugs/1182101 fixed
bzr revid: xmo@openerp.com-20130624055929-3rtkgqrp4o87pvau
integer/float fields were not offering auto-completion in search views,
making them unsearchable except via advanced search.
This patch adds the missing complete() function and removes the incorrect
value_from() function that did not conform to the 7.0 search view API.
It seemed to be a leftover of the 6.1 search field implementation
of get_value(), wrongly renamed for 7.0.
Also includes corresponding tests.
bzr revid: odo@openerp.com-20130418112001-388op1t8ugr0rhfn
If there are no grouping field specified *but* group_by_no_leaf is
specified, should call read_group with no grouping fields: will
generate a single group (which can not be opened) for all of the
model.
Necessary for analysis views since individual "records" make no sense.
bzr revid: xmo@openerp.com-20130416092344-2pqog8f7xprn6hsh
Implementation of invisibles in search view altered handling of search
inputs: their parent may not be the searchview anymore (usually is a
instance.web.search.Group). GroupbyGroup assumed parent was view and
was actually unused until
xmo@openerp.com-20130307124222-1ypzfopbktxmad4z, which exposed the
incorrect underlying assumption.
Make GroupbyGroup access its view when it wants its view, not its
parent.
bzr revid: xmo@openerp.com-20130312092824-z7sh4h3ityo4g00v
This leads to any subsequent view overwriting the current user's lang
or timezone with the one active when the filter was created,
generating dismay and discontent (e.g. part of the user interface
switching from spanish to english or english to german, depending on
the respective settings of the current user and the filter creator —
at time of filter creation).
bzr revid: xmo@openerp.com-20130304101414-mm6ai1dkltd7ard5
On click on a filter in the drawer, FilterGroup would just match the
offset of the filter in the group's DOM with an index in the internal
#filters array.
This worked until invisible fields, and then again only for filters
*preceded* by an invisible sibling in the same group: invisible
filters are not rendered in the DOM, so the indexes would get out of
sync.
Fix by using explicit indexes stored in a filter's @data-index and
using that to get the filter object/node.
An alternative fix (but hackier I think): instead of not rendering
invisible filters, render them with display: none. Remains an option
in the future if needed...
lp bug: https://launchpad.net/bugs/1157125 fixed
bzr revid: xmo@openerp.com-20130321155123-211iht7c6zme712e
Olivier Dony