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, ...).
The structure `filename*=UTF-8` works in Safari, from
release 6.2 (which is set as version 537 in the user_agent version).
This structure has the advantage to handle the UTF-8 encoding,
and therefore special characters, such as accents.
Therefore, from this Safari release, we use the same format
than other browser. For older releases, we use the format
`filename=`, without UTF-8, ASCII encoded, replacing
special characters by `?`.
opw-649863
* 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
How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
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
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
The `check` decorator expects the context to be in the `kwargs`
or to be the last arguments of the method.
The `call_kw` route, which is decorated by the `check` decorator,
like every route,
expands its kwargs arguments.
Therefore, once in the `check` decorator,
the context is located in the `kwargs` key
of the kwargs.
(More simply, instead of
`kwargs.get('context', {})`
it's
`kwargs.get('kwargs', {}).get('context', {})`
As the context is not retrieved correctly,
the lang is not set correctly either,
and the sql constraints were not translated.
In 7.0, it worked, because there was a double
check, as the call_kw was called trough an rpc
(`dispatch_rpc`) call,
which was decorated by the `check` as well.
As a fix for 8.0, we apply the same logic,
we perform a double check, with an indirection.
The check decorator should probably be
refactored, but this cannot be done
in a stable release such as 8.0.
Closes#3634
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.
Christophe Simonis