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
A PendingDeprecationWarning is used in order to reduce the
verbosity of the logging, and to indicate that we might
forbid passing required=True in a future OpenERP version
for fields types where it makes no sense.
bzr revid: odo@openerp.com-20111021142836-0k4qruhe1vgodysu
This allows for transparent inheritance of m2m columns via _inherit,
as long as the m2m relationship table is not explicitly named in
the declaration.
bzr revid: odo@openerp.com-20110926171451-n2jg8pbl5mq715vk
We have a workaround in place for fields.function of binary type
that may return values that are invalid in XML documents, and thus
in our XML-RPC protocol. But out workaround failed to care for the
invalid XML codepoints (below 0x1f) that are well valid in UTF-8
encoding.
Added a sanity check for that as well, using a terrible workaround
for this last resort case: b64-encode the bytes, to avoid crashing
the request.
bzr revid: odo@openerp.com-20110906173140-vc4tl6wstzt8h06o
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
There was no need to wrap/cast int values for values less
than 2^31-1, which the highest XML-RPC int value.
Also, instead of wrapping them in strings, we can use
float values, which are 64bits based in the XMLRPC standard,
and closer to the real value (for comparisons, etc.).
Added note for integer_big, as a reminder of this possible
issue.
bzr revid: qdp-launchpad@openerp.com-20110818120550-ulvffm6ka9f3c5ym