When the number of records n and the limit l were such that n%l = 0
(e.g. 16 records total, 8 displayed per page), clicking on the
previous button on the first page, or on the next button on the
last page produced a bug because the total number of pages
computed for this edge case was incorrect.
When the list view is grouped, the page count should be hidden as irrelevant.
However if it's fully hidden, the limit can no longer be changed.
Instead of hidding the pager, this commit hides the arrows and replaces
the content by the current limit to allow to be changed.
See issue #3964 for more detail. Main problem was caused by commit
f0e331e005. It set the key name+'__display' to false when reloading
a record for all field types, but it was only concerned with many2many.
Fixes the issue #1216 (follow the link for more information). The issue
was caused by a hack in list view: the magical suffix __display is used
in render_cell to determine if a many2many field should be updated. This
commit simply makes sure that old many2many fields + __display keys are
cleared.
A better way would be to redesign/refactor the list view to avoid that
hack in the first place. But this would be a much more complex task.
If an action unlink the current records (e.g. unreconcile on account.move.reconcile), trigger history_back to avoid errors when trying to reload inexistant record (opw 607883)
This is a partial backport of saas-4 code (rev c0db6ae, 162ad1c) and should not be forward ported.
Displaying the pagert in view group does not make sense as it's not updated when changing filter and every group (even if more than 80) is displayed in view group
Fix bug https://bugs.launchpad.net/openerp-web/+bug/1279885 :
Many2many fields in Tree views will not get translated.
If you check the context for a name_get of a m2m field, it is passed as
None.
Add context propagation to m2m fields in list views.
Fix translation issues when viewing a a many2many field in a Tree view.
When delete a record, correctly display the number of remaining items displayed (eg: 1-79 of 99)
When no more items in a page, force switch to previous page
When no more pager, reload the content to display potential items in next page
bzr revid: mat@openerp.com-20140303164114-pzeuu9hxvq17lx02
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