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
replaced @disabled checkboxes for boolean fields by @readonly + alpha
(50%), as disabled input do not generate *any* event. Not default
action (of course) but not e.g. a click either, whether delegated or
bound directly on the element, there's no way at all to see if e.g. a
user has clicked on a disabled checkbox or radio.
lp bug: https://launchpad.net/bugs/1013569 fixed
bzr revid: xmo@openerp.com-20121113131806-7fhog1f96gxnjr67
The on_/do_ binding still happens in Widget.init, but as we now use ES5 bind()
it doesnt clutter stack traces anymore. However the fate of this automatic binding
feature remains uncertain.
bzr revid: al@openerp.com-20121110193440-78mpwamqx7iwq2ux
e.g. quotation form view, "Order Lines" table, add a tax (or more) to
a line, save, then try to edit the line.
Issue: the listview mostly uses a single-level structure for its
display, each record is a trivial map of {name: value}. For the M2O
the expected value can be complex-ish (a name_get which holds all the
interesting stuff) but not so for the m2m.
An m2m value is just a list of ids (Array<Integer>), the list view
would overwrite that with the concatenated name_get strings to get
something kind-of displayable. Except editable serializes the record
it has and passes that as-is to the embedded formview. The
corresponding widget (FieldMany2ManyTags) most definitely does not
expect a big string to be shoved up its fat ass.
So use a different but just as disgusting hack: instead of *replacing*
the ids array with the string, add the string to the record after very
slightly munging the original name, that way the form is happy because
it gets the value it expects, and the Many2Many column can override
_format to use the value of the munged/fake column as "stuff it passes
to whatever is in charge of formatting fields for display" when the
original field is asked for.
NOTE: redundant work is done as every line will do its own name_get,
potentially on the same ids over and over again. Having a
short-lived backend cache may allow not name_get-ing ids we've
already fetched during the same table display...
bzr revid: xmo@openerp.com-20121108145705-uphw76z4q4krcpnl
niv-openerp
Christophe Simonis
Xavier Morel
Christophe Matthieu
Mohammed Shekha
Dharti Ratani (Open ERP)
Antony Lesuisse
Vijaykumar Baladaniya
vta vta@openerp.com
Fabien Meghazi
Tejas Tank
Vidhin Mehta (OpenERP)
Hiral Patel (OpenERP)