Looks slightly worse as results don't seamlessly update in-place, but
limits/avoids the risk of quick-typing, hitting [Return] and getting
an incomplete/incorrect query because the completion didn't catch up
(e.g. slow network) and [Return] validated the previously retrieved
completion.
lp bug: https://launchpad.net/bugs/1183746 fixed
bzr revid: xmo@openerp.com-20130605144949-jbzs2hppr6c1djg3
Added the missing complete() function and removed the incorrect
value_from() override that seemed to be a leftover remnant
of the 6.1 search field implementation of get_value(), wrongly
renamed for 7.0.
bzr revid: odo@openerp.com-20130328120337-lao4o9i0owsbpysi
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
niv-openerp
Olivier Dony
Xavier Morel
Christophe Simonis
Anael Closson
chirag patel
Thibault Delavallée
Fabien Meghazi
Bhumi Thakkar (Open ERP)