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
This fix is related to revision 3985 revid:dle@openerp.com-20140326142040-pls0dk2kd03z55ro, which did not worked for buffered dataset (virtual one2many line in view form
search_read is used instead of read to not return records for which we lose the access rights
bzr revid: dle@openerp.com-20140327112456-iyceuf9dnn07hwke
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
As `new Date()` return the current date, when we are the 31,
setting the month to a month with less than 31 days will change
the date to next day (1st of next month). This result to a date(time)
object one month ahead of the wanted date(time).
bzr revid: chs@openerp.com-20131031103333-vt68132ptj9sbr04