previous commit broke some tests. The issue is that the search view
now avoid making requests if there is no action id. But this is an
assumption that tests use, so some slight adjustments have to be made.
Also, this is the moment to give properly the action id to the favorite
menu. Instead of bypassing its parent, it now receives the action id
from the search view.
The search view architecture allowed an 'invisible' attribute in fields. These fields were ignored for the autocompletion and did not appear in the interface. The goal was to allow default parameters to create facets, without displaying the field in the interface. Since that functionality is not used and the new search view does not support it right now, the tests can be removed.
Allow binding an optional `action_id` to filters.
The web client will try to identify the specific
action ID when saving new filters. If no contextual
action exists, the filter is saved globally for
the model.
This will automatically keep filters within their
original menu when there are several menus/actions
leading to a given list of documents.
In some cases the action_id will not match the
filter model, which should be fine (e.g. when opening
a many2one completion popup for model `foo` within
a menu of model `bar`).
It is also still be possible to have a filter apply
to all actions/menus for a given model by manually
deleting the action_id value in the filter
(e.g. via the Manage Filters debug menu).
When updating a filter the action_id value is ignored
so that old global filters will be gradually replaced
by new "local" filters.
Also added an _order to ensure stable ordering of the
filters.
Task #5009
This new autocomplete widget (the one used in the search bar) does not
do remote calls automatically, but on demand. In theory, it should lead
to a better user experience, not having the ui blocked every time long
remote calls are done.
It also has the benefits of bringing us one step closer to not
depending on jquery.ui. Bonus point: the code is quite short (< 200 loc
i believe)
* oe_searchview_custom has been split in oe_searchview_custom and
oe_searchview_filter: a test need to take that into account
* in adjust_top, the parent might not have a $ method.
to accomodate the fact that the searchview has been changed.
Two changes need to be accounted:
(1) the drawer html structure has changed (oe_selected class is
replaced by badge, some li tags are replaced by spans, ...) and
(2) the CustomFilters has been split into CustomReports and
SaveFilter, so there is an extra filter in the drawer inputs.
Also, the searchview need a parent to react to the switch_mode event,
so the tests add a fake parent to the view in make_search_view
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
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
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
Géry Debongnie