In the Filters, Group By and Favorites dropdowns,
when clicking outside the `li` elements but still
inside the dropdown menu itself
(like on the dividers,
or next to the advanced search `Apply` button),
the dropdowns was closed.
This behavior was annoying when doing an advanced search
with a field using the datetime picker, as, to close the datetime
picker, you have to click outside it, and when you did, it closed
automatically the filter dropdown... So you had to open it again to
finally apply the filter.
opw-674310
When we download a file (as can be done with attachments in Odoo),
firefox is opening the link in current window but cancel the action once
it is aware the resource is to be downloaded.
But this get firefox into a corrupt state for some contenteditable
features, for example document.queryCommandState which is needed for the
editor will after downloading a file throw an error consistently instead
of working as expected.
It can be reproduced on firefox (at least from version 32 to 46) with
the following snippet:
https://jsfiddle.net/s246u3ay/3/
The issue is probably linked to the following reported issue since 2005:
https://bugzilla.mozilla.org/show_bug.cgi?id=297494
This commit avoid the bug by opening attachments download links in a new
window instead of the current one.
closes#12109
opw-676918
The left margin of the graph doesn't take into account the width of the
maximum Y-axis value. In case the values are high (> 10^7), they are
cropped.
The fix is to adapt the left margin as a function of the size of the
maximum value.
opw-676538
Before this commit, in some cases, clicking on 'save' button, then on
other buttons (like 'validate' in invoices) had the unfortunate effect
of applying twice the changes in some cases.
More specifically the problem appears when:
1. an onchange is triggered (for example, taxes in invoices)
2. the user clicks on 'save', buttons are disabled
3. the 'save' actions is completed, the buttons are enabled, but
the on_button_save still does some work: triggering event, and
reloading the view
4. the user clicks on 'validate'
5. the onchange completes, this triggers some more work
Our only protection against such interactions is right now the fact that
buttons are disabled/enabled. In my opinion, there should be a way
to guarantee that actions are properly serialized (that is actually what
a mutex is for... just saying). But the code of the form view/list view is
too coupled, and such changes are quite dangerous. A real refactoring
of those is needed at some point in the future.
When the user searches for date (or a datetime) in the search bar, the
suggested date can become completely wrong. For example, in the French
localization where the date format is DD/MM/YYYY, the system will search
for the date MM/DD/YYYY. This is even worse when the date is not fully
written: DD/MM could be converted to MM/DD/0000, which doesn't make any
sense. This is related to the moment issue
https://github.com/moment/moment/issues/1407.
The fix is to make sure that the input date has a correct format thanks
to `parse_value`. The latter converts the date into a fixed format.
Fixes#11876
opw-676604
When clicking on save several time when editing a view form it can be
saved several times which can be an issue for one to many.
The normal happenstance when saving should be as follow:
-> save (click)
-> wait write result
-> received write result
-> reload the form with updated data and updates buttons
But when clicking several time, it could become:
-> save (click)
-> wait write result
-> received write result
-> save (click)
-> wait write result
-> received write result
-> reload the form with updated data and updates buttons
This commit only reinstate the saving feature once the form is reloaded.
closes#11926
opw-671793
note: no need to forward-port
The current behavior was allowing going on the previous row if the
user is at the start of an editable element and on the next row if the
user is at the end of an editable element. The problem was, we did not
want this behavior when the editable element is a select or m2o (as
the up and down input should open the select/m2o dropdown instead).
The read_slice method in dataset is problematic, because it alters the
dataset ids. So, if 2 consecutive read_slice are started, but the first
one ends after the second one, we don't have the correct ids in the
dataset.
This commit just make sure that previous read_slice do not alter the ids
of the next read_slice.
Makes the fix in f992c8ee19
specific to the view manager of the main oe_application
container, in order to avoid disrupting other view manager
occurrences (such as the ones in modal windows or x2many
list views).
Fixes#11629 (again)
Note: Hopefully the Blink team will fix Chrome so we can
get rid of this hack in the future:
https://bugs.chromium.org/p/chromium/issues/detail?id=603507
The list view Column widget should be exposed, so it can be extended.
This is required to allow the creation of other kind of list widgets.
The _format method is not extendable if we don't add this line.
(comment from ged) The file list_view.js should be split in two, and
reorganized, but this should not be done in 9.0.
e8a00bc50d moved the get_file function
from web.session to web.ajax. The issue is that get_file uses
session.url() for iOS devices. Also, in order to prevent an infinite
spinner options.complete() is called before actually opening up the new
window. Although this resolves the issue it still requires the user to
configure Safari to allow pop-ups, otherwise they are silently ignored.
opw-672882
Following commit 8276fb585, the data exported should match the data
displayed on the list view. Therefore, we need to make sure that the
context used match the context of the list view.
When a filter is applied in the list view, the context is evaluated
thanks to pyeval (see the call to `/web/dataset/search_read`). The fix
is to evaluate the context in a similar way.
opw-674473
- Fix for status widget (b25c054c93) moved
to appropriate file: addons/web/static/src/js/views/form_widgets.js
even though the problem is less severe in 9.0 (no crash but triggers
form save, which is unnecessary)
- Fix for website_event_sale ignored (880e951f34)
because the problem does not exist anymore in 9.0, probably due to
refactoring 66871ee65b
When the warning on form view is closed by cancel or OK button, all is
well. But if the modal is closed by any other way the def will stay pending
blocking next operations.
This commit set the deferred as dejected if not resolved when the modale
is closed.
closes#11688
opw-671371
Current behavior before PR: if you create a new record within a one2many
field and the model's form has a clickable status bar defined, clicking
this status bar will raise an exception because the virtual id
(one2many_v_XXXX) will be passed to the model's write method
Desired behavior after PR is merged: clicking just changes the cached
value
For some reason, it was lost. Probably in the graph view/pivot view split.
This commit simply accepts the attribute, but default to true, so nothing
changes unless you have explicitely set it to false.
Also, fixes en error introduced by a forward port (the use of
openerp.web.format_value)
The editable list view method 'edit' is supposed to wait for the
record to be completely loaded. But when loading the defaults values,
it ignored the actual loading and completed too early. This commit
chains the deferred with the form record.
I recently removed some rpc from init fieldmany2manytag (it was in a
mutex) and moved it to the willStart method (without mutex). The
fieldmany2many tag widget needs this information before it can be
rendered. However, in editable list views, the rendering engine does
not wait for the fields to be ready before completing its initialization
process. As a result, the field many2many tag was rendered before it
was ready, which broke various things, including its position.
This commit attempts to bring sanity to this issue by making sure that
the rendering engine waits for its fields to be ready. Also, the
editable list view should detect correctly when the form is loaded.
If this commit introduces new issues with the editable list view and
onchanges, I will not be pleased. You don't want to bring me this sad
news without at least something to buy my good will.
We have an interesting problem when editing all custom float fields and all
fields with no explicit digit attributes: the propertiesmixin tries to
check if the number was changed, according to their declared precision.
But for these specific fields, it does not find a digit attribute, and
defaults to 2. Then, it makes sure that the changes are ignored if the
new value is too close to the old value (with 2 digits precision)
For example, if the user sets the value to 1.234, then save, then change
it to 1.235, then save, the form view will display 1.234 and totally
ignore the change.
Not that handling the digit precision is done in the propertiesmixin and
in the field float widget. Also, they do different things, and in some
case, may not be the same. All this logic should be moved to the
fieldfloat widget.
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
the widget FieldMany2ManyTags does a rpc to fetch the fields (just to
know if 'color' is in the model...). It was done in a mutex and used
later in a mutex. This commit simply use the willStart method to make
sure the data is available before rendering.
Denis Ledoux