Performing a full table lock is potentially very slow
due to the number of tables holding foreign keys towards
res_users, so we should avoid doing that for simple
auth check() calls. The point was only to avoid failing
the update of the last login timestamp, which we don't
actually care much about. So we can replace that with a
simple SELECT FOR UPDATE NOWAIT on that specific user
row and and skip the update in case the LOCK was
not granted
bzr revid: odo@openerp.com-20120813143552-3g3z0q9n1iox8a0b
Basically (and apparently), as base_crypt performs its conversion of
passwords to encrypted passwords a new request arrives and tries to
check its login, blowing up during the update.
* For the conversion, lock the whole table before updating the
passwords, as we need to touch every record anyway we can just put a
big exclusive lock on res_users
* Ideally we'd be able to just lock the relevant row of res_users in
check/_login, but for some reason I don't quite get this does not
work and still yields
> TransactionRollbackError: could not serialize access due to concurrent update
except on the SELECT FOR UPDATE query instead of the UPDATE one. The
docs don't seem to help, and replacing the FOR UPDATE row-level lock
by a table lock works even though they appear pretty much at the
same point. Me no get.
bzr revid: xmo@openerp.com-20120716064903-403pth90kupgfdv3
The cases where we filter out special periods
should in fact be the default, but this is a risky
change, so we turn this filtering on via an extra
context flag instead, which can be added by callers
as needed.
bzr revid: odo@openerp.com-20120704171726-vmkvb8dwbc9mdvs8
The cases where we filter out special periods
should in fact be the default, but this is a risky
change, so we turn this filtering on via an extra
context flag instead, which can be added by callers
as needed.
bzr revid: odo@openerp.com-20120704163307-bvu454y7if8vck8j
dateutil.parser.parse() was failing to parse the date on
some seemingly non-standard Date headers including trailing
extra TZ info, such as:
"Thu, 28 Jun 2012 18:09:47 +0200 (GMT+02:00)"
RFC2822 seems to only mention the +XXXX offset format, but
apparently other formats are employed in the wild, such
as this one coming from the Zimbra webclient.
The fuzzy matching copes with that, and an extra try/except
block was added for good measure, with a fallback on the
current datetime, should the parsing still fail.
bzr revid: odo@openerp.com-20120702154106-mwdrd9bv9xvbde0s
The `duration` used by the dhtmlx gantt component
corresponds to the calendar duration of the event
divided by 3. This makes sense only for events
spanning full days, and for working times
with 8 hours per day. Unfortunately these
hypotheses do not hold for most cases inside
OpenERP, so we should hide this information.
The actual duration of the items can always
been viewed by clicking on the corresponding
label.
bzr revid: odo@openerp.com-20120702133016-gzscrpbbh1a9mgez
Previously the date was treated as UTC, ignoring
the specified timezone offset. As a result the
displayed date was off by the actual UTC offset
of the sender's timezone
bzr revid: odo@openerp.com-20120702093523-fttsemnl1irc7917
Issue 575065
Flow for a button[@type=action] requires going through multiple RPC
calls to execute action. Due to reloading behavior of o2m-list on
actions (saves containing form then executes action then reloads row),
internal form view gets removed while e.g. server action is being
fetched (in Views#do_execute_action).
Problem: there is guard on ``rpc`` call which drops response to
stopped widget (Widget#rpc) => action/load call never returns
successfully because linked form is dead.
Solution: instead of calling View#do_execute_action via the formview,
call it via the listview (do_execute_action was already partially
overridden to change the ``on_close`` callback, override it further).
=> widget still lives, and rpc requests execute correctly leading to
all actions being correctly called (mostly).
bzr revid: xmo@openerp.com-20120629105325-vmwpyi7w3pc33sg9
* Correctly propagate current validation status of row being edited
* Automatically save row being edited upon leaving it
* Replace "Save" button (floppy) by "Cancel" (cross)
* Allow easier overriding of Groups and List sub-widgets
bzr revid: xmo@openerp.com-20120625070901-4cs6v24exjk5z2fa
Olivier Dony