When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
When installing or updating a module, custom fields referring custom model
(many2one) cannot be read because custom model are not loaded at this stage
(they are only loaded after all modules because they can refer any model).
Not prefetching them avoid crash when computing stored function fields.
bzr revid: chs@openerp.com-20130626091332-231rqg5ouhnc3d2x
This was apparently a long-standing issue due to a
strange handling of the _prefetch attribute on
columns: accessing a column would only trigger
the prefetching if its _prefetch attribute was
True, but the prefetching itself would also
prefetch columns that had _prefetch False.
We clearly want it the other way around, or
at least we want _prefetch to decide whether
a column is included in any given prefetching
pass. We can skip the prefetching pass when
the only field being accessed has _prefetch
False because it is likely the other fields
have already been prefetched separately.
This last subtlety should not make any
noticeable performance difference.
lp bug: https://launchpad.net/bugs/1177965 fixed
bzr revid: odo@openerp.com-20130620131057-v7s4qfqj976j3ufo
- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415171732-aj3j2e2mycvzf4kp
This is needed so the uninstall process can simply go through
the installed data by using the ir_model_data entries in reverse
order (when ordered by IDs), so that parents are deleted before
children.
bzr revid: vmt@openerp.com-20130321133202-igea1vxlszfpk6pe
object has no __getattr__, in the usual case super(BaseModel,
self).__getattr__ will blow up with an AttributeError (but the wrong
one).
On the other hand, if a BaseModel descendant class is used in MI
alongside a non-BM descendant (e.g. res_partner inheriting from Model
and format_address) and the non-BM descendant also implements
__getattr__, we want to forward the failed attr search to the other
__getattr__ implementation.
So check if super() has a __getattr__, call it if it does otherwise
AttributeError right there.
bzr revid: xmo@openerp.com-20130315115302-z7jla334gb9a5e43
- isinstance(ids, dict) is done at the end, but not at the beginning,
so if ids was a single dict, it would break in the map(lambda).
- The loop to convert None to False can be done in _read_flat instead
of read (there is already plenty of loops in _read_flat)
- The __getattr__ was breaking the stacktrace.
bzr revid: vmt@openerp.com-20130314154418-0wmxfw1ot92kjmzf
Olivier Dony
Martin Trigaux
Christophe Simonis
Thibault Delavallée
Denis Ledoux
Quentin (OpenERP)
niv-openerp
Vo Minh Thu
Ronald Portier
Raphael Collet
Chris Biersbach
Christophe Matthieu
Xavier Morel