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
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
Xavier Morel