Coming from hr_recruitment, where kanban_state is displayed, but without the customization
Also, remove lingering options in view, and missing fields for project_issue
- Change the widget behavior from asynchronous to asynchronous, by adding 3 related fields
on the project.task model, which are the custom labels defined for the stage
- Instead of making a rpc call, we are taking directly the labels on the parent for the kanban view,
or on the view datarecord for the form view
- There are now 2 templates for the kanban view or the form view
- The development has been backported in the community version
- The options attribute has been removed on the project_view.xml file for the kanban_state field
The get_value method of field radio returned sometines an undefined
value (while it is expected to return false is there is no value).
This caused traceback for siblings fields trying to access the value
of an empty field radio (onchange, ...).
* When the autocomplete popup list appears, the focus should be on first element in list, in order to quick create a new record if no match
* Tour.js has been modified because jquery ui autocomplete needs a mouseenter event to be notified that this element will be set
Move the project kanban_selection widget out of h1 and make it as
direct child of form sheet. This allows to put it on the right of
oe_title no matter what (+ enterprise compatibility).
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
The widget SelectCreatePopup display the search view drawer directly
after the search view input field. But in current firefox version this
could lead to an issue with float positionning.
fixes#8462
opw-648999
Provide a more informative error message than "undefined is not a
function" when a method passed by name to the events object is missing
on the widget.
The test was not stable enough since listview editable and onchange
API changes.
+ Some step were wrong (test of the wrong element)
+ Minimize differences with enterprise version (so that the two tests
are testing the same things)
(backport of enterprise version)
Fix various problems with list view editable :
* Click outside which should discard/save the line in edition
* Warnings which should not appear when line is being discarded/saved
* JS test
+ JS code refactoring
Barcodes are detected by catching keypresses. When a keypress is not
part of a barcode, it is 'released' by forging a keypress event.
For security reasons, a non-native keypress doesn't trigger the native
input mechanism. So in order to make both barcode-scanning and manual
keypresses work in a field, it is necessary to have a handler listen
to the 'false' keypresses and simulate the native input behaviour.
When a button in the modal's footer has an onclick handler and closes the
modal, the action of closing the modal should wait for the potential deferred
returned by the handler.
For instance, if an handler performs an asynchronous call and, when resolved,
triggers a notification, the notification doesn't reach the webclient if the
modal is already closed because the widgets hierarchy is broken.
This allows to detect barcode scans while the focus is in such a field.
It is not the default behaviour because buffering keystrokes to see if
they are a barcode then releasing them if they aren't isn't trivial
(it is impossible to trigger a native keyboard event).
A 'display: none' rule on hover has been added for boolean buttons, on each
'o_stat_button o_stat_text' that hasn't classname o_hover. This applies on
every stat button that isn't a boolean button, so their content is always
hidden on hover.
Disabling all warning coming from listview editable broke tests
because they relied on this behaviour.
The problem that was to be solved is that warnings coming from
listview editable were useless for the user in a form view. Another
solution must be found.
Backport of refactoring/fixes/features for the listview editable. This
includes changes to formview and listview too (as the listview editable
interacts with them).
The widget now provide labels that depend on widget option "terminology". For
each terminology, it provides four button labels that are shown depending on
the field's value and hover status on the button.
Christophe Simonis