How can I migrate to DAViCal using already generated .ics files?
From DAViCal Wiki
If you can export your current user calendars to several iCalendar files, then migrating to DAViCal is a really easy task.
Contents |
Exporting iCalendar files from your current system
Exporting your existing calendars depend on your current calendar system.
Please, add below the process for other calendar systems.
Sun Java Enterprise System
Exporting from JES is really easy. The utility cscal lists current users and calendars, and csexport lets you export an specific calendar.
You can use the following script:
#!/bin/bash
EXECUTABLESDIR=/calendar/opt/SUNWics5/cal/lib
OUTPUTDIR=/exported_calendars
UMASKINITIAL=`umask`
# csexport exports calendars using 'icsuser' as the user
# Let him write on /exported_calendars
umask 000
cd $EXECUTABLESDIR
mkdir -p $OUTPUTDIR
# cscal output is as follows:
#
# perula: owner=perula status=enabled
#
# We sort it to make it easier to generate directories
$EXECUTABLESDIR/cscal list |awk '{print $2, $1, $3}'|sed 's_^owner=__g'|sort> $OUTPUTDIR/calendar-list
# Let's create a directory for each user, and his/her calendars will be
# exported inside it
cat $OUTPUTDIR/calendar-list | while read i; do
CURRENT_USER=`echo "$i"|awk '{print $1}'`
# Remove trailing ':' from main calendars
# Additional calendars are not affected by this
CURRENT_CALENDAR=`echo "$i"|awk '{print $2}'|sed 's_:$__g'`
# Create user directory and export calendar
mkdir -p $OUTPUTDIR/$CURRENT_USER
$EXECUTABLESDIR/csexport -c $CURRENT_CALENDAR calendar \
$OUTPUTDIR/$CURRENT_USER/${CURRENT_CALENDAR}.ics
done
umask $UMASKINITIAL
This will generate a /exported_calendars directory (name by default) with the following tree structure:
exported_calendars/ ├── aacal │ └── aacal.ics ├── agenda1 │ ├── agenda1:Agenda1Prueba.ics │ └── agenda1.ics ...
Importing .ics files to DAViCal
Let's suppose you now have a bunch of ics files from your users. How can you put them DAViCal?
Enable full collection writing in DAViCal
You have to set the following options in your DAViCal configuration file:
$c->readonly_webdav_collections = FALSE; $c->writable_dav_collections = TRUE;
Create an administrative account
Use the default admin user or create a new one with 'Administrator' flag. It will be used to create every single calendar.
Import the calendars
We will use curl to add our existing calendars.
I have used the following script with the previous directory tree format:
#!/bin/bash
URLBASE=http://davical_host/caldav.php
USR_ADMIN=admin_user
PASSWORD_ADMIN=admin_passwd
# Exported files
if [ ! -d exported_calendars/ ]; then
echo "Missing exported_calendars/"
exit 1
fi
find exported_calendars/ -name *.ics | while read i; do
# Format:
# exported_calendars/user/name.ics
USR=`echo "$i"|cut -f 2 -d '/'`
CALENDAR_NAME=`echo "$i"|cut -f 3 -d '/'|sed 's_\.ics$__g'`
# Default calendar is 'home' (change it here)
# Other calendars (user:xxx) get translated into 'xxx'
EXPSIMPLE=s/^${USR}\$/home/g
CALENDAR_NAME=`echo "$CALENDAR_NAME"|sed "$EXPSIMPLE"|sed 's_^.*:\(.*\)$_\1_g'`
echo DEBUG \[$i\] $USR, $CALENDAR_NAME >&2
# Use cURL
URL=${URLBASE}/${USR}/${CALENDAR_NAME}/
curl --insecure --basic --request PUT --header \
"Content-Type: text/calendar; charset=utf-8" \
-u ${USR_ADMIN}:${PASSWORD_ADMIN} \
--data-binary @${i} \
$URL
if [ $? -ne 0 ]; then
echo ERROR with user $USR, calendar $CALENDAR_NAME >&2
fi
done
This way every calendar gets put on caldav.php/username/calendar_name.
Disable again full collection writing in DAViCal
Set previously changed settings about DAV collections to default values:
$c->readonly_webdav_collections = TRUE; $c->writable_dav_collections = FALSE;
Post migration notes
Fixing collection user assignation
If your users were not created/synchronized before the calendar import proccess, then your DAV collections lack the user_no column on DB, so those collections are not associated to the users. This can be seen in DAViCal interface on each user, which has associated no collections. Although users can access their own collections, some calendar clients such as iCal or Sunbird don't behave correctly with this situation.
When you have all your users created (they logged in for the first time and they got created, or you just launched a synchronization) then you can use the following commands to launch an SQL query to correct all the user_no NULL values. SQL query by courtesy of karora:
# su postgres $ psql davical \ -c "UPDATE collection SET user_no = (SELECT user_no FROM usr WHERE username = substring(parent_container,2,length(parent_container)-2)) WHERE user_no IS NULL;""
After that, every collection should be associated to its owner.

