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
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
Before the valpocalypse, filter contexts were "literal" (parsed
objects) when reaching the search view, and `.attrs.context.group_by`
would return the right thing (namely the group_by attribute of the
context object).
After the valpocalypse, contexts & domains on view fields (and
filters) are not evaluated on the Python side anymore and reach view
objects as strings, the access chain above thus always returns a falsy
value (undefined) as strings don't have a .group_by.
Fix FilterGroup to correctly parse filter's @context before trying to
see if it has a group_by.
lp bug: https://launchpad.net/bugs/1116432 fixed
bzr revid: xmo@openerp.com-20130307124222-1ypzfopbktxmad4z
xmo@openerp.com-20130305093619-s1e5fbl80r7qnk5l added zIndex on wrong
element of search view (view itself instead of just the autocompletion
drop-down) leading to the search view text field being visible over
the "more" section of the menu.
Move zIndex setting to the right place (on the missing
`autocomplete('widget')` indirection, and on open as jquery ui
autocomplete apparently decides to reset the dropdown's z-index each
time it is open)
bzr revid: xmo@openerp.com-20130306110051-1wfhxaylsn71skjp
The search view's completion list should be in front of the search
view's drawer, which itself should (probably) be on top of the graph
view's "action" dropdown.
The graph view's dropdown itself needs a z-index > 0 to be in front of
the graph itself, otherwise it is inactive and unusable: it's visible
through the graph but not activable.
bzr revid: xmo@openerp.com-20130305093619-s1e5fbl80r7qnk5l
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
Navigation implementation can only deal with straight text (and
asserts that), if HTML is pasted in a search input
InputView#getSelection will throw errors and refuse to act.
Clean up input content after a paste event, to ensure only plain text
is present so it can be navigated.
Don't forget to correctly re-set the cursor at the end of the input
data, otherwise the user will face various deep DOM errors when trying
to move around the input with the arrow keys (which he would usually
be able to do after a paste).
lp bug: https://launchpad.net/bugs/1102237 fixed
bzr revid: xmo@openerp.com-20130123091600-nd4rwqpin6qj8ult
If the filter is executed first, the "iteratee" is transformed to an
array (from an object) and the "key" is lost, replaced by the indices
to the array (and thus the name of the fields end up as "0", "1", "2",
... instead of their actual logical names)
bzr revid: xmo@openerp.com-20130123084422-tbl05l5j72sx528n
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
handler for "global click filtered by whether click target is outside
of search view" executed after prop deletion handler has executed =>
the whole proposition has already been removed from the document and
thus isn't a descendent of the searchview anymore => test matches and
drawer closes.
Altered handler to stop propagation so does not reach global handler.
bzr revid: xmo@openerp.com-20121106144736-l0pde7phf3nake4t
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
ensures consecutive searches of the same element will behave correctly
(trigger a new autocompletion instead of nooping the second time
around because the new value is the same as the old/stored one)
bzr revid: xmo@openerp.com-20120726113105-d73fere31qdy8wda
Required reifying the purely decorative spyglass (created via :before)
into an actual button and moving that button to the right place (after
removing all decorations set by default on buttons e.g. shadows &al).
apr request.
bzr revid: xmo@openerp.com-20120724124607-bc1nsywtth7cn11i
Just because the search_default is an array does not mean it's a
name_get apparently: there are many cases of a single id wrapped in an
array (``[id]``).
So ensure that the search_default is an array *of length 2 whose
second element is a string* before considering it a name_get and using
it as-is (without resolving the label via an explicit name_get).
Also, error out for any m2o search_default which is an array of length
> 1 (unless the second element is a string as per description above).
bzr revid: xmo@openerp.com-20120724115659-l0n0gjr91bcop13z
Xavier Morel
niv-openerp
Thibault Delavallée
Fabien Meghazi
Olivier Dony
Bhumi Thakkar (Open ERP)
Vidhin Mehta (OpenERP)
vta vta@openerp.com
Vishmita
ggh-openerp
Antony Lesuisse
Christophe Simonis