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
Because the Add/Create button is global, it's not really possible to
know *where* to create the new record, and the current design can't
really deal with a record being edited outside of all groups.
An option might be to create a dedicated empty group for that, but the
cost/benefit is high and the UI would probably be odd.
lp bug: https://launchpad.net/bugs/1098205 fixed
bzr revid: xmo@openerp.com-20130306102136-2ms7llbt4swka92k
When using the ``set_editable`` feature (context key) from filters
(togglable on/off), the list view would not correctly clean up
(destroy) the form when switching from editable with a started editor
(and form) to non-editable, leading to form fields (in this case m2o
fields being in an incorrect state and trying to query a non-started
autocompletion widget on every click anywhere blowing it up).
lp bug: https://launchpad.net/bugs/1117320 fixed
bzr revid: xmo@openerp.com-20130225135629-8k338gw0arsi6m6j
Otherwise, if a search is performed while creating or editing a line
(e.g. in logged calls, create a line without saving then try to apply
a filter) the edition section (and new line) disappears but the list
remains in "edition" mode (e.g. save/discard button) even though
edition data is missing (trying to save or discard will error out).
bzr revid: xmo@openerp.com-20121210100914-delia5bhmtgrujpu
Because of the "meta" columns (e.g. group name column),
ListView#columns would end up with a different number of elements than
ListView#fields_view.arch.children, and when zipping them together (to
build the form view for edition) things wouldn't match anymore.
It would seem simply filtering out meta columns (and only keep those
actually specified by the view) is sufficient to fix the issue and
have everything line up again. I'm midly impressed.
bzr revid: xmo@openerp.com-20121129131301-scc38i4l55ea7lis
During the creation of a new record (in an editable list), the
prospective new record has a ``false`` id. In a non-o2m, the row under
creation can be selected (checkbox) and deleted (More > Delete),
leading to the request to ``DELETE false`` being sent to the ORM…
which said ORM does not wish to entertain.
Before actually performing the delete request (more precisely
forwarding said request to the listview itself), remove all false-ish
ids from the array.
Also, don't send a request to delete nothing.
bzr revid: xmo@openerp.com-20121119084203-0vz4v9myfizxz88u
move special case in o2m listview to main editable and expand to
correctly fit edition cases, not just work in case of creation
issue: if a row being edited is deleted in an o2m, the form will be
blurred and try cancelling/saving the edition and reloading the row,
but this will only happen *after* the record/row/whatever has been
"deleted" and (amongst other things) removed from the buffered o2m
cache, leading to a tentative read on the server side (usually with a
local id which doesn't even make sense) and thus an error.
Intercept the deletion signal to cancel the edition immediately and
only let the deletion through after the edition has successfully been
canceled.
bzr revid: xmo@openerp.com-20121116164416-8kr39t6jtqy2s3jc
the onwrite handler created an "empty" record with no field value
whatsoever, which'd blow up in the py evaluator. As during creation
(edition of a record where all fields are empty) create a record where
all fields are set to ``false`` so rendering works correctly, and wait
for content refresh to get correct data.
Also added a test for @on_write
bzr revid: xmo@openerp.com-20121112150526-vrr66ms95qbuoped
Only fetch the table cells of the row being edited *after* having
saved a pending edition.
Otherwise, when re-editing the same record (e.g. click between buttons
or on a readonly field), the cells are saved, the record is refreshed
destroying the cells, and when trying to get the cell positions to
position form fields correctly... the cells which don't exist anymore
return 0, 0 as their position and nothing works correctly.
bzr revid: xmo@openerp.com-20121017134351-lpmz27f1iemmsfoq
Altered action button workflow:
* Action callback (passed to ``do_button_action``) now *takes* a
record id instead of closing over it, in case the original list does
not have an id to start with
* ``handle_button`` partially applies the id *it* got to the callback
via ``_.bind``
* Editable list view override of ``do_button_action`` uses ``id`` it
got from ``ensure_saved`` in case it got id=false in
bzr revid: xmo@openerp.com-20120807092317-wk0xyfzrhxc89t94
niv-openerp
Xavier Morel
Vijaykumar Baladaniya
tsabi
tsabi
Fabien Meghazi
Vidhin Mehta (OpenERP)
Raphael Collet
Antony Lesuisse
Jigar Amin - OpenERP
Fabien Pinckaers