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.
new option: if set to PHP regex string then hide_TODO is enabled if the client
user-agent string matches the regex for example:
$c->hide_TODO='#^iOS.*dataaccessd.*#';
will hide all todos from non-owner/non-admin users for iOS devices
* Changed the end-of-line encodings of all non-Windows-related and non-autogenerated text files to use UNIX LF (lots of them had mixed LF/CRLF).
Conflicts:
inc/caldav-PUT-functions.php
The resource data element is not *actually* allowed, per the spec, but
some clients do use it, and some servers do support it. In the case
of an initial sync which requests it we don't want to send down a huge
response to an ill-considered client.
When the WebDAV sync draft first came out the responses were each
contained in a DAV::sync-response tag, but by -03 this has changed
to a DAV::response tag since the format of the tag contents now
match this existing tag structure.
Unfortunately some client software in the wild depends on this
being a DAV::sync-response so the config option is needed to
interoperate with this software.
The sync-collection report was looking for $request->CollectionID()
but this is not set for bound collections and we have to use
DAVResource methods to retrieve it.
This is so we get dav_name correct for delete actions, which
will otherwise be null since there is no caldav_data or
calendar_item record for them any longer.
