A related field used in a group by (filter with group_by in context)
which isn't stored on the model, but stored in the related model should
be allowed to be grouped by uppon on a pivot view.
In 8.0 it wasn't the case, but when adding it as a
<filter context="{'group_by':'field_name'}" />
it was added in the list of fields.
In saas-6 these group by are only available in the search view, but in
some instance (the field is not stored directly on the model) this could
lead to an error which is fixed by this commit.
closes#8349
opw-647401
In 36146b3f setting the date of the datetimepicker was done when it was
opened, but only for widget datetime. Thus we could get an issue for a
widget date when we wanted to use it to select two same date.
e.g if we select 23 september for a date, it works. if we then use the
widget on another date, 23 september is selected and it will not trigger
a value change if we leave this value.
This fix adds the date setting when opening the date widget, and also
prevents the bootstrap datetimepicker feature* of closing the widget
when setting the value of the date-only picker.
closes#8506
opw-648619
* this feature is explained in the following issue:
https://github.com/Eonasdan/bootstrap-datetimepicker/issues/603
On a first edition of a view list editable, scrolling before the first
edition might cause an issue: the editing fields are higher than they
should.
This commit solves this.
This issue stems from jQuery .offset({value}) function which is broken
if the element we want to position:
- is in absolute postionning,
- is inside a scrolled element in non static positionning,
- has not both top and left css property setted,
- has no ancestor element between itself and the scrolled not in static
positionning.
This issue happens less (and probably not at all) in saas-6 since the
last condition is most often not met thanks to this change:
https://github.com/odoo/odoo/commit/1ccd87a#diff-27c072074221456684bfc5f150ca0bc9R876
This issue of jquery is solved since jquery 3.0.0-alpha1:
https://github.com/jquery/jquery/commit/2d71594
( the issue is shown in https://jsfiddle.net/wpjrnggf/ and we can see it
is solved with jQuery 3.0.0-alpha1 https://jsfiddle.net/L6ykpjgy/ )
closes#8251
opw-647622
The custom filters were not translated in the user language(FR) when:
-Going to Marketing / Mass mailing
-Creating a new one
-Selecting "customers"
-Clicking "select records"
-In the modal, clicking Filtres / Add custom filter
To have the user_context, the context sent to fields_get must be taken
with get_context.
opw:647495
Before this rev., the number of records per page to display in list views
could be specified in the action definition, but it didn't work for One2Many
list views (because they are instanciated by a FormView, which isn't supposed
to have a reference to the action, instead of the ActionManager as regular
list views).
This rev. allows to specify the list_view's limit directly in the definition
of the view, and not only on the action as before.
In internet explorer, writing direction can lead to wrong text direction
when combined with rotate.
A fix was already in place for IE up to version 9 but the issue also
happens in next versions which are more difficult to differentiate
(especially the current spartan/edge version).
So this fix use the same css property value for all browser and it doesn't
seem to have an impact (other than correcting the issue in IE).
closes#7955
opw-646430
When two first notebook pages are invisible, the shown page will be the
second invisible one.
With this fix, all oe_form_invisible classes are added in the init stage
of the NotebookInvisibilityChanger object.
opw-646740
note: good for saas-6 but not next versions, see opw-639595
Bootstrap bind on document to do an element, in some case the bounce effect
on the edit button might cancel the bootstrap action.
e.g in the crm.claim form view, the `group` tag arround a notebook element
break the tab change on the notebook.
opw-646012
note: in 8.0 the issue didn't happen since the tab change was done by
jquery ui which happened before the bounce effect.
In previous releases, the search view ignored the selection widget when
the field is a many2one. This behaviour is justifield by the fact that
the selection widget just doesn't work, and the default search input
actually does work.
The search view was refactored extensively in late 2014, and this
behaviour was lost. As a result, every many2one with a "selection"
widget stopped working (for example, warehouse/products, a search for
"you" does not give anything on "location" or on "warehouse"). This
commits simply fix the issue by ignoring the selection widget in search
views (with many2one fields).
If too many tags (or too long tags) where present in a many2many tags
widgets, it could go over the field and cover other thing in the UI.
Now the field size expands with the content (and in a way it is more
visually similar before and after 'Edit' so it is nice).
closes#7579
opw-644236
When you clicked on "Search more" to add a product in your lunch order,
the default filter didn't appear because the wizard didn't contain an action id.
Introduced by 5cd78b8
The bug solved by this commit didn't appear without the commit.
opw:643951
The behavior of the datetime widget was to focus in the field every time a date
is chosen. This causes an issue if the datetime widget is called from an
editable list. Indeed, the list editable will consider that the value has been
set, and therefore the value will not be changed anymore if the user choses
another date.
The new behavior is to put the focus only when the date picker is hidden,
therefore the editable list will consider the value set only when the selection
is done.
opw-644062
Fixes#7463
When we go from one field to another via the tab key, in the form view what happens is:
{{we get a blur from the current field}}
-> if [[widget was not in state clicked (which can be gotten for example by clicking on a focused field)]]
-> blur event is cancelled,
-> the blur event is set to be triggered soon
-> the clicked state is set to false
{{we may get a focus for the next field}}
-> if [next field get an onfocus event]
-> blur event is cancelled,
So if :
- the state is not clicked and,
- the next field don't get an focus event.
We get a blur event which will either save (if a field value has been changed) or cancel
the form view editing and will hide the current edition, hence losing the focus.
For example, it happens on a readonly fields with field containing an `<a />` tag, on
some browser (for example google chrome), the focus event will not get triggered (it still
work if we were in a clicked state) so we can't cycle thought a list editable cells if there is a readonly field in it.
closes#7446
opw-643718
Don't retrieve the binary contents just to display the size, but pass context
with bin_size=True instead
Always pass filename in download link
Combination of patches from the bug report from Enrico Ganzaroli, Cedric Le
Brouster and Holger Brunn
Fixes#4899, lp:1167429
Don't preload company logo of the wrong company
When a user other than the admin signed in
and was in a company different than the admin
and this company had a different logo,
the company logo (in the upper left corner)
displayed the logo of the admin company,
instead of the logo of the company of this
user.
As soon as the user refreshed the page
in his browser, the issue was resolved,
but the logo should be the good one
from the beginning.
Closes#1453
To distinguish two ir.attachment 'File Content', we base it on the file
size (this I imagine is for efficiency).
This is done by setting bin_size in the context. Doing this, the
returned db_datas field will be the file size of the converted to base64
content (if no filestore).
But this size is returned in string format, so "get_nice_size" (in
openerp/osv/fields.py) which gets this size calculates the length of the
string. e.g: if the size is '2142' get_nice_size will return 4.
This fix solves this by converting the string to an integer, thus
unifying it with the filestore case (where we use os.path.getsize which
return an integer).
Also, the field presenting the issue (FieldBinaryFile) has been changed
so it is always updated even if the size is the same (as it was already
done by 3632949 for FieldBinaryImage widget).
closes#7223
opw-643071
This decision comes from the following bug:
- Go to Sales -> Quotations, and open any existing quotation in form view (the
partner must have an address defined)
- Click on the partner
- Click on the stat button "Claims"
- You notice that the address of the partner is included in the search
This is due to the context property show_address which is set to 1 when a
quotation is open. Therefore, it is necessary to filter out this keyword.
Since the prefix "show_" is used for only few context variables, it was decided
to define this pattern as a standard pattern to filter out.
opw-642893
In css, overflow-x and overflow-y must have the same value. If overflow-x is equal to
auto then overflow-y is equal to auto.
To solve the problem, the height of the input is removed because it is forced by the Jquery
auto-completion plugin according to the wrapper.
Without this patch, when you go to Settings > Import/Export > Export Translation and click on the arrow to
to show the list of modules you can export, the list is partially hidden.
opw:632607
!! THIS SHOULD NOT BE FORWARDPORTED TO MASTER !!
When loading an action with a specific url (e.g. when refreshing the
browser), the view displayed before refreshing should be loaded
directly (except for form views, for which we need the default
view to be loaded first to keep the breadcrumbs intact).
Before this rev, it automatically first loaded the default
view for the model (i.e. the first view in the views' list), and
then switched to the previously displayed view. This sometimes
produced an error when using a filter needing a field not available
in the default view (e.g. Reporting > Project > Issues Analysis,
switch to the second view 'Graph', and then refresh -> Error).
This revision introduces a new key in the View widget: multi_record.
This key distinguishes views that aim to display several records
(e.g. List, Kanban ...) and those that display a single record (i.e.
Form and Diagram). We use this key to decide whether or not the
view stored in the url should be directly loaded (yes for
multi-record, no otherwise).
This reverts commit 291eb111b3.
By putting into the flags object the default_view stored into the
context (i.e. the one written in the url), it happens that a View
Manager tries to open a view which is not available. For instance,
Sales > Sales Teams. Then refresh the page. As we are in a Kanban
view, the view_type = Kanban is stored in the context. Then click
on Quotations in a Kanban card. It doesn't work because the
ViewManager tries to open the Kanban View of the Quotations which
doesn't exist.
When loading an action using a specific url, with
a view_type different than the default view of the action
(e.g. Project > Project > Issues has as view order
kanban, list, calendar, form, graph, and try to load
this menu action from an url, but by specifying another view_type
than 'kanban', for instance, 'list'), the default loaded view was
always the first view, and then a switch was done to go to the view_list.
It caused issues when using a filter needing a field available in the list
view but not in the kanban view.
It also lead to an issue in the reporting, when trying to load a reporting
action with a view not being the first one of the action
(e.g. Reporting > Project > Issues Analysis, switch to the second view
'Graph', and then refresh -> Error).
This revision makes so the view from the view_type url arg is directly loaded.
opw-640289
and the render of the buttons.
The sibar menu can depends on the current view and fields
states.
We therefore have to wait for them to be loaded before loading
the sidebar.
Before this rev., loading a report view (in the reporting menu),
leaded to a crash, due to this revision: ac92551406.
opw-640409
Nicolas Lempereur