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
As discussed on bug 925361, in order to have
a consistent behavior everywhere we need default
values to be using the client's timezone, just
as if the user had set the value themselves
using their local clock.
Because fields.date values are timezone
agnostic by design, they must be correctly
initialized from the start, no conversion
happens later.
The new context_today method is mean to be
easily usable as _defaults initialize, i.e.:
'date_field': fields.date.context_today
is all that is needed.
It also avoids the classical mistake of
forgetting to make the default value
dynamic and directly passing the result of
a time.strftime() call.
lp bug: https://launchpad.net/bugs/925361 fixed
bzr revid: odo@openerp.com-20120213180355-ruyw5j2w7r06kyue
Warnings are handled with the other logs (and not always sent to stderr),
they also appear under a module __name__ channel instead of py.warn.
The disadvantage is that there is no longer specific warnings,
such as pending deprecation warning or deprecation warning.
bzr revid: vmt@openerp.com-20120125132407-u33idc0qh7ecs1i5
Thibault Delavallée
Stephane Wirtel
Fabien Pinckaers
Fabien Pinckaers
niv-openerp
Antony Lesuisse
Olivier Dony
Xavier Morel
Vo Minh Thu
Guewen Baconnier
Naresh (OpenERP)