Create a deserialize_sort method and add a set_sort method to
datasets. The set_sort method is useful to avoid duplicating code
in lists and kanban views (to set the initial default order)
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
The following fixes have intentionally been reverted,
as the code has significantly changed and the bugs cannot
be reproduced:
- web_calendar fix (revid:dle@openerp.com-20140214114258-0hcsfdwyl61gph0v)
- CSS fix for buttons (revid:mat@openerp.com-20140213145755-txvtwqbfc83vnw9o)
bzr revid: odo@openerp.com-20140217102806-qg6kwk2jomdvvmlj
Instead returns undefined which is handled below.
This does not solve the issue when records are not loaded properly but gives a better information on the reason.
bzr revid: mat@openerp.com-20140213085008-pnq4r0ebfl072u78
Turns out when code looks somewhat odd there may well be a good reason
for it, and changing it without wondering breaks the pager.
In this case, `/web/dataset/search_read` has a significant difference
with Model.search_read: it returns the records slice specified by
(``limit``, ``offset``) but it also returns the *total number of
records* for ``domain`` which is sort-of useful to generating the
pager.
lp bug: https://launchpad.net/bugs/1218266 fixed
bzr revid: xmo@openerp.com-20130906150101-2qb349fzaz6rye36
Following xmo@openerp.com-20130607120355-x3poxy2ar2bpqqvw:
* add_ids should not add ids which are already in the dataset, this
leads to duplicates which the web client does not overly like
* methods which add or remove records should not manipulate
dataset.ids as well as that's now automatic (on_write feature)
* record add should only insert the id in the dataset on non-false ids
(e.g. list edition uses "pending" record with false id during
creation, then sets the id it got from create() call)
bzr revid: xmo@openerp.com-20130607152326-2pja1kuwo0ropfuw
When a record is activated, the listview will do some jiggling around
assigning the ids of internal dataset to the one shared between all
views, this is mostly for the case where one switches from a "grouped"
list view, so the form view only cycles on the "current" group.
Problem is, that internal dataset is not correctly synchronized with
the shared one, so when the id is removed from the shared dataset it
is *not* removed from the internal one(s), and when the switch is made
the ids from the internal dataset are set on the shared one and
reintroduce the deleted record, leading to the form view's incorrect
state.
Fix the issue by updating the dataset's ids list when a record is
deleted from the records tree.
Also extracted some stuff from DataSetSearch's unlink callback so it
can be overridden and is more stable across datasets.
lp bug: https://launchpad.net/bugs/1161210 fixed
bzr revid: xmo@openerp.com-20130416152000-06dbwkgdb8zlf9pc
If there are no grouping field specified *but* group_by_no_leaf is
specified, should call read_group with no grouping fields: will
generate a single group (which can not be opened) for all of the
model.
Necessary for analysis views since individual "records" make no sense.
bzr revid: xmo@openerp.com-20130416092344-2pqog8f7xprn6hsh
Evict record from BufferedDataSet cache as is done with button calls,
otherwise when caller reloads record (read) after having executed the
workflow action, it'll get the old one back from the BDS's cache.
bzr revid: xmo@openerp.com-20130301103543-jra87w2wm417tgyc