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
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 should solve the following: When we reply to PROPFIND requests etc,
we provide the absolute url of ourselves like:
<D:href>http://our.server:8069/webdav/mydb/Documents</D:href>
The problem is that if we bind to 0.0.0.0 and the interface, which the
client connects through, doesn't resolve from "our.server", then we are
practically redirecting the client to the wrong address.
This is expected to happen at openerp servers w/o full qualified names and
reverse resolution of their interfaces.
Requires server patch (at websrv_lib) to function, fallbacks to old code
on trouble.
bzr revid: p_christ@hol.gr-20100926163210-v8scuvhg991jbbzc
An ETag should refer to the requested uri, so a Location header will
render it invalid anyway. Gnome's evolution has an if-else block that
first checks ETag and then Location.
bzr revid: p_christ@hol.gr-20100812111025-xoilqlb956moovgv
We must check the "If-Match" header. Its value is quoted, so try to
remove quotes (crude way), and also consume any body before we respond
with 4xx.
Conflicts:
document_webdav/webdav_server.py
bzr revid: p_christ@hol.gr-20100801083828-lh9htiqlwewvhloh
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
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
The NotFound one should properly parse the list uri2. Define a helper
function that will wrap around usual calls and handle their exceptions.
bzr revid: p_christ@hol.gr-20100712192930-necdd0z9d2j6w4ut
P. Christeas