We'll now have a BaseModel with 3 subclasses, AbstractModel,
TransientModel and Model. Model is for regular models,
TransientModel for automatically-vacuumed models, and
AbstractModel for common superclasses meant to be
inherited by other models only, and not directly used.
bzr revid: odo@openerp.com-20110923124525-jfzk55dk3ban2ps2
Quoting column names make the case-sensitive in PostgreSQL,
and this is the default strategy we are using so far. It is
important to be consistent there.
We might want to do the same to table names too.
This allows create fields with mixed cases names for example.
bzr revid: odo@openerp.com-20110919201845-heer0rttcouvtc9x
- Refactoring to make the function readable and maintainable
- Fixed algorithm to properly take into account the priority of all stored functions,
and not just the priority of the first function for a given model, which could hide
other stored function with higher priorities.
lp bug: https://launchpad.net/bugs/715470 fixed
bzr revid: odo@openerp.com-20110919091952-05lfl2kncr3ep9nj
The only requirements for this to work are:
- all model methods likely to be called on a browse_record must support
a context parameter (positional or keyword, doesn't matter)
- callers should never pass the context as a positional args, otherwise
we'll have multiple values for the context.
Both requirements seem sensible enough.
bzr revid: odo@openerp.com-20110913130826-d7fme3mznv55ok5f
do replacement in two passes of re-base replacement: replace old-style 'field:id' and 'field.id' in resp. 'field/id' and 'field/.id', don't touch anything else (especially not 'field/.id') and leave them through instead.
bzr revid: xmo@openerp.com-20110831094547-8evd7ecm5qojspnr
The option is not completely flexible (no possibility to choose to have a foreign
key on one of the fields. No similar option is provided for many2one either.
It is seldom used (e.g. in account_followup addons).
bzr revid: vmt@openerp.com-20110829094354-0yf6t6329j8e765q
This is necessary to preserve the model loading order
as defined in the module. This was broken when the
metaclass was introduced to make the explicit model
constructor call optional.
One consequence is that the order in which the classes
are declared in the module really defines their
initialization order, even if the constructors are
later called explcitly in a different order.
This latter case should be fairly rare, and easy to
fix too - simply putting the class declaration in the
right order.
bzr revid: odo@openerp.com-20110826161736-lgnpurtbcqtbseey
the change is not enough as we still want to differentiate between regular osv and osv
that should be wiped from the db from time to time.
bzr revid: vmt@openerp.com-20110728082752-39jur9oo0m93ebzh
expression.py now always normalize its given domain, but the evaluation code
for the orm_memory is just lacking. The fix simply skips any operator.
bzr revid: vmt@openerp.com-20110726152122-hi8y65fixcx65me8
Olivier Dony
Xavier Morel
Vo Minh Thu
Naresh (OpenERP)
sebastien beau
Antony Lesuisse
tfr(OpenERP)
Raphael Collet
gpa
Nimesh (Open ERP)