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
Yes, I have been subclassing the DAV module and improving on the existing
code, regarding that we couldn't ship our own version of the whole
python-webdav library (as in v5.x).
At commit b2a2c3f95416788, on 2010-04-06, we explicitly deleted our custom
copies of the DAV module and linked to the upstream project, in fact.
bzr revid: p_christ@hol.gr-20101209095950-qf2ppgdxw8y2lake
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
The gnome gvfs component falsely requires that / will serve PROPFIND
requests. We reuse the static-http capability of the server (force
activation rather than opt-in default behavior) and serve pseudo-DAV
properties for the root.
Conflicts:
document_webdav/webdav_server.py
bzr revid: p_christ@hol.gr-20101123185011-besih03q4gt2atps
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 is another workaround for nautilus, that descends into the db (=does
authorization) and then requests info for the parent again
(causing db=False later).
bzr revid: p_christ@hol.gr-20100624150122-tntum07kgth2ogup
Python-webdav does not follow the http protocol for persistent connections,
nor does it accept patches. So, override their functions.
bzr revid: p_christ@hol.gr-20100624150054-iwuvgehsyjr7qghv
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