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
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
Adapt the Favorites menu so that addons appending stuff in it are compliant with
the enterprise edition.
Mainly, creation of dashboard.less from of dashboard.sass so that we can use mixins
defined in the web addon.
Some changes as well in the dashboard view to make it compliant with the enterprise
edition.
Use correct naming convention: classnames with underscores, less mixins with hyphens.
When a many2one field of a searchview was selected
by default, through a default_*_id within the context,
the many2one value name wasn't translated.
e.g. with Spanish loaded (and l10n_multilang installed),
translate a project.project name in Spanish.
Then, while being in Spanish, in the project.project kanban,
click on the Tasks link of a project (tareas),
then, notice the value of the project name in the
search bar.
opw-632818
previous commit broke some tests. The issue is that the search view
now avoid making requests if there is no action id. But this is an
assumption that tests use, so some slight adjustments have to be made.
Also, this is the moment to give properly the action id to the favorite
menu. Instead of bypassing its parent, it now receives the action id
from the search view.
The search view architecture allowed an 'invisible' attribute in fields. These fields were ignored for the autocompletion and did not appear in the interface. The goal was to allow default parameters to create facets, without displaying the field in the interface. Since that functionality is not used and the new search view does not support it right now, the tests can be removed.
Allow binding an optional `action_id` to filters.
The web client will try to identify the specific
action ID when saving new filters. If no contextual
action exists, the filter is saved globally for
the model.
This will automatically keep filters within their
original menu when there are several menus/actions
leading to a given list of documents.
In some cases the action_id will not match the
filter model, which should be fine (e.g. when opening
a many2one completion popup for model `foo` within
a menu of model `bar`).
It is also still be possible to have a filter apply
to all actions/menus for a given model by manually
deleting the action_id value in the filter
(e.g. via the Manage Filters debug menu).
When updating a filter the action_id value is ignored
so that old global filters will be gradually replaced
by new "local" filters.
Also added an _order to ensure stable ordering of the
filters.
Task #5009
This new autocomplete widget (the one used in the search bar) does not
do remote calls automatically, but on demand. In theory, it should lead
to a better user experience, not having the ui blocked every time long
remote calls are done.
It also has the benefits of bringing us one step closer to not
depending on jquery.ui. Bonus point: the code is quite short (< 200 loc
i believe)
* oe_searchview_custom has been split in oe_searchview_custom and
oe_searchview_filter: a test need to take that into account
* in adjust_top, the parent might not have a $ method.
to accomodate the fact that the searchview has been changed.
Two changes need to be accounted:
(1) the drawer html structure has changed (oe_selected class is
replaced by badge, some li tags are replaced by spans, ...) and
(2) the CustomFilters has been split into CustomReports and
SaveFilter, so there is an extra filter in the drawer inputs.
Also, the searchview need a parent to react to the switch_mode event,
so the tests add a fake parent to the view in make_search_view
There seems to be a problem with QUnit's serialization routines when
applied to complex widgets (the view here) while running inside
PhantomJS. It does not seem to be cycles in datastructures (that is
handled) but looks related to complex objects linked from multiple
"children" (skipping any object already serialized makes the issue
disappear).
The bug leads to unbounded memory growth, and on runbot to the process
being summarily terminated (likely by the OOM killer) not even
resulting in an OOM error (which is displayed locally). The issue can
not be observed within browsers. This may be a difference in GC
strategy.
The serialization is applied by the driver on high-level comparison
methods (e.g. strictEqual) so the caller can display the structures if
desired.
Replace the strictEqual(a, b) call by ok(a === b) to avoid any risk of
such serialization.
bzr revid: xmo@openerp.com-20130801091326-u2q9e163zls4k8ad
Implementation of invisibles in search view altered handling of search
inputs: their parent may not be the searchview anymore (usually is a
instance.web.search.Group). GroupbyGroup assumed parent was view and
was actually unused until
xmo@openerp.com-20130307124222-1ypzfopbktxmad4z, which exposed the
incorrect underlying assumption.
Make GroupbyGroup access its view when it wants its view, not its
parent.
bzr revid: xmo@openerp.com-20130312092824-z7sh4h3ityo4g00v
This leads to any subsequent view overwriting the current user's lang
or timezone with the one active when the filter was created,
generating dismay and discontent (e.g. part of the user interface
switching from spanish to english or english to german, depending on
the respective settings of the current user and the filter creator —
at time of filter creation).
bzr revid: xmo@openerp.com-20130304101414-mm6ai1dkltd7ard5
On click on a filter in the drawer, FilterGroup would just match the
offset of the filter in the group's DOM with an index in the internal
#filters array.
This worked until invisible fields, and then again only for filters
*preceded* by an invisible sibling in the same group: invisible
filters are not rendered in the DOM, so the indexes would get out of
sync.
Fix by using explicit indexes stored in a filter's @data-index and
using that to get the filter object/node.
An alternative fix (but hackier I think): instead of not rendering
invisible filters, render them with display: none. Remains an option
in the future if needed...
lp bug: https://launchpad.net/bugs/1157125 fixed
bzr revid: xmo@openerp.com-20130321155123-211iht7c6zme712e
e.g. @domain="[]" would be seen as non-empty by the search view, and
if multiple domains the search view would generate a nonliteral
``['|', '[]', '[]]`` which would just yield ``['|']`` after evaluation
and concatenation, which is an invalid domain and would blow up the
server.
Specifically filter out the values ``[]`` and ``{}`` from filters
bzr revid: xmo@openerp.com-20121129112413-yrgncnesqs093jwf
Christophe Simonis