OpenERP depends on PostgreSQL 8.3 so we can now
use 'IF EXISTS'. It's also necessary to 'CASCADE'
the drop, otherwise depending views will prevent
the deletion and thus update of the view.
Depending views will automatically be updated
later and thus re-created, so this is safe.
bzr revid: odo@openerp.com-20120227165737-z5fgb6fle9g0cylw
This is for example used by hr.employee which
inherits from resource.resource, with the
`active` field located on the resource model.
Simplified some code too.
bzr revid: odo@openerp.com-20120223141635-p117b5wvvreuj40c
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
This is essential to have the proper behavior for
timestamps: on the database side we exclusively
store UTC data (no DST issues, etc.) as naive
timestamps (to prevent Postgres from messing with them).
Inside OpenERP server/addons we work again with
pure UTC data (much simpler), and only render
them according to the user's timezone when they
are displayed in the user interface or rendered
in a PDF report.
lp bug: https://launchpad.net/bugs/918257 fixed
bzr revid: odo@openerp.com-20120220105943-v3m0i50phrurt8x6
The processing of <report> tags during XML file
processing is not modular or extensible, which
means that extra reporting engines cannot easily
add custom behavior for <report> records of their
type. By returning the newly created ID in
the tag_report() method we at least allow them
to hook up a monkey-patch without need to copy-
paste the original code.
This patch also allows an extra XML attribute
for webkit headers, because the original @header
attribute is reserved for a boolean value.
bzr revid: odo@openerp.com-20120214135255-a7hyxsoif4jhg6ro
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
Any running transaction that has created or altered
a record that contains a FK to the user is automatically
holding an SharedRowLock that prevents login() from
updating the last login date. As we cannot delay the
login() until all such transactions are finished,
it's simpler to try to get the lock and if that
fails, we skip the login date update for once,
no big deal.
A typical candidate for this situation is the
Admin user, locked out by long running cron
jobs that touch rows as Admin, hence holding
a ShareRowLock to res.users ID 1 because of the
many create_uid/write_uid foreign keys.
lp bug: https://launchpad.net/bugs/713216 fixed
bzr revid: odo@openerp.com-20120213183207-45ptopqm0szritgx
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
Olivier Dony
Launchpad Translations on behalf of openerp
Christophe Simonis
Antony Lesuisse
Xavier Morel
Vo Minh Thu