Features of DAViCal are linked to features of CalDAV client.
Comparison of CalDAV clients
|Handle Private Events||yes||yes||yes||yes||no||yes||yes|
|Handle Confidential Events||yes||yes||yes||?||no||no||yes|
|Alarm per Calendar||yes||0.8||?||?||no||yes||no|
|Auto detect subscribable calendar||wip details||yes||3.0.1, but only your own calendars|
|Access Rights: UI to manipulate ACL||wip||yes, unsupported in DAViCal||?||?||?||yes, unsupported in DAViCal|
|yes||feature implemented, and working (almost) perfectly|
|wip||work in progress, something is already there but not completely working as expected|
|x.y.z||From Client version x.y.z|
|D x.y.z||From DAViCal version x.y.z|
Handle Private Events
The user has the ability to set the privacy of an event. If set to Private the event is hidden to all except: the Administrator, the users that have the Administer's right on its calendar, or the user himself. DAViCal is able to filter and returns no information when this situation appears
Handle Confidential Events
The user has the ability to set the privacy of an event. If set to Confidential the event is visible, but only information that the user is busy. This applies to all except the Administrator, the users that have the Administer' right on its calendar, or the user themselves. DAViCal is able to filter and returns only the information needed.
The user has the ability to set an alarm on events. In Mozilla Calendar the user can set an alarm but can also recognise alarms of all other calendars. DAViCal supports alarm filtering: if the user is the Administrator, the users that have the Administer' right on its calendar, or the user themselves, the user receives an alarm for the event, otherwise the full event will be created without an alarm. For information about configuring hiding of alarms for non-owners and non-admins of calendars see hide_alarm.
Alarm per Calendar
The calendar client offers a way to specify which one of the subscribed calendar can trigger an alarm.
With such a feature, the user, with its calendar client, can request the server to find free time for all their attendees.
The client should provide a specific view like this one
General DAViCal Server Features
Multiple calendars per user
The CalDAV specifications allowed for one user to have many calendars. A calendar in the specification is called a collection and has a path like a directory in a file system, for example: I can have 2 calendars "/max/work/" "/max/home/"
for more details : Improved Permissions
You have 2 ways for doing this in the web interface provided,
- You can import in place an ics file that will replace a specific calendar collection in the server
- You can import all ics files stored on a directory on the server into DAViCal for a specific user deduced from the ics file name.
You specify the path on the server and the path of the calendars newly created, for example: on my server I have the directory /ics_files_directory, I've got 2 ics files : /ics_files_directory/max.ics,/ics_files_directory/andrew.ics. I set ics_files_directory as the path on the server, and home for the newly created calendars. All ics files will be imported respectively in collections /max/home and /andrew/home
Supported DAV Methods
GET,HEAD,OPTIONS,PUT (target exists),PUT (no target exists),PROPPATCH,PROPFIND,DELETE,LOCK (target exists),LOCK (no target exists), MKCOL, MKCALENDAR,UNLOCK,REPORT,FREEBUSY for more details : Improved Permissions
Alarms and TODO Handling
DAViCal provides a way to not share alarms and todos of a calendar when the requester of the calendar is not the owner or does not have the 'Administer' right.
for more details see LDAP Authentication
- when a user from the LDAP directory log in, and does not exist then DAViCal creates a new user or if they do exist updates the user if necessary (timestamp comparison)
- ability to sync LDAP directory to DAViCal : this operation do the following :
- check valid users in LDAP directory
- check users in DAViCal
- if a user is present in DAViCal but not in LDAP, mark them as inactive in DAViCal
- if a user is present in LDAP but not in DAViCal, create the user in DAViCal
- if a user in present in LDAP and DAViCal, update the information in DAViCal
A patch exists on the sf.net tracker for this, but it is monolithic, includes large chunks of another project, and it probably doesn't apply to current DAViCal. Someone with an interest needs to take on the job of fixing the patch, modifying it to refer to external code as external code and feeding the result to Andrew in small incremental changes.