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 the DAV client requests properties for a relative URI (without the
protocol:ip:port part), it means it can also understand responses with
relative notation, so don't bother calculating the prefix (non-trivial).
This fixes the REPORT responses to Mozilla Sunbird.
bzr revid: p_christ@hol.gr-20101014125118-3x5ivmrbaqwb1nsx
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
When DAV-aware nodes want to return properties, they might need to
have xml attributes or single instances of sub-elements.
Example:
return ('aprop', 'D:', ('foo', 'D:', None, { 'name': 'bar'}))
will result in xml:
<D:prop>
<D:aprop><D:foo name="bar"/></D:aprop>
</D:prop>
bzr revid: p_christ@hol.gr-20101012104029-gq6hhjki4i52n8qh
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
Several small fixes for the DAV responses, so that we are more conforming
to the protocol. Also fix multiple namespaces, getctag and (as always)
whitespace
bzr revid: p_christ@hol.gr-20100729133937-z6ctpn92w6mz7r9k
This is a reshape of the code, since the porting. While the MultiHttpHandler
will strip the '/webdav' part of the path, the DAV code will try to
generate more paths without it. So, there must be consinstent functions
that will convert (at mk_prop_response and mk_propname_response) to the
full path or back. Also, only have one function that will strip the
db name from the path, so that we control the auth requirements (for the
purpose of database listings, which shouldn't require authentication).
bzr revid: p_christ@hol.gr-20100623105437-kmy0ccqihu5h9ydp
Cecile Tonglet
dle@openerp.com
Antony Lesuisse
Vo Minh Thu
Antonin Bourguignon
Hardik
Numerigraphe - Lionel Sausin
P. Christeas
rpa (Open ERP)
vra
Harry (Open ERP)