Create a new stylesheet for IE9 and less custom css.
The issue #6198 and #6201 is present in IE9 since a div with height 100% inside
a table-cell (i.e: td tag) element only take the minimum height possible for the
content.
For issue #6198: in IE9 a kanban tile could not be moved to an empty kanban,
this fix sets a minimum height for a empty column (80px, the size of two empty
tiles) so now a tile can be moved in the 80px in the top of the column.
For issue #6201: graphs took the minimum height in IE9, this fix set a fixed
height to improve the situation.
For issue #6200: in IE9, the list view could wrongly not go the next line
even if its width is 100%. For the given case, the display CSS property of
these listview is set to value "block".
opw-632415 opw-632417 opw-632416
Do not check float_is_zero for float fields with
digits specifically set to 0, it means
the rounding precision is infintie for those ones,
and tmp === val is enough.
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.
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
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.
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
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 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
Rewrite relativedelta.__add__ based on dateutil 2.4.0
* completely remove any hint of supporting time deltas (could be
implemented in the future, but not currently asked for and lots of
code to implement)
* implement weekday support (ordinal only)
* probably better leapyear support
* remove relativedelta.__sub__ (only works between relativedeltas)
* add relativedelta.__neg__
fixes#5089
The priority widget did not handle the readonly concept
It was therefore possible to set the priority of
an issue (for instance) even if the field was marked
as readonly.
opw-628960
When accessing an existing record in form mode directly (enter the url or refresh a page), the daterecord has not been initialized yet. This means that the value of actual_mode will be set to 'edit' before loading the current record (method _actualize_mode() called from do_show()).
This was problematic for one2many fields that we loaded in edit mode, showing add/delete icons/buttons in readonly views. (opw 607910)
Backport of 7ec7f1ba40 for 7.0 and saas<6. (opw 627885)
When the number of records n and the limit l were such that n%l = 0
(e.g. 16 records total, 8 displayed per page), clicking on the
previous button on the first page, or on the next button on the
last page produced a bug because the total number of pages
computed for this edge case was incorrect.
27a48f8026 introduced the use of self.dataset
It appears it is not always defined.
Few lines above, self.getParent().dataset is used,
and looks to be always defined.
We therefore now use this dataset in order to get the context,
to correctly pass the current session language.
Closes#5416
This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
Without this, if the user creates a second line (or more) with another search query and presses tab (or clicks somewhere else) quickly, it will take the previous search result instead of the new one because the new one did not occur yet.
With this fix, if the search did not have time to process, the Create a product modal appears, just like it already did for the same behavior on the first line.
Fixes 620679.
When having several databases in the login form (not monodb mode),
when switching from one database to another,
if the company logo was different,
the company logo could be the logo of the database you came from.
fixes#5291
opw-628131
When clicking on an element in a listview editable, the record_id
is not updated in the dataset, which means that when you switch to form
view, the list view does not display the last selected record.
Also, it should fix the issue solved by PR pull/2725
During the refactoring of the web client, the self.$el has been changed
from .openerp to body, so the notification was no more into the .openerp container.
Custom css (eg .highlight) was no more applicated.
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
The onchange() on new records processes fields in non-predictable order. This
is problematic when onchange methods are designed to be applied after each
other. The expected order is presumed to be the one of the fields in the view.
In order to implement this behavior, the JS client invokes method onchange()
with the list of fields (in view order) instead of False. The server then uses
that order for evaluating the onchange methods.
This fixes#4897.
Nicolas Lempereur