dataset.index was previously set to ``null`` in handler of [Create]
button (to fullfill contract with form view that dataset.index should
be ``null`` to indicate the creation of a new record with no id).
Issue: after setting the index to ``null``, the list view calls
``render_row_as_form`` which starts out trying to save a row being
edited (case: clicking of the [Create] button after having selected a
row for edition or after having written in a new record e.g. [Create]
-> type -> [Create] type -> ...). This tentative to save the existing
form would be performed in the context of a ``null`` dataset.index,
which the form view doesn't (and shouldn't, index should be that of
record *being edited*) expect.
-> first save in whatever dataset state is the current one, and *right
before* creating the new form (after having saved and/or discarded the
previous one) we have the id of the new record to edit (or ``null``),
find the index for *that* and set ``dataset.index`` to that (or
``null``) so the new form view can be created and opened in the right
context.
bzr revid: xmo@openerp.com-20120613153842-pd6xitjs8n003ogs
if the editable row's form isn't dirty, either nothing has been
entered in a new row or an existing row (being edited) has not been
altered, so can just discard the row (and reload it from cache if it's
an edition).
bzr revid: xmo@openerp.com-20120613153633-ms7i8t9lvdarxqi3
the user has not modified the editable line after opening it (whether to create a new record or to edit an existing one), so shouldn't be invalid
bzr revid: xmo@openerp.com-20120613153555-fq0moy1q464l92yj
- required fields may sometimes be provided by alternative columns,
and all the alternatives are therefore not required (e.g. for
a m2o the CSV can provide m2o or m2o/id columns)
- when fields share the same label, precedence when matching
column headers should be given to the field with the exact
same name, rather than just the first one encountered
bzr revid: odo@openerp.com-20120606174043-f1nmkad3p17mccyy
Don't prefilter via name_search if no data has been entered in the m2o
field, it's going to return all records (not paginated) so it's a
waste of time and resources
bzr revid: xmo@openerp.com-20120606124717-h2p211vbrydazado
* Some literal actions (not stored) provide an empty string for
domains and contexts instead of (respectively) an empty array or an
empty dict literal inside the string. Treat those case as nothing
being provided.
* Likewise some literal actions provide nonsensical (but falsy, but
not False) values for view_id (such as an empty list). Yield a
``False`` view_id for all falsy ``view_id`` received (``0`` should
not be a valid view_id, so ``False`` works)
bzr revid: xmo@openerp.com-20120606123508-ndh3jpzw1nabf98n
- Normally when user click on 'Search More' on many2one fields, relation
object records are prefiltered based on the text user entered in the
many2one field.
But if user do not enter any text before click on 'Search More',
system will call name_search() with an empty search criteria - and
this could be quite expensive depending on the size of the dataset!.
(this of name_search() on more that 10.000 products...)
We now do not prefilter records if search value is empty (standard domain
filtering still apply).
bzr revid: xal@openerp.com-20120525131416-ie958wu0cihjslgc
We do default to exporting the XML ID, but there are
many cases where completely new data needs to be
imported and there is no XML ID available to do so.
In that case allowing name_search() to be used as in
6.0 is a life-saver. This patch simply makes the
m2o field itself visible during import, so users can
use it in their CSV file or manually select it.
Some trivial examples:
- you need to import 2000 new leads with their countries,
obviously you can't guess that base.be should be used
for country Belgium
- you need to update 2000 unassigned leads in the system
and assign them to some of the salemen... but you don't
have their XML IDs and even if you had, the match is
quite hard to do.
bzr revid: odo@openerp.com-20120525070859-y4q3bnamvag2pzcq