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
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
-_get_defaults(): improved docstring in order to follow RST docstring format
-_get_defaults(): removed weird loop in _get_defaults as there is always 1 element only
-_fnct_read(): make name_get as root
-_fnct_read(): check existence for m2o fields (as root)
-_fnct_read(): check for type of property field is now done on reliable information
bzr revid: qdp-launchpad@openerp.com-20110708125106-0q0wj5zncaa7yp0w
The 'method' param was quite useless, as 100% of functions
fields were using method=True. In addition, there is no need
to distinguish methods and functions, as methods are unbound
and passed as function objects in the declaration of a function
field, so they only need a proper signature.
Finally, docstring was added for fields.function class,
based on current doc from developer book (in preparation of
future API doc).
(A fix in addons follows, getting rid of all the useless
method=True params there too).
bzr revid: odo@openerp.com-20110701232328-flgxulxva70vnyxr
This is because the permissions for reading the display name
of a m2o record does not depend on access to the target table,
but depends on the user access to the current table.
Users that are denied read access to the target table may still
see the names of the records linked to the documents they can
read
bzr revid: odo@openerp.com-20110619171102-sh0derdj50epea7b
- Some logging code moved from netsvc.py to loglevels.py
- Changed imports to use the new openerp module
- config and netsvc initialization calls move to openerp-server.py
- Moved openerp-server.py outside the old bin directory
- Some imports in tools moved inside the methods to break mutual-dependencies
bzr revid: vmt@openerp.com-20110207125723-ooee7d7ng5elmkso
Thibault Delavallée
niv-openerp
Antony Lesuisse
Olivier Dony
Xavier Morel
tfr@openerp.com
Fabien Pinckaers
Vo Minh Thu
Raphael Collet
Guewen Baconnier
Naresh (OpenERP)
Quentin (OpenERP)
Yogesh (OpenERP)
sebastien beau
gpa
P. Christeas