Issue 575065
Flow for a button[@type=action] requires going through multiple RPC
calls to execute action. Due to reloading behavior of o2m-list on
actions (saves containing form then executes action then reloads row),
internal form view gets removed while e.g. server action is being
fetched (in Views#do_execute_action).
Problem: there is guard on ``rpc`` call which drops response to
stopped widget (Widget#rpc) => action/load call never returns
successfully because linked form is dead.
Solution: instead of calling View#do_execute_action via the formview,
call it via the listview (do_execute_action was already partially
overridden to change the ``on_close`` callback, override it further).
=> widget still lives, and rpc requests execute correctly leading to
all actions being correctly called (mostly).
bzr revid: xmo@openerp.com-20120629105325-vmwpyi7w3pc33sg9
* Correctly propagate current validation status of row being edited
* Automatically save row being edited upon leaving it
* Replace "Save" button (floppy) by "Cancel" (cross)
* Allow easier overriding of Groups and List sub-widgets
bzr revid: xmo@openerp.com-20120625070901-4cs6v24exjk5z2fa
This issue was caused by the way browse_records are cached,
in combination with the deletion of messages just after sending
them. When processing a second message, the attachment.datas
function fields gets computed for all messages that are being
browsed, including the first message that was already deleted,
causing an exception. The value of the function field had
already been computed for the first message, but had been
discarded by the message.refresh() call.
Hopefully this kind of issue will disappear once we implement
the new ORM API.
bzr revid: odo@openerp.com-20120622152536-42b2s28lvdv3odyr
This issue was caused by the way browse_records are cached,
in combination with the deletion of messages just after sending
them. When processing a second message, the attachment.datas
function fields gets computed for all messages that are being
browsed, including the first message that was already deleted,
causing an exception. The value of the function field had
already been computed for the first message, but had been
discarded by the message.refresh() call.
Hopefully this kind of issue will disappear once we implement
the new ORM API.
bzr revid: odo@openerp.com-20120622093123-wpk8ht454w7p2c1w
After opening a record with a list o2m, editing said list o2m and
saving a row, clicking the action button would lose all data
explicitly changed: the o2m would just call the action without saving
the form's current state, so the corresponding server method would
only be able to use data previously saved.
Fixed by overriding do_button_action, and only calling the _super()
method after the parent form has announced it is saved (either because
nothing was changed or because it did indeed save itself).
bzr revid: xmo@openerp.com-20120622085432-mh3977uygua5bypn
This is required to avoid strange mro() pitfalls
where an AbstractModel is inherited by a Model,
and the _auto=False of AbstractModel ends up
first in the mro() because Model does not explicitly
define it, and the BaseModel default _auto is farther
in the mro().
lp bug: https://launchpad.net/bugs/1013566 fixed
bzr revid: odo@openerp.com-20120621110825-ry8e5tktvwv3h4tm
if only the *display* list is filtered, the advanced search engine may
still attempt to *select* a non-searchable field (if it's the first
one) leading to broken/nonsensical behavior.
Non-searchable fields should be removed from the advanced search's
ability to find them altogether.
bzr revid: xmo@openerp.com-20120621101103-k842i8h1rxlr4n9k
This is required to avoid strange mro() pitfalls
where an AbstractModel is inherited by a Model,
and the _auto=False of AbstractModel ends up
first in the mro() because Model does not explicitly
define it, and the BaseModel default _auto is farther
in the mro().
lp bug: https://launchpad.net/bugs/1013566 fixed
bzr revid: odo@openerp.com-20120621100900-xejo9yhgx36kyh03
Xavier Morel