Thu, 09 Apr 2026 22:17:55 +0000 https://bugs.horde.org/ticket/8734 Synchronization of multiple calendars with SyncML I added capabilities to synchronize multiple calendars with kronolith, inspired by the turba code. For me the patch works well with my mobile as well as with a thunderbird/lightning/funambol client. Regards Heienr Sat, 28 Nov 2009 07:48:43 +0000 https://bugs.horde.org/ticket/8734#t56885 It looks like one part is missing: finding the correct calendar out of sync_cals when updating an existing event in _kronolith_replace(). OTOH please remove the changes to _kronolith_synchronize(), this method is for Kolab. Beside those two issues, it's a great patch. Tue, 01 Dec 2009 23:05:50 +0000 https://bugs.horde.org/ticket/8734#t56953 I'd like test the patch. Can you upload it?. Thanks Wed, 02 Dec 2009 10:49:21 +0000 https://bugs.horde.org/ticket/8734#t56959 The patch is attached to this bug... Wed, 02 Dec 2009 12:46:57 +0000 https://bugs.horde.org/ticket/8734#t56960 > It looks like one part is missing: finding the correct calendar out > of sync_cals when updating an existing event in _kronolith_replace(). > OTOH please remove the changes to _kronolith_synchronize(), this > method is for Kolab. > Beside those two issues, it's a great patch. Hello, as far as I understood, the event returned by $event = $kronolith_driver->getByUID($uid); knows which calendar it belongs to, and hence no manual lookup is required. For me, the patch works, and modified events appear in the correct calendar (and are not moved to the default calendar). As the synchronization framework only knows about the events returned by _kronolith_list, events from calendars not used for synchronization should not be modified. I did not know what _kronolith_synchronize is used for, and in the turba/lib/api.php, the _turba_synchronize routine is modified in an analogous way - sorry, I removed the modifications (they did not harm in my setup, however). Best regards Thu, 03 Dec 2009 17:08:58 +0000 https://bugs.horde.org/ticket/8734#t56973 > as far as I understood, the event returned by > $event = $kronolith_driver->getByUID($uid); > knows which calendar it belongs to, and hence no manual lookup is required. This returns an event by the UID, which uniquely identifies the event across *all* calendars - in other words, two calendars that have an entry for the same event would contain the same UID so you can't be sure which calendar the event belongs to when using that method. Thu, 03 Dec 2009 17:20:00 +0000 https://bugs.horde.org/ticket/8734#t56974 > This returns an event by the UID, which uniquely identifies the event > across *all* calendars - in other words, two calendars that have an > entry for the same event would contain the same UID so you can't be > sure which calendar the event belongs to when using that method. > Thank you, now I understand the problem. I will try to solve it as soon as I find some time for it. Currently however I have no idea how to determine which calendar an event belongs to... Thu, 03 Dec 2009 17:32:02 +0000 https://bugs.horde.org/ticket/8734#t56975 > >> as far as I understood, the event returned by >> $event = $kronolith_driver->getByUID($uid); >> knows which calendar it belongs to, and hence no manual lookup is required. > > This returns an event by the UID, which uniquely identifies the event > across *all* calendars - in other words, two calendars that have an > entry for the same event would contain the same UID so you can't be > sure which calendar the event belongs to when using that method. This shouldn't happen actually, because we check for the existence of the UID when adding new events. Thu, 03 Dec 2009 17:49:05 +0000 https://bugs.horde.org/ticket/8734#t56976 The patch doesn't apply to the latest version of api.php at all. Can you provide a patch against the latest api.php version? http://cvs.horde.org/h/chora/co.php/kronolith/lib/api.php?r=1.126.2.65&p=1 Fri, 04 Dec 2009 16:55:36 +0000 https://bugs.horde.org/ticket/8734#t57003 >> This returns an event by the UID, which uniquely identifies the event >> across *all* calendars - in other words, two calendars that have an >> entry for the same event would contain the same UID so you can't be >> sure which calendar the event belongs to when using that method. >> > Thank you, now I understand the problem. I will try to solve it as > soon as I find some time for it. Currently however I have no idea how > to determine which calendar an event belongs to... I changed my mind: Actually, i did not modify _kronolith_replace() at all, so if there is a problem with UIDs not identifying an event uniquely, that problem would have existed before my modifications. Sat, 05 Dec 2009 14:54:40 +0000 https://bugs.horde.org/ticket/8734#t57013 > The patch doesn't apply to the latest version of api.php at all. Can > you provide a patch against the latest api.php version? > http://cvs.horde.org/h/chora/co.php/kronolith/lib/api.php?r=1.126.2.65&p=1 I will try to provide a patch soon (within the next one or two weeks). Is it possible to replace kronolith 2.3 api.php with the current version, or do I have to upgrade kronolith? If an upgrade is required, is it enough to upgrade kronolith only or do I have to upgrade the complete horde setup? Sat, 05 Dec 2009 15:00:58 +0000 https://bugs.horde.org/ticket/8734#t57014 > The patch doesn't apply to the latest version of api.php at all. Can > you provide a patch against the latest api.php version? > http://cvs.horde.org/h/chora/co.php/kronolith/lib/api.php?r=1.126.2.65&p=1 I attached a patch against the current FRAMEWORK_3 cvs branch. The .tar.gz file contains three .diffs for the files config/prefs.php, lib/api.php and lib/prefs.php in kronolith. I tested the code with a thunderbird/funambol client and a test server setup, for me all sorts of adding, deleting and modifying events work and are correctly synchronized. Where are conflicts handled (i.e. if the same event is changed on both client and horde before synchronizing)? I am wondering whether there is a possibility to configure what happens in that case (like duplicate event, client is right, horde is right, select newer, etc.)... Thu, 10 Dec 2009 11:37:57 +0000 https://bugs.horde.org/ticket/8734#t57106 > It looks like one part is missing: finding the correct calendar out > of sync_cals when updating an existing event in _kronolith_replace(). > OTOH please remove the changes to _kronolith_synchronize(), this > method is for Kolab. > Beside those two issues, it's a great patch. I am using the first version of the patch with a kolab 2.2.2 server, and there, the modification to _kronolith_synchronize is required. If I remove it (the second version of the patch) and create a new event in a calender selected for synchronization that is NOT the default calendar, this event will be duplicated on the client during synchronization, probably because some of the settings in the imap backend of kolab do not get correctly updated. With the patch to _kronolith_synchronize, everything works as expected. Tue, 15 Dec 2009 14:33:25 +0000 https://bugs.horde.org/ticket/8734#t57176 Thanks for the hint! Tue, 15 Dec 2009 15:06:11 +0000 https://bugs.horde.org/ticket/8734#t57177 > I attached a patch against the current FRAMEWORK_3 cvs branch. > The .tar.gz file contains three .diffs for the files > config/prefs.php, lib/api.php and lib/prefs.php in kronolith. Could it be, that the tar.gz is broken? Everytime I try do download it, I only get a empty 0 Byte sized file. Fri, 12 Feb 2010 00:53:58 +0000 https://bugs.horde.org/ticket/8734#t57970 >> I attached a patch against the current FRAMEWORK_3 cvs branch. >> The .tar.gz file contains three .diffs for the files >> config/prefs.php, lib/api.php and lib/prefs.php in kronolith. > > Could it be, that the tar.gz is broken? Everytime I try do download > it, I only get a empty 0 Byte sized file. Clicking on the little disk symbol on the right hand side of the text worked for me. I also get a 0 Byte file when I use the text link. Fri, 12 Feb 2010 18:50:20 +0000 https://bugs.horde.org/ticket/8734#t57974 > Clicking on the little disk symbol on the right hand side of the text > worked for me. I also get a 0 Byte file when I use the text link. Thanks - that worked for me too :-) Fri, 12 Feb 2010 19:27:50 +0000 https://bugs.horde.org/ticket/8734#t57975 Implemented in 3.0.5 Fri, 01 Jul 2011 20:42:43 +0000 https://bugs.horde.org/ticket/8734#t66101 Hi, > Implemented in 3.0.5 Thank you very much for this change. It seems multiple calendarsynchronizations are only working for owner-owned calendars. We have some group calendars and most of our users wants to be able to sync the calendars they have read-access to. So is it possible to add synchronaization for "not" owned calendars? Tue, 09 Aug 2011 09:59:06 +0000 https://bugs.horde.org/ticket/8734#t66877 > It seems multiple calendarsynchronizations are only working for > owner-owned calendars. We have some group calendars and most of our > users wants to be able to sync the calendars they have read-access to. > So is it possible to add synchronaization for "not" owned calendars? No. There are a number of issues with this. For your case,the most important is that there is no way to mark calendar entries readonly in activesync. Editing an event in a read only calendar would appear to work on the client,would fail to update server side which would cause the client to continuously attempt to sync this change. There is a thread on the dev list with more detailed discussion about this owner-only limitation. Fri, 12 Aug 2011 18:06:30 +0000 https://bugs.horde.org/ticket/8734#t66950 >> It seems multiple calendarsynchronizations are only working for >> owner-owned calendars. We have some group calendars and most of our >> users wants to be able to sync the calendars they have read-access to. >> So is it possible to add synchronaization for "not" owned calendars? > > No. There are a number of issues with this. For your case,the most > important is that there is no way to mark calendar entries readonly > in activesync. Editing an event in a read only calendar would appear > to work on the client,would fail to update server side which would > cause the client to continuously attempt to sync this change. There > is a thread on the dev list with more detailed discussion about this > owner-only limitation. OK, i solved this issue for me with his script... Maybe this will help someone else: #!/usr/bin/perl use DBD::mysql; use strict; # CONFIGURE my $user="$ARGV[0]"; my $database="$ARGV[1]"; my $host="localhost"; my $dbuser="root"; my $password=`gtc-crypt -a mysqlroot -p`; chomp($password); # Connect to the DB my $dbh = DBI->connect("DBI:mysql:database=$database;host=$host","$dbuser", "$password", {'RaiseError' => 1}) || die "No connection to DB $database: $? $!"; $password=""; # Create synccalendar if not exists # Get primary calendar of the user my $sth = $dbh->prepare("SELECT share_name FROM kronolith_sharesng WHERE share_owner='$user'"); $sth->execute(); my $synccal; my $nosynccal=1; my $first=1; while (my $cal = $sth->fetchrow_array()) { if ($first) { $synccal=$cal; $synccal=~s/^...../SYNC-/; $first=0; } else { if ($cal eq $synccal) { $nosynccal=0; last; } } } if (($nosynccal) && ($synccal)) { my $insert="INSERT INTO kronolith_sharesng (share_name, share_owner, share_flags, perm_creator_2, perm_creator_4, perm_creator_8, perm_creator_16, perm_creator_1024, perm_default_2, perm_default_4, perm_default_8, perm_default_16, perm_default_1024, perm_guest_2, perm_guest_4, perm_guest_8, perm_guest_16, perm_guest_1024, attribute_name, attribute_desc, attribute_color, share_parents) VALUES ('$synccal', '$user', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', 'Sync', 'Only for syncing', '#ffffff', 'NULL')"; $dbh->do($insert) || die "Error: $! $?"; } exit 1 unless ($synccal); # Get displayed calendars of user my @cals; my $sth = $dbh->prepare("SELECT pref_value FROM horde_prefs WHERE pref_scope='kronolith' AND pref_name='display_cals' AND pref_uid='$user'"); $sth->execute(); while (my $ref = $sth->fetchrow_hashref()) { my $cals= $ref->{'pref_value'}; $cals=~s/^a:.+:{//; $cals=~s/i:.;s:23://g; $cals=~s/\"//g; $cals=~s/;}$//; @cals=split(/;/, $cals); } exit 1 unless ($cals[0]); # Set Sync-Calendar in Horde-Prefs $dbh->do("DELETE FROM horde_prefs WHERE pref_uid='$user' AND pref_name='sync_calendars' AND pref_scope='kronolith'"); $dbh->do("INSERT INTO horde_prefs (pref_uid, pref_scope, pref_name, pref_value) VALUES ('$user', 'kronolith', 'sync_calendars', 'a:1:{i:0;s:23:\"$synccal\";}')"); # Clear the sync-calendar $dbh->do("DELETE FROM kronolith_events WHERE calendar_id='$synccal'"); # Copy Calendars to sync-Calendar foreach my $cal (@cals) { if ($cal eq $synccal) { next } my $sth = $dbh->prepare("SELECT * FROM kronolith_events WHERE calendar_id='$cal'"); $sth->execute(); while (my $ref = $sth->fetchrow_hashref()) { $ref->{'event_id'}=~s/^...../SYNC-/; my $insert="INSERT INTO kronolith_events (event_keywords, event_exceptions, event_recurinterval, event_recurdays, event_recurenddate, event_recurcount, event_baseid, event_exceptionoriginaldate, event_id, event_uid, event_creator_id, event_title, event_description, event_location, event_url, event_private, event_status, event_attendees, event_resources, event_modified, event_start, event_end, event_allday, event_alarm, event_alarm_methods, event_recurtype, calendar_id) VALUES ('$ref->{'event_keywords'}', '$ref->{'event_exceptions'}', '$ref->{'event_recurinterval'}', '$ref->{'event_recurdays'}', '$ref->{'event_recurenddate'}', '$ref->{'event_recurcount'}', '$ref->{'event_baseid'}', '$ref->{'event_exceptionoriginaldate'}', '$ref->{'event_id'}', '$ref->{'event_uid'}', '$ref->{'event_creator_id'}', '$ref->{'event_title'}', '$ref->{'event_description'}', '$ref->{'event_location'}', '$ref->{'event_url'}', '$ref->{'event_private'}', '$ref->{'event_status'}', '$ref->{'event_attendees'}', '$ref->{'event_resources'}', '$ref->{'event_modified'}', '$ref->{'event_start'}', '$ref->{'event_end'}', '$ref->{'event_allday'}', '$ref->{'event_alarm'}', '$ref->{'event_alarm_methods'}', '$ref->{'event_recurtype'}', '$synccal')"; $dbh->do($insert) || die "Error: $! $?"; } $sth->finish(); # Copy Horde-Histories-Settings for synchronization $sth = $dbh->prepare("SELECT * FROM horde_histories"); $sth->execute(); while (my $ref = $sth->fetchrow_hashref()) { if ($ref->{'object_uid'} =~ /^kronolith\:$cal/) { $ref->{'object_uid'}=~s/^kronolith\:$cal/kronolith\:$synccal/; my $insert="INSERT INTO horde_histories (object_uid, history_action, history_ts, history_desc, history_who, history_extra) VALUES ('$ref->{'object_uid'}', '$ref->{'history_action'}', '$ref->{'history_ts'}', '$ref->{'history_desc'}', '$ref->{'history_who'}', '$ref->{'history_extra'}')"; $dbh->do($insert) || die "Error: $! $?"; next; } if ($ref->{'object_uid'} =~ /^kronolith\:$synccal/) { $dbh->do("DELETE FROM horde_histories WHERE history_id='$ref->{'history_id'}'"); } } $sth->finish(); } Thu, 25 Aug 2011 14:39:38 +0000 https://bugs.horde.org/ticket/8734#t67115