Setup for Apple Users

The applications used on Apple devices can be made to configure simply if you set your server configuration up to cater to them:


 * Running an SSL server on port 8443 (CalDAV and CardDAV), or a plain HTTP server on port 8008 (for CalDAV) and 8800 (for CardDAV).
 * Running from the root of the server
 * Using mod_rewrite to translate request URLs

If you install DAViCal in a subdirectory, or run it on a port other than 8443 (SSL) or 8008 and 8800 (unencrypted) then clients using the Apple devices will need to go into the advanced settings and configure the full URL, as detailed in the installation instructions for iCal and iPhone (the iPod instructions are the same as for the iPhone).

The use of mod_rewrite for URL Rewriting is explained in the Apache Config section.

If that's all set up...
When your server is properly configured with all of the above, it should be possible for users to configure iCal or iPhone by entering only: and the client should auto-discover all the rest.
 * The server hostname
 * The username
 * The password

It has been reported that clientside the path should omit the trailing '/home' or '/home/'.

Different database layout expected for iOS 7 queries
Should be resolved in 1.1.2

Symptoms: Users aren't able to connect to any of their existing collections. Instead iOS will create new collections that it names after a 128bit hex number scheme that then shows up in the administration interface.

Cause: iOS 7 REQUIRES separate collections for VEVENT a VTODO components (otherwise it completely ignores the existing collections).

Solution: You need to manually set the  for existing collections to VEVENT (and move the remaining data to new VTODO collection).

For existing collections insert the following SQL statement (e.g. with ):

INSERT INTO property (dav_name, property_name, property_value, changed_by) VALUES (<'/user/collection/'>, 'urn:ietf:params:xml:ns:caldav:supported-calendar-component-set', , );

Replace  with a valid collection name already existing in your database.

Replace  with the calendar component type (e.g., VEVENT,VTODO, etc.) that your resources can contain:


 * for "event" only collections use:

''


 * for "todo" only collections use:

''


 * for "todo" and "event" collections (all data in one collection) use:

''

Replace  with a valid integer value from "user_no" column in the "usr" table

Example:

INSERT INTO property (dav_name, property_name, property_value, changed_by) VALUES ('/bob/calendar/', 'urn:ietf:params:xml:ns:caldav:supported-calendar-component-set', '', 42);

You could also use:

$c->default_calendar_components = array( 'VEVENT', 'VTODO', 'VJOURNAL', 'VTIMEZONE', 'VFREEBUSY', 'VAVAILABILITY' );

... it sets the default supported components for all collections without  property, but it is not the best idea for environment with iOS clients because iOS always creates separate calendars for events and todos.

iCal handles principal grants, not collection grants
So you need to restrict access at the collection level after granting broader access at the principal level, and users may still see delegated calendars that they cannot actually read and/or write to.

Lookback on iPhone
If you get a blank calendar on an iPhone the standard fix seems to be to set the look back for 'Only last two weeks of events' (you still see all future events, of course). I have no idea why this might be the case, but changing that setting has so frequently fixed the problem that it has to be mentioned... Should be resolved in 0.9.9.5.