2:12 a.m.
> with the DESCRIPTION set to the
> SUMMARY of the VEVENT.
It's a good suggestion. I find evolution also implement it in this way.
That is a potential gap in SyncEvolution: it doesn't have
"alarm
descriptions" and thus creates/stores slightly invalid iCalendar 2.0
VALARMs without the obligatory DESCRIPTION.
So if 'SUMMARY' is present and 'DESCRIPTION' of 'VALARM' is
absent,
Is it ok to do the assignment?
No alarm. Yongsheng, can you investigate further?
Ok, I'll do it.
Cheers,
Yongsheng
> -----Original Message-----
> From: Ohly, Patrick
> Sent: Friday, April 02, 2010 12:20 AM
> To: Tino Keitel
> Cc: Zhu, Yongsheng; syncevolution(a)syncevolution.org
> Subject: Re: [SyncEvolution] Alarms in the calendar: Evolution vs. vcal
>
> On Thu, 2010-04-01 at 16:18 +0100, Tino Keitel wrote:
> > On Thu, Apr 01, 2010 at 15:57:53 +0800, Zhu, Yongsheng wrote:
> > > Hi, Tino
> > > I can verify your finding. Below bug entry is used to track this issue.
> > > http://bugzilla.moblin.org/show_bug.cgi?id=10458
> > > You could track this issue to find the latest information.
> > > thank you for raising this question.
> >
> > Thanks for caring about this. I think a solution could be to always
> > create an ACTION of type DISPLAY,
>
> That's what we do now. I just merge Yongsheng's patch.
>
> with the DESCRIPTION set to the
> SUMMARY of the VEVENT.
>
That is a potential gap in SyncEvolution: it doesn't have
"alarm
descriptions" and thus creates/stores slightly invalid iCalendar 2.0
VALARMs without the obligatory DESCRIPTION.
>
> I'm not sure whether this really is a problem in practice. Evolution
> doesn't seem to care I assume, otherwise we would expect to have had bug
> reports about it before, which is not the case.
>
> I'm not sure whether the problem is solved entirely with Mobical.net,
> though. In a simple, relative alarm (15 minutes before event), this was
> sent to the server:
>
> BEGIN:VCALENDAR
> VERSION:1.0
> TZ:+01:00
> DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T010000Z;2010103
> 1T010000Z;;freeassociation.sourceforge.net;Tzfile;Europe;Berlin
> BEGIN:VEVENT
> LAST-MODIFIED:20100401T161612Z
> DCREATED:20100401T161612Z
> CLASS:PUBLIC
> SUMMARY:custom alarm
> DESCRIPTION:custom alarm
> DTSTART:20100401T103000Z
> DTEND:20100401T110000Z
> AALARM:-PT15M;;;custom alarm
> DALARM:-PT15M;;;custom alarm
> END:VEVENT
> END:VCALENDAR
>
> This came back:
> BEGIN:VCALENDAR
> VERSION:1.0
> BEGIN:VEVENT
> DTSTART:20100401T103000Z
> DTEND:20100401T110000Z
> SUMMARY:custom alarm
> DESCRIPTION:custom alarm
> LAST-MODIFIED:20100401T161623Z
> END:VEVENT
> END:VCALENDAR
>
No alarm. Yongsheng, can you investigate further?
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>