autosize does not work correctly (it moves the screen in all directions
sometimes when the user press enter in the bottom of the screen in some
browser),
So, we decided to have our own version, because of course, we can do it better. A
few horrible hacks later, I proudly present you "autoresize" (it was
almost named "odooresize" but common sense prevailed).
As added benefits, it plays better with our web client, so when you open
a dialog in a modal for example, the autosize fields should have the
correct height automagically (or should I say 'odoomagically')
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
Move the widget_x2many tour to web and call it from test_new_api as it needs
to be overrided for the new design, and it requires models and data from
test_new_api.
Clean other unnecessary stuff from web_tests, and thus remove the addon.
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
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
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.
When creating a new record in list editable, due to previous commit 6349048, the load_record was called twice and the first record of the current list view (self.dataset.index) was used to fill the new record.
With this, we make sure a new record is indeed created.
Fix the web test to have a default_get call in mock models and increase the number of default_get assertions (for creations in list editable, the default_get is then called twice, not optimal but due to the absence of distinction between empty datarecord and filled with default values).
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
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.
Géry Debongnie