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.
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
BufferedDataSet.read_ids assumes the input and output orders are the same, and
returns wonky results when not the case, which in turns fucks up its cache as
it associates ids and records incorrectly.
bzr revid: xmo@openerp.com-20140225162813-8ofxpiy1012eehgk
* Alter datetime.now(), generate a local datetime (add utcnow() which generates a UTC datetime)
* Implement datetime.replace() to manipulate local datetimes
* Implement date.today(), generates a local date
* Implement datetime.toJSON(), returns a javascript Date (assumes datetime attributes are local)
* Add conversion hook in JSON and JSONP handlers, automatically converts a Date object to a UTC datetime formatted according to server formats
Should allow the generation of correctly working (from the end-user's POV) [Today] filters, amongst other things.
Eg: a local expression in a domain for 'Today 00:00:00' would now be expressed as 'datetime.datetime.now().replace(hour=0, minute=0, second=0)' (no .strftime) and will be converted to UTC when sent to the server
bzr revid: mat@openerp.com-20140128133706-4yp610pp5w06tcia
* change datetime.now() to generate user-local naive datetimes
* add datetime.utcnow() behaving as the old now()
* add date.today() generating a user-local date (for the current day)
* add datetime.replace() to replace any specific attribute of the
datetime object (except tzinfo, for now)
* datetime.toJSON() now returns the equivalent javascript Date object
(warning: uses the datetime attributes directly, since datetimes are
naive if they were created with utcnow() the Date result is going to
be complete nonsense). With the previous commit datetime.now()
generates a user-local now() which is converted to the correct UTC
datetime when sent to the server.
This means it becomes possible to generate datetime bounds for the
user's local today with either
datetime.datetime.now().replace(hour=0, minute=0, second=0)
or
datetime.datetime.combine(
datetime.date.today(),
datetime.time())
and once send over JSON-RPC the server will get the local datetime
in UTC to the server's format.
nb: user-local means "in the timezone of the user's browser" in this
context.
bzr revid: xmo@openerp.com-20140122151911-akn1nr6e739eg92s
Aaron Bohy