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
As of today, google maps tend to localize:
Avenue de la Liberté 56, 1000 Brussels, , Belgium
As:
Place de la Liberté 56, 1000 Bruxelles, Belgique
making imprecision and failing geolocalizaton test of
'crm.crm_case_abcfuelcounits0' (current modification is backported from
trunk unit-test)
bzr revid: xal@openerp.com-20120524165431-nopxu62kbjrs431o
As of today, google maps tend to localize:
Avenue de la Liberté 56, 1000 Brussels, , Belgium
As:
Place de la Liberté 56, 1000 Bruxelles, Belgique
making geolocalizaton of 'crm.crm_case_abcfuelcounits0' fail
bzr revid: xal@openerp.com-20120524152946-y4itnc3n4fps3prx
This was working previously because the cache was disabled,
due to bug #988743. Now that the cache is working again,
it needs to be properly invalidated whenever a decimal.precision
record is created or deleted, otherwise all computations
will use an incorrect precision.
bzr revid: odo@openerp.com-20120523085234-2q8z7f1naydnjgsz
In the case of ``list`` view mode, code would fail to use provided
``views`` array (and therefore lose the view id), overriding it with
``[false, 'list']`` instead.
Original issue seemed to be that the dashboard's ``view_mode`` may
contain view names which are not in the original action's ``views``
array (?) in which case the _.find call returns ``undefined`` and then
blows up.
This was fixed by pre-checking the dashboard's view mode against the
action's view_mode, which is:
1. Wrong, as the action's view_mode will always contain ``tree`` never
``list``
2. Weird, why not fallback *instead of returning ``undefined``*?
So that's what was changed: instead of returning ``undefined`` the
mapping function now returns a default ``[false, mode]`` pair.
bzr revid: xmo@openerp.com-20120518085105-job3luim44ih6nps
* 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
Some strange mail client implementations seem to
selectively strip the background-color CSS in emails,
making a white-on-black button become white-on-white
invisible text. Replaced #FFF with #DDD in order
to more gracefully degrade in those cases.
Reproduced with Lotus Notes 8.
bzr revid: odo@openerp.com-20120430132103-ei61f9m9irpmh2ys
Launchpad Translations on behalf of openerp