- 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
- 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
* The action's context and domain are needed because they are
explicitly ignored by those codepaths when the action is ultimately
executed in the dashboard, and their data are needed: such flags as
group_by_no_leaf may be set in the action's context, or things like
the leads/opportunities filters which need to remain in the
dashboard view.
* On the other hand, some keys in the action's context may be
detrimental to the correct behavior of the action in the dashboard,
one such key (group) is the search_default_*: these default values
for the search view may have been unset by the user before adding to
the dashboard, we must not add them back. And since the dashboard
will instantiate a full action/view manager for each action there
will be (empty) search views which will try to make use of those
defaults.
As a result, add the action's context and domain to those of the
research while *creating* the dashboard action/section, *but* filter
out search_default_* context keys while doing so.
If new problematic context keys are discovered, they should be added
to the filter.
bzr revid: xmo@openerp.com-20120516153309-3eq957p1pbj99fun
min-height seems the original intention of the
CSS, while height is too restrictive and hides
parts of the field value when it is very long
(and switching to edit mode is not always an
option, e.g. for read-only records like emails)
bzr revid: odo@openerp.com-20120426161133-glgkx7h6hdyyxw24
Olivier Dony