The pager was not displayed in One2Many List views. This fix applies the
same behavior as in One2Many Kanban views, which is probably not the
best way to do it, but which works fine.
The issue was caused by 2 things:
- The One2Many.FormView template removes the condition around the
buttons/pager divs of the FormView template. However, it was using a
selector that does not seem to be used anymore. We thus removed it
and the buttons/pager divs are now in the rendered One2Many List View
- The rendered pager was appended to this.options.$pager whereas it
should be appended to the corresponding div in its own template.
This commit should not be forwardported
Apparently, browsers decide how they want to style readonly inputs,
and it seems like Firefox is greying them out while Chrome doesn't.
We use an opacity: 0.5 rule to grey them out ourselves in Chrome,
but in Firefox they are not dark enough to read easily because of
the double greying. I checked with the designers but they don't
have any better fix for that.
The graph view is supposed to load in a given mode, as described by the
type attribute ('bar', 'line', 'pie'). However, the type attribute in
the fieldviewget was ignored, which means that the graph view was
always loaded in bar mode.
In some rare cases (non stored functional fields), the pivot view should
allow it as a valid measure. This commit changes the pivot view in such
a way that any explicitely defined measure will be added to the list,
even if it should not work, like for the non stored functional fields.
The pivot view has no way to know if a generic model has overrided the
read group method in a correct way to make it work, it is up to the
developer to make sure that measures defined in the xml are valid.
On a line write in a account.move.line tree view, the on_write return all the
sibling move lines of the written move line. The lines are then displayed even
if they do not match the current search domain.
This fix adds the context on the given on_write callback request, and in
on_create_write use a on_write_domain in this context to filter the returned ids.
fixes#3161, closes#5727
opw-630093
The datetime widget use the "keypress" event to detect if it has been
changed. Unfortunately, some keys, such as backspace, do not fire a
keypress event. This commit listen instead on the 'change' event, which
should fire when the input has changed.
Currently, the view_form search_count doesn't propagate the context, so when
searching on a translated field, the count can be different than the one we
would expect and get with a search in a current language different than en_US.
opw-628792 opw-630212 closes#5825
The sequence for new items in some models is simply set to a constant 10.
Hence if 3 items had after reordering sequences 10, 11 and 12. If a new item is
added, it would get after saving at the second position.
This fix set the sequence of a new item to the maximum+1 or minimum-1 sequence
of current items sequences (max if tree has editable="bottom", min if tree has
editable="top").
opw-627830
This temporary patch was used to simulate the presence of a
`display_name` field in all models. It is not needed anymore
as of version 8.0, which comes with the actual magic to make
`display_name` work everywhere.
first, I want to say that I'm not proud of this. Let's just say that it
is better than the previous code (of which I'm not proud either).
The issue is that the sub menus (filters/groupbys/favorites) aren't very
good when their height is too big, and they're hidden below the screen
without scrollbar. Previous code tried clumsily to compute the correct
max height in js, but it was only done in filters menu, and did not
always work. This code do the same in css. This would be good except
that it is just an estimation: calc(100vh - 125px). It assumes that
the header will approximately take 120px, and size the max-height
accordingly.
The signature and behavior of function template() of underscore.js has
been changed from rev. 1.7.0. It doesn't accept an initial data object
anymore, and always returns a function.
This commits adapts our calls to _.template(). This fixes display bugs in
list views (e.g. the progressbar which was not displayed).
This patch removes the asynchronous code that was
still used to open the autocompletion drawer.
Even with the setTimeout delay forced to 0, the
asynchronous handling meant the final ENTER
keyUp event could be processed before the opening
of the autocompletion drawer related to the last
key pressed. This would trigger the search with
the search string of the previous autocompletion
popup, missing the last few keys.
Also handle ENTER at keyDown, because in some
rare cases a barcode scanner may emit only
the keyDown event for ENTER, without the
corresponding keyUp, causing a merge of two
successive scanned barcodes.
Based on many tests conducted with different
barcode scanners, the only thing that
is guaranteed is the correct order of the keyPress
events for all regular characters, and the
fact that the ENTER keyDown and/or keyUp will
always be sent after them.
All other events can be mixed or simply missing
if you make a rapid succession of scans, especially
if done with a long series of barcodes.
Scanners tested (with 1ms data transmission delay):
- Honeywell Eclipse MS5145
- Dacomex Slim 50mm CCD scanner
* when users press ENTER after editing some custom search, the resulting
filter is now applied.
* when users press ENTER in favorite menu, save current search, the
current search is now saved
if the graph view is set in bar mode, and does not have any groupby,
then it tried to read some property from its viewmanager, which results
in a crash. It is most likely the remnants of the old code, this commit
correctly sets the string to the current measure.
The menu was not present in 8.0 when going back from the mass mailing email
composer to the backend. This fix adds the current action id as a return_action
query string parameter and return to the correct action.
fixes#5591
opw-629526
This patch hopefully solves an annoying issue with the search view:
when the user types really fast (or uses a barcode scanner for example),
the resulting search string was (sometimes) missing the last few
characters. I'm unclear on the exact reason why it happens. From the
code, I can only guess that it happens because the scanner use a TAB
key instead of ENTER (TAB is handled in keydown event, ENTER in keyup),
or that the key events aren't in a correct order (if the user press a
key A, then press ENTER, then release ENTER, then release A, it results
in an empty key).
Anyway, the way this patch probably solves the issue is by using the
keypress event for triggering the search view. I hope that in every
case, the keypress event are correctly ordered. It leads to some code
I'm not really proud of this patch, but the key event handling are
quite messy. Also, I need to handle the search string also when the
keyup event is fired, because it might change the search (for example
backspace trigger a keyup, but not a keypress).
This search view option was properly set but not
observed by the search view itself.
This caused all related links and smart buttons
to open a list of records that was wrongly filtered,
as soon as a default filter was applicable to the
target action (e.g. with default filters gloablly
set per model, not per action).
This regression was introduced at refactoring
commit d8d6311b50
Allows exporting fields whose string is a non-ascii *byte*string (rather than unicode).
backport of 7286f4e424 fixing #773 to branch 7.0 by request of @flotho
This issue is related to
http://bugs.jqueryui.com/ticket/8656http://bugs.jqueryui.com/ticket/8749https://github.com/jquery/jquery-ui/commit/d693ce5324f6f3be8479ef083e4eaf3c705ef043
When opening a form view, scrolling down,
and opening a many2one dropdown menu,
the dropdown menu wasn't directly under its input.
It could be really problematic when the menu was not even
visible on the current browser page (when you had to scroll down
a lot to access the many2one input).
The issue was resolved as soon as you opened the dropdown
menu a second time, and did not happen if you didn't scrolldown.
But, on initialization, the dropdown menu wasn't at the right position.
Fixes#5603
opw-629601
Text fields, or char fields having widget="text",
were not sized correctly when the field was not
visible by default, ans was set visible thanks
to attrs and other fields values.
opw-629394
Aaron Bohy