+ do NOT use ORGANIZER for events without further participants or a different organizer
+ do not include event owner/ORGANIZER as participant in his own calendar, if he is only participant
--> all other cases include ORGANZIER and additional as ATTENDEE (tested with iCal on iOS and OS X)
- implemented schedule-tag and If-Schedule-Tag-Match header from CalDAV Scheduling
- allow to change participant status and add/remove alarms with schedule-tag instead of ETag
--> If-Schedule-Tag-Match header has precedence over If-Match (ETag) header, but limits changes to participant status and alarms
--> ToDo: test accepting, rejecting recurrences
--> participants are - thanks to CalDAV scheduling - now setable for new event, thought searching for them does NOT yet work, no idea why ;-)
- added somehow missing calendar-query report to supported-report-set
- had to implement a workaround for Lightning, as it wrongly interprets principal-property-search for calendar-home-set in the principal-collection-set
matching our *DAV root returning all principals, as all have a matching calendar-home-set, as NOT supporting CalDAV scheduling
--> search only current user's principal, when Lightning searches for calendar-home-set
- OPTIONS / return now calendar-auto-scheduling too, as Lightning only searches there, to check if server supports CalDAV scheduling
- fixed outbox freebusy request to cope with no X-CALENDARSERVER-MASK-UID and a single attendee
- principal reports scheduling-inbox-URL /<username>/inbox/ and scheduling-outbox-URL /<username>/outbox/
- outbox collection contains no events
- outbox correctly answers POST for freebusy information
- outbox respons to all other POST with "204 No Content", ignore client request to deliver invitations
- inbox collection contains events of unknown status (PARTSTAT=NEEDS-ACTION)
- inbox responds to DELETE with "200 Ok"
--> iCal under OS X now shows freebusy times :-)
(had to add "write-content" privilege for calendar collections user has edit rights for, to allow adding events)
+ currently only standard WebDAV privileges: read, read-current-user-privilege-set, write-content, bind and unbind used
+ they get only queried for collections, thought we dont report any write* on collections, as we dont allow to create calendars or change properties
- new groupdav::add_resource() method used to add all resources (incl. collections) to propfind or report requests
- improved autoindex to show nicely indented hierarchical properties
- re-enabling propfind iterator again for calendar (fetching events in chunks of 500), to lower memory footprint
Please note: changed SQL queries used for CalDAV do not take changed participants (or status) in exceptions into account
- Lightning pops up alarm, until Sequence/etag get updated: if user has no edit rights on an other users calendar, etag never got updated, now we update it
- fixed user was not able to add alarms via CalDAV, if he had no edit rights for event (was always possible in web UI)
- alarms from other users calendars are not included any more, as they make no sense but a lot of trouble
- fixed wrong condition on adding alarms, causing some alarms no being saved
Replacement code for in r29270 removed filter
$cal_filters['query']['cal_reference'] = 0;
only works, if all recurrences and the master are returned in a single chunk, otherwise events get returned multiple times"
resource of the series master. Now the status of single recurrences of a
serie are send to the clients as (virtual) exceptions as Jaytrax&Joerg
implemented it already for SyncML.
The implementation is unfortunately a little different, as CalDAV
differs from SyncML and I dont know the SyncML part that well. Maybe we
can re-unify the code again together.
Tested so far with Tb3/Lightning1.0b and a little with iPhone.
Please let me know, if you run into problems with other clients.
Patch is mostly created by script in egroupware/doc/fix_depricated.php in separate commit.
I do NOT advice to apply this patch to a production system (it's commited to trunk!), as the automatic modified regular expressions have a good change to break something ...
manufacturer and the recogniced GroupDAV client as product name.
This way we are able to handle different GroupDAV clients, as we
allready do with different SyncML clients.
Also removed the no longer needed code enabling the use of the real UID,
as SyncML does no longer misuse the UID for it's GUID.
- new GroupDAV v2 component-set attribute for collections
- getlastmodified & getcontentlength properties for infolog propfind
- fixed propfind on a single infolog entry to return just that entry
- getcontenttype of vevent and vtodo collection returns extra component
addressbook (infolog will follow).
CalDAV is tested so far with lightning 0.8 and Apple's iCal. Please note
that both distinguish between iCalServer and CalDAV!
The URL is currently http://domain.com/egroupware/groupdav.php/calendar/
