revno 4821, revision-id tfr@openerp.com-20110628141309-oag99snygj3vuqwn :
pooler.get_db_only was removed from the server but not from the addons.
It seems the commit 4821 tried to solved the situation by using get_db
instead, which is wrong and it will load the db instead of just trying
to get a cursor. This commit solves correctly the removel of get_db_only:
by using sql_db.db_connect (for which get_db_only was an alias).
bzr revid: vmt@openerp.com-20110909113916-td9o8yct0u5bitb6
Reported by: Dr. Ferdinand Gassauer
Locations that contain a semicolon are split by the urlparse.urlparse(),
thus setting their 'path' and 'params' return fields (rather than just
the 'path'). In our syntax, there is no params, so the part after the
semicolon needs to be appended back to the patch.
bzr revid: p_christ@hol.gr-20110118165021-4knt76njdqnt1eln
Branch patch11 had somewhere been lost in bzr hell.
Conflicts:
account/account_move_line.py
document_webdav/nodes.py
document_webdav/webdav_server.py
event_project/__init__.py
users_ldap/users_ldap.py
bzr revid: p_christ@hol.gr-20101223155444-ym8r0g4208gm88j9
This replaces the pseydo-locking of python-webdav library with a real
db-based locking. Locks are stored as DAV properties, which will
effectively also be listed in the PROPFIND response of the nodes.
With locking in place, Office suites can collaborate on documents online.
bzr revid: p_christ@hol.gr-20101207134041-8negkvxrbscv7fs7
If you are trying to expose your OpenERP server through a DNAT box,
the propfind (aka. folders listing in WebDAV) must reference the external
IP/host that the client asked for. Use the more expensive "get_baseuri()"
of the interface class for that.
bzr revid: p_christ@hol.gr-20101207134005-v3oxr7zwbheiylxv
If user rights are not setup for the user that connects to WebDAV, this
exception will occur and the typo would not help debug the problem.
(still, the user won't see the items at either case)
bzr revid: p_christ@hol.gr-20101014110323-zxj5oha0u96e2l1t
This report is a request to fetch multiple calendar entries. The
request contains a range of URIs to fetch, which must be processed
at the dav_fs.Report level.
The report is being called with Depth: 0 , for which the library could
not perform an iterator. Hack over it and explictly set Depth:1 in our
case.
bzr revid: p_christ@hol.gr-20101012104103-eu156146jy4a75af
It is unavoidable. Some user agents (i-#$^%) have serious trouble with
protocol extensions they don't support. So, we have to hide a few of
our capabilities with quirk code.
bzr revid: p_christ@hol.gr-20101012104102-xakiyykjqsu16q2o
This property is used in DAV folders, CalDAV, GroupDAV and CardDAV, with
different extensions at each one. So, it needs an extensible API for the
value it may return.
Typical response in a calendar dir:
<D:resourcetype>
<D:collection>
<ns0:vevent-collection xmlns:ns0="http://groupdav.org"/>
<ns1:calendar xmlns:ns1="urn:ietf:params:xml:ns:caldav" />
</D:resourcetype>
The last two elements have to be added by subclassing the node in the
caldav module.
Conflicts:
document_webdav/dav_fs.py
bzr revid: p_christ@hol.gr-20100801083722-nh4ty58fy0hobrgk
create_date, write_date may not be specified as object fields, so we
cannot always call them. Use the perm_read() instead (which works for
all objects). However, the datetime returned may have fractional secs,
in which case a better conversion function shall be used.
bzr revid: p_christ@hol.gr-20100729133937-fslzb5xba2pq5grj