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
mail.message.Message has case-insensitive behavior
for headers, but setting the header value *adds* a
new header even if the same header already exists.
This caused multiple issues when forwarding, because
the forwarded mail kept the original To: header.
Also changed the code to use capitalized header
names at all times, just for consistency.
Also removed unused variable ``mail_message``.
bzr revid: odo@openerp.com-20120427140427-3qfctfqzrsexgkac
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
Xavier ALT