the height of the oe_view_manager_header is variable, and the top can't
be positioned correctly with pure css without a lot of work, so this
commit adds a touch of javascript to make sure that the view is
correctly positioned.
* 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.
* separate the css class oe_searchview_custom into oe_searchview_custom
and oe_searchview_savefilter to be able to style them independently
* by default, the drawer has display:none
* fix a bug occuring when the user removed a custom filter (it hid the
remaining filters)
the header height is not fixed, it can change when the breadcrumbs
start a new line, or when there is only one view type (for ex, in most
reporting views). So, the top value of the view_manager_body has to be
adjusted accordingly.
after some thought, the extra method insert was not really necessary.
It was at first a way to force the user to give two nodes to determine
where the searchview and the drawer were to be inserted. However,
the second node can be omitted, a perfectly reasonable default is
to append the drawer just after the searchview.
Then, the role of insert is exactly the same as appendTo, so it makes
sense to override appendTo and remove insert. Simpler, and the job is done.
this commit splits the widget CustomFilters in two widgets:
CustomReports and SaveFilter. CustomReports is the widget
displaying the list of reports, and SaveFilter obviously is the
Save Current Filter widget.
The goal was to put the custom reports in the first column and the
Save Current Filter form in the second.
Before, the searchview and the searchview drawer had to be instantiated by
the user and appended separately to their correct place. Now, the
searchview is responsible for creating/destroying the drawer, and the
user is responsible for correctly using the insert method with
the node where the searchview/drawer are to be inserted.
the searchview has been splitted in two widgets: SearchView and
SearchViewDrawer. They are dependent of each other, so a drawer
has to be created for each searchview. This was not the case in
some form views (inline, created by a wizard).
the drawer wasn't closed when switching views, which might be a
problem when the user switches to a form view. Also, renames the
variable 'searchview_drawer' to 'drawer'.
incomplete work. So far, the search view widget has been split in
two widgets: SearchView and SearchViewDrawer. The SearchViewDrawer
has been inserted inline, and some preliminary work has been done
to improve the layout.
The following fixes have intentionally been reverted,
as the code has significantly changed and the bugs cannot
be reproduced:
- web_calendar fix (revid:dle@openerp.com-20140214114258-0hcsfdwyl61gph0v)
- CSS fix for buttons (revid:mat@openerp.com-20140213145755-txvtwqbfc83vnw9o)
bzr revid: odo@openerp.com-20140217102806-qg6kwk2jomdvvmlj
Closing previously occured on search request (so that a user wouldn't be able
to select "old" data on new search request), but ``search`` is only triggered
after the search delay. Worked when delay was 0, with it being moved to 250 a
user can get results matching the previous search instead of the current one.
Trigger a closing of the current results list on any ``input`` event, which is
when text is entered in any of the searchview's ``InputView``
bzr revid: dle@openerp.com-20140210140032-06dnlxepcc5ae21f
Closing previously occured on search request (so that a user wouldn't be able
to select "old" data on new search request), but ``search`` is only triggered
after the search delay. Worked when delay was 0, with it being moved to 250 a
user can get results matching the previous search instead of the current one.
Trigger a closing of the current results list on any ``input`` event, which is
when text is entered in any of the searchview's ``InputView``.
bzr revid: xmo@openerp.com-20140210123416-cfc0x24bfkiv4lse
Depending on the way the search view is setup, a single item
(e.g. "Search foo for bar") can follow a list of a bunch of
completions. In that case, it is hard to notice that it's not just one
more item of said list.
Add a marker on the first of every completion list in order to catch
1-item lists (or lists without titles/categories) and prepend a small
border every time, so that single-element completions following
lists-with-titles can be noticed.
bzr revid: xmo@openerp.com-20131107112858-1xyvcesize0doblz
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