lp bug: https://launchpad.net/bugs/865188 fixed

bzr revid: fme@openerp.com-20111005153202-4ao575zh3885ukuy

bzr revid: al@openerp.com-20111005143607-7p5z3gn4ddt3pios

bzr revid: vmt@openerp.com-20111005135549-xvhtt57fl1ib7o6e

bzr revid: xmo@openerp.com-20111005130252-oovrpbo4a1pjavwd

bzr revid: vmt@openerp.com-20111005113434-itjuj0u3d6fhryn8

Python has an iteration fallback protocol: when iterating over an
object which does not define __iter__, if the object defines
__getitem__ it considers that it's a list, and invokes __getitem__
from index `0`.

This can be a problem in openerp in methods which expect an list of
ids but are only given a single id (not a singleton list), in that
case self.browse() will return a single browse_record (instea of a
list) and the method tries to iterate over it by calling
browse_record.__getitem__.

Problem is that browse_record.__getitem__ is pretty deep and does
little validation, so the error appears 3 frames below where the
actual issue is with a completely cryptic message of "KeyError: 0",
which makes the actual harder to track.

By raising an error immediately in browse_record.__iter__, this kind
of issues is much easier to handle, the stack points precisely to the
frame in error with a clearer message.

bzr revid: xmo@openerp.com-20111005112444-jcp9fw6pa36ahpsd

this means if the auto_search attribute is missing, search automatically. Search should only
be prevented if auto_search is precisely false

bzr revid: xmo@openerp.com-20111005111210-qju8ocbhvqahczsz

bzr revid: xmo@openerp.com-20111005105731-9431uvhay91bt10c

bzr revid: vmt@openerp.com-20111005105103-cutnuvfkgsjej3vc

The static homepage do not reload the page when the module installed have no configuration actions (eg: returning direcly ir_actions_act_window_close)

bzr revid: fme@openerp.com-20111005101714-s5jy3gslni00a5jo

 - _original_module is now available on model/browse_records
 - context usage in res.partner.*
 - proper name_search() + default values for res.currency
 - active_model in wkf exec context
 - safe_eval allows try/except/finally
 - yaml_import: !ref {id: xml_id} works
 - ir_mail_server: support for alternative body/subtype
 - default value for web.base.url config parameter
 - consistency rename: Model.*get_xml_id* -> *get_external_id*

bzr revid: odo@openerp.com-20111005100954-c8mbd4kz6kkqaj84

[fix] problem with the idea module trying to override the 'active_id' context key, which it should not

bzr revid: nicolas.vanhoren@openerp.com-20111005095633-v53hjz3fkwlb3fso

bzr revid: odo@openerp.com-20111005094843-ov5p9em7mzxb2pkn

bzr revid: nicolas.vanhoren@openerp.com-20111005093600-xjyqrmpoqywy1ztq

bzr revid: nicolas.vanhoren@openerp.com-20111005093237-22dbe1jwbkqk18pt

bzr revid: xmo@openerp.com-20111005090518-3ht49k8s6vtrxhwl

bzr revid: odo@openerp.com-20111005085022-krq4qe95q84s7gol

bzr revid: odo@openerp.com-20111005084621-totk30u0e0weol2o

lp bug: https://launchpad.net/bugs/865945 fixed

bzr revid: fme@openerp.com-20111005083656-f5bq8v1km25s4orx

bzr revid: fme@openerp.com-20111005083521-ofyfzdp8olzpjnbd

bzr revid: ysa@tinyerp.com-20111005071001-x8cdfvarwfk4brkb

bzr revid: launchpad_translations_on_behalf_of_openerp-20111005044429-thiikup2n1y3ayb9

bzr revid: odo@openerp.com-20111005010136-xkowcqda3kres691

bzr revid: odo@openerp.com-20111005002956-1tfe5u13qid3intk

bzr revid: odo@openerp.com-20111005002416-vz0vzfpb2uosxu4c

bzr revid: al@openerp.com-20111005001643-ngs7quhipn79gauu

bzr revid: al@openerp.com-20111004231534-ay78ghc46ihb91mx

bzr revid: odo@openerp.com-20111004225439-xnb77gtbl77onysm

bzr revid: al@openerp.com-20111004223410-pbwkn5k4zq9ze1mj

bzr revid: al@openerp.com-20111004222640-ako0cjw414c5lz72

bzr revid: odo@openerp.com-20111004205254-82krwzabg0wuf2ka

The 'module' field of ir.model.data is required, so we
we need to set it when auto-generating ir.mode.data
entries. This acts as the namespace of the record.
Because we don't want exported records to look like they
belong to an existing module (and risk being garbage
collected at the next module update), we put these
auto-generated names in a reserved '__export__' module
namespace.

bzr revid: odo@openerp.com-20111004205140-duaww77ng4qmktj2

bzr revid: odo@openerp.com-20111004204800-f4470vy0ou3ugxnm

ORM Models already have a _module attribute that contains the
name of the module that declared this class, however
sometimes we also need the name of the module that
declared this model the first time.
This will be stored in _original_module and is the
name of the module to which the first parent with 
the same _name belongs to.

bzr revid: odo@openerp.com-20111004204705-8z9o70n1ynpvng3i

bzr revid: nicolas.vanhoren@openerp.com-20111004161116-6pylm16ty6v69szu

bzr revid: xmo@openerp.com-20111004155918-c2vy0rwkesvdkmli

[FIX] stupidity: if insert a line in a list with more than 5 records (no padding), since the new line does not have a @data-id yet it's going to remove it immediately.

select line to remove before inserting new one

bzr revid: xmo@openerp.com-20111004155746-q13ieg0q6lsy1uf7

bzr revid: xmo@openerp.com-20111004154650-hx56g1lmefhzgf21

[FIX] insertion position of new lines (in editable lists) in case of lists padded to 5 (empty) lines

bzr revid: xmo@openerp.com-20111004154246-7o1cw016cf9ygem3

Form fields are extended/replaced in editable list view in order to
handle @invisible and @tree_invisible correctly in editable-list-form
context (base semantics of @invisible are different between listview
and formview, formview's @invisible is listview's @tree_invisible, and
instead of removing element from visible DOM listview's @invisible
only hides the element but it keeps the space it's taking).

As a result, listview editable needs to override Widget.update_dom for
pretty much all form widgets, in order to manage this difference in
behavior.

In case of @tree_invisible, it did so correctly setting and unsetting
its stuff and calling this.super() to execute the widget's actual
update_dom triggers **but it did not do so when the element was really
visible**.

As a result, in editable listview elements would never appear required
(blue background), invalid (red background) or disabled (gray),
although they were correctly set up, because the display layer was
never updated.

bzr revid: xmo@openerp.com-20111004151031-65o0q8e86op7kdks