This was causing binding/1038-PROPFIND-Depth-2 to fail as the getctag that
was found didn't match what was expected. Looking at how bound collections
are handled, there is a lot of metadata that we're missing.
Preferably we'd cache or otherwise restore that metadata, but I'm going
to leave that as a future enhancement. ;)
The test regression-suite/0549-iCal-REPORT was failing due to us not
keeping track of the proxy information when storing/fetching collections
from the cache.
The calendar-sync REPORT fetches the collection as a DAVResource, then
instantiates a DAVResource for each event in the collection.
Unfortunately, ByRow in DAVResource fetches the resource's collection from the
database!
This commit populates each DAVResource's collection field with the
already-fetched collection when performing calendar-sync queries.
dead_properties is an assoc.array from name to value, but it was being merged
with simple arrays of property names.
This means that tests 0824 and 0828 now actually return the dead properties, so
I've updated those result files.
Signed-off-by: Jamie McClymont <jamiemcclymont@catalyst.net.nz>
case 'urn:ietf:params:xml:ns:caldav:max-resource-size': /** Ignored, since we will support arbitrary size */
this solves issue #80 (large contact photos not being accepted by the server). we might wanna think about a larger limit instead, e.g. increase the limit from 65kB to 6.5MB
Otherwise we cannot be sure if the resource we are looking at is a
proxy. Looking at the request as we did in DAVPrincipal is wrong, as one
request can result in several resources to be examined, only some of
which may be proxies.
BTW looking at the regression test changes, I'm not sure having
calendar-proxy-read-for on proxy principals is correct, but caldav-proxy
seems to have nothing to say on that so we leave it for now.
and a few more bits inspired by CalDAV/aclreports.xml:
- strict Depth header checking
- principal-match: match on dav_name if not $match_self
- principal-match can "alternatively" return resources in a collection
that belong to a principal, like a user's calendars when we query
the principal URI
Fix add-member support for calendars
Change the add-member parameter to add_member to match the name of the global variable name. Otherwise the global variable was always unset and the generic POST handler handled the request instead of the PUT handler for vcalendars.
Make sure to return a Location header when adding a vcalendar using add-member POST.
See merge request !14
