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
e.g. @domain="[]" would be seen as non-empty by the search view, and
if multiple domains the search view would generate a nonliteral
``['|', '[]', '[]]`` which would just yield ``['|']`` after evaluation
and concatenation, which is an invalid domain and would blow up the
server.
Specifically filter out the values ``[]`` and ``{}`` from filters
bzr revid: xmo@openerp.com-20121129112413-yrgncnesqs093jwf
when creating the instance, set instance.session.uid to 42 so the evaluator has something to chew on when it tries to create the evaluation context
bzr revid: xmo@openerp.com-20121120101733-b0ire11bbuywfi8u
* mock(:) callback receives a pair (args, kwargs) not raw params
* list buttons test triggers domain evaluation, which depends on form (why???)
bzr revid: xmo@openerp.com-20121116115544-cdowx66w3m8inqon
simplify code and make setup & teardown processes more reliable
add testing.Stack tools which stacks promise-returning functions
around the actual promise-returning function to execute (the test case
itself).
testing.Stack returns an object with 3 methods, ``push([setup][,
teardown])``, ``unshift([setup][, teardown])`` and ``execute(fn,
*args)``. ``push`` and ``unshift`` create a new stack with the
provided setup and teardown added respectively at the top and bottom
of the stack.
``execute`` will walk the stack from bottom to top executing ``setup``
handlers (and waiting on their result), if all setup handlers execute
without failure the ``fn`` callback gets executed (and waited on) then
*all* ``teardown`` handlers are executed from top to bottom:
| setup
| setup
| setup
| setup
| fn
| teardown
| teardown
| teardown
V teardown
If a ``setup`` handler fails (the promise is rejected), teardowns will
start executing *from the previous level* (so the ``teardown``
matching the failed ``setup`` will *not* be run), but all
``teardowns`` below that will be run regardless, even if one fails the
next one will still be executed.
The stack will either ultimately return a promise rejection using the
*first* rejection it got (a rejection may be cascading, so the
rejection of a setup may also lead to or be linked to a teardown being
rejected later), or will return the resolution from ``fn``.
If ``execute`` is passed further arguments, those arguments will in
turn be forwarded to ``fn`` as well as all ``setup`` and ``teardown``
handlers.
bzr revid: xmo@openerp.com-20121116071712-zuld957icellezum
the onwrite handler created an "empty" record with no field value
whatsoever, which'd blow up in the py evaluator. As during creation
(edition of a record where all fields are empty) create a record where
all fields are set to ``false`` so rendering works correctly, and wait
for content refresh to get correct data.
Also added a test for @on_write
bzr revid: xmo@openerp.com-20121112150526-vrr66ms95qbuoped
The facet removal from its last value being removed
(`this.remove(facet)` in the 'change' handler of the SearchQuery)
broadcasted its `remove` event, triggering the `do_search` (and
repaint) hook of the SearchView a second time right after the
`change`-triggered search.
Not only is this unnecessary and duplicated work (the `remove` is a
sync operation, so searchview-attached events haven't yet executed by
the time `remove` is called), the listview really doesn't like getting
a ``search`` signal while it's already executing a search.
So fix that.
bzr revid: xmo@openerp.com-20121018124005-6vfi7tqasz32ai8v
niv-openerp
Xavier Morel
Christophe Simonis
Olivier Dony
Anand Patel (OpenERP)
vta vta@openerp.com
Raphael Collet
Fabien Meghazi
ggh-openerp
Vidhin Mehta (OpenERP)
Antony Lesuisse