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
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
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
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
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
I don't remember why I did that originally, it does not seem to serve any purpose and it causes problems in case of records with binary fields
bzr revid: xmo@openerp.com-20111004102115-lz6kgyiw35vp1t99