Recurring event looses alarm on import or sync

[Achim_Konigs]

Hi,

I recently noticed that on a slow sync many of my birthday events loose their alarms. At first I thought the sync on the client end was at fault, but then I started to track this problem a bit and I think there is a fault somewhere in eGroupware… I am using the latest debian package of eGroupware on a ubuntu system with apache 2 and PHP Version 5.3.10-1ubuntu3.2.

I did a search on that issue and found some complaints and so from other people that might be related, but there were no real reactions on them, neither with useful solutions nor with “it’s a bug, we are going to solve that”.

Basically, what I think, what is the issue, is that alarms in the past are discarded. I usually create real birthday events, i.e. an event in say 14th July 1981 which recurs every year on the 14th of July and has an alarm set to remind me of that event… now if I take that event and export it as iCal from the calendar, I get an iCal with the alarm correctly specified, like here:

BEGIN:VCALENDAR

BEGIN:VEVENT
DTSTART;VALUE=DATE:19810714
DTEND;VALUE=DATE:19810715
SUMMARY:Birthday Test

RRULE:FREQ=YEARLY

BEGIN:VALARM
TRIGGER;VALUE=DATE-TIME;TZID=Europe/Paris:19810713T180000
ACTION:DISPLAY
DESCRIPTION:Birthday Test
END:VALARM
END:VEVENT
END:VCALENDAR

Now if I re-import that very ics file that eGroupware produced for me into the calendar the alarm is gone. That clearly is an issue… I would try to patch eGroupware, but I’d need some directions on where that alarm is discarded. Or at least maybe a rough roadmap, which way an event takes from being an ics that is imported towards being stored in the database (hopefully that would be similar for a web-based import and a sync). I suspect that somewhere the “can’t do alarms in the past” guard is triggered during the import (it’s the same on a sync via SyncML and I suspect also via GroupDav), which is not so nice for recurring events…

Is there any sensible work around? Where is that check done? Is there any possibility to change it to accept alarms for recurring events and transfer them into the future in the right way? I know that this is done somewhere, too, because the alarm always shows for the next occurrence of the event and if that passes by the alarm is activated on the next occurrence respectively.

This really is bugging me for months, now… I always suspected my sync process to be at fault… but now that I dug a bit more into that, it is clearly a fault in eGroupware… the import of an exported and unchanged event should never change the original event.

Cheers
Achim

[Achim_Konigs]

Ok, I seem to have fixed it by myself.

I just copied the code that cares for shifting alarms in the past for recurring events from calendar/inc/class.clanendar_so.inc.php at line 1268 to calendar/inc/class.calendar_ical.inc.php after line 1441 and modified it only a little bit (I removed the “continues”, because I did not really understand if that could have bad side effects).

That is what I added:
if ($alarm[‘time’] < time())
{
//pgoerzen: don’t add an alarm in the past
if ($event[‘recur_type’] != MCAL_RECUR_NONE)
{
$start = (int)time() + $alarm[‘offset’];
$event[‘start’] = $event[‘cal_start’];
$event[‘end’] = $event[‘cal_end’];
$event[‘tzid’] = $event[‘cal_tzid’];
$rrule = calendar_rrule::event2rrule($event, false);
foreach ($rrule as $time)
{
if ($start < ($ts = egw_time::to($time,‘server’))) break;
$ts = 0;
}
if ($ts)
{
$alarm[‘time’] = $ts - $alarm[‘offset’];
}
}
}

On my first tests that worked fine. If somebody can explain me how, I could also try to create a patch for that…
I really hope this change (or something similar) makes it into the code base.

Best regards
Achim

[Achim_Konigs]

sync_recurring_alarm.diff (1.16 KB)

I managed to create a diff file against the trunk version of the calendar. Hopefully you now are able to include that change into your development version? Or do I really need to create another account and create a ticket for that? :-p
Would be great. For me the fix works great for some time now and I don’t loose alarms on slow syncs anymore.

Cheers
Achim

[Ralf_Becker_Stylite]

Hi Achim,

http://egroupware.219119.n3.nabble.com/file/n3984752/sync_recurring_alarm.diff
sync_recurring_alarm.diff

I managed to create a diff file against the trunk version of the calendar.
Hopefully you now are able to include that change into your development
version? Or do I really need to create another account and create a ticket
for that? :-p
Would be great. For me the fix works great for some time now and I don’t
loose alarms on slow syncs anymore.

Thanks for the patch, I modified it a bit, to not doublicate the code:

http://svn.stylite.de/viewvc/egroupware?revision=39851&view=revision

Please check if it still works for you, then I can backport it to 1.8.

Ralf

Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

---

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

---

eGroupWare-users mailing list
eGroupWare-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-users

[Achim_Konigs]

Hi,

glad to get some reaction to this.

Thanks for the patch, I modified it a bit, to not doublicate the code:

http://svn.stylite.de/viewvc/egroupware?revision=39851&view=revision

Please check if it still works for you, then I can backport it to 1.8.

I don’t really understand why, but for me those changes don’t seem to work. I only tried an iCal import with the webinterface, though. If you want I can try to look into a bit more later.

Achim

[Ralf_Becker_Stylite]

Hi Achim,

Hi,

glad to get some reaction to this.

Thanks for the patch, I modified it a bit, to not doublicate the code:

http://svn.stylite.de/viewvc/egroupware?revision=39851&view=revision

Please check if it still works for you, then I can backport it to 1.8.

I don’t really understand why, but for me those changes don’t seem to
work. I only tried an iCal import with the webinterface, though. If you
want I can try to look into a bit more later.

Go ahead

I fixed one problem in r39852, but that should not affect iCal import,
only storing of alarms.

Ralf

Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

---

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

---

eGroupWare-users mailing list
eGroupWare-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-users

[Achim_Konigs]

Hi,

ok, I looked a little bit more into this issue with much trial and error.

I don’t really understand the if that you moved the code into (and that
contains the save_alarm call)… but: If I move my code into that
if-block, it will not work, either and alarms get lost during an
import…? Strange.

But this was not the only issue. If I copied your code out of that if,
it did not work, either…
So I tried to understand some more modifications you did. And it seems
that the renaming of the event fields does not work in the ical.php
file… if I add

$event[‘start’] = $event[‘cal_start’];
$event[‘end’] = $event[‘cal_end’];
$event[‘tzid’] = $event[‘cal_tzid’];

before the call to calendar_so::shift_alarm($event, $alarm);
the import works.

I don’t know php very well, neither do I know much of the egroupware
codebase… So I’m kind of stuck here. But that’s what I observed. As
soon as the code looked like below the alarms did not disappear on imports:

$alarm[‘all’] = false;

$event[‘start’] = $event[‘cal_start’];
$event[‘end’] = $event[‘cal_end’];
$event[‘tzid’] = $event[‘cal_tzid’];
calendar_so::shift_alarm($event, $alarm);

// if no edit rights, allow participants to set alarms directly (like
status)
if ($event_info[‘stored_event’] && !$event_info[‘acl_edit’])
{
$this->save_alarm($event_info[‘stored_event’][‘id’], $alarm);
}

I hope that helps a little bit.
As I said, I don’t really get what the if checks… if I go only for the
comment, that would say, that save_alarm is only called for events that
I don’t have edit rights for… but what about events I have edit rights
for?

Furthermore I don’t really get why “egw_db::strip_array_keys” does not
work in the ical.php. Maybe some scope issue? But shouldn’t it work
inside the shift_alarm method anyway?

Achim