Renamed the m2m extra info keys, as their names
were quite confusing (third_table?), + removed
the "func_obj" key for function fields, as
it was a duplicate of the "relation" kay that
is already present for all relationship fields.
These renames should not break anything, as this
info should only be used for debug, but they still
constitute an API backwards-incompatible change.
bzr revid: odo@openerp.com-20120926130942-doauqgh6v35vhi29
Use: 'my_field': fields.char('Old field', size=64, deprecated="This field will be removed as of version 42 of OpenERP. Please update your module to use 'my_new_field' instead.")
bzr revid: tde@openerp.com-20120809083103-pjc9ynvmtojnfnah
This is a partial implementation with no support for
restricting read/write access via RPC. This first
part only covers the removal of the restricted fields
from the client-side view, i.e. in the results of
fields_view_get() and fields_get().
The second part will come later and will cover the
real low-level access control.
bzr revid: odo@openerp.com-20120518143625-ps9db62vzrc2pylh
apparently we do weird things with __builtins__, on my machine it's consistently an alias to the __builtin__ importable module, but in the server it's a dict
bzr revid: xmo@openerp.com-20120419130245-ael83wc5h310m38s
corrected some typo `.. in (xxx)` instead of `.. in (xxx,)` (Note the trailing comma).
There is still a (non-harmful) reference to one2one in the base_synchro addons.
bzr revid: vmt@openerp.com-20120322164540-9rl8iidj4wrjohru
The fields.binary type allows storing arbitrary
byte arrays, but it has been used historically
to store base64-encoded versions of the binaries.
This was partially related to the way these binary
values are serialized when transferred using the
standard XML-RPC protocol.
With the introduction of JSON-based RPC calls
alongside the 6.1 web client, these base64-encoded
binaries may now be deserialized as unicode ASCII
strings instead of 8-bit strings. That seems like
an acceptable behavior and we can simply coerce
these unicode strings to bytes strings as we know
they will be pure ASCII. Any non-ASCII unicode
value for binary field makes no sense and should
be passed as a byte string directly.
Thanks to Rui Barreiros for providing the final
hint in bug 919982 comments that lead to the
identification of this bug.
lp bug: https://launchpad.net/bugs/899794 fixed
bzr revid: odo@openerp.com-20120222093937-quifmtsfc9gaa9ar
The ORM automatically passes a Model instance
as the first argument to _default callables,
historically provided to give lambda functions
access to the Model instance.
context_today() does not need it but takes it
for compatibility purposes.
This also means that when called explicitly
within business code we should now pass a
Model instance as first argument, typically 'self'
bzr revid: odo@openerp.com-20120214122413-rznpdyqajrzswk4o
- optional datetime was not being used
- parameter renamed to timestamp to better
indicate that it must be a datetime, not
a simple date
bzr revid: odo@openerp.com-20120214085044-unpa77hork25gtif
Christophe Matthieu
Thibault Delavallée
Raphael Collet
Xavier Morel
Olivier Dony
Stephane Wirtel
Fabien Pinckaers
Fabien Pinckaers
niv-openerp
Antony Lesuisse
Vo Minh Thu