451821 - [Google] X-Props are not roundtripped (dismiss or snooze alarms doesn't work)

Status: VERIFIED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Bas van den Bosch]

Caldav on google: it's not possible to dismiss or snooze alarms. 

STR:
1. create an event with default google-alarm (google-bug: only google's default alarm is supported)
2. wait for alarm to fire 
3. try to dismiss
4. window refreshes with alarm 


Log of dismissing an alarm:
CalDAV: Item modified successfully.
CalDAV: Status 207 fetching calendar-data for calendar bas op gmail 
[calAlarmService] considering alarm for item: New Event alarm time: 2008/08/16 05:20:00 UTC isDate=0 snooze time: null
[calAlarmService] now is 2008/08/23 07:05:53 UTC isDate=0
[calAlarmService] last ack was: null
[calAlarmService] alarm is in the past and unack'd, firing now!
refresh completed with status 207 at https://www.google.com/calendar/dav/[e-mail]/events/
etc

Log of snoozing an alarm:
CalDAV: Item modified successfully.
CalDAV: Status 207 fetching calendar-data for calendar bas op gmail 
[calAlarmService] considering alarm for item: New Event alarm time: 2008/08/16 05:20:00 UTC isDate=0 snooze time: null
etc

May be a google-thing?

Comment 1

[Bas van den Bosch]

Further investigation shows that google drops all X-MOX props so when refreshed Lightning thinks it's a fresh alarm. So imho a bug for google.

dismissing sends:
CalDAV: send: BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
X-LIC-LOCATION:Europe/Amsterdam
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20080823T092524Z
LAST-MODIFIED:20080823T093544Z
DTSTAMP:20080823T093544Z
UID:e5d47deb-fb12-4600-bf5e-7573fe745a9d
SUMMARY:New Event
STATUS:CONFIRMED
CLASS:PRIVATE
X-MOZ-LASTACK:20080823T093544Z
DTSTART;TZID=Europe/Amsterdam:20080820T061500
DTEND;TZID=Europe/Amsterdam:20080820T073000
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for LOCATION 
 property. Removing entire property:
SEQUENCE:0
TRANSP:OPAQUE
X-MOZ-SNOOZE-TIME:20080823T094044Z
X-MOZ-GENERATION:1
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT10M
DESCRIPTION:Mozilla Alarm: New Event
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

and google returns:
CalDAV: recv: <?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/calendar/dav/bvdbos%40gmail.com/events/e5d47deb-fb12-4600-bf5e-7573fe745a9d.ics</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <D:getetag>164017-63355167336</D:getetag>
        <C:calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
X-WR-CALNAME:Bas van den Bosch
X-WR-TIMEZONE:America/New_York
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
X-LIC-LOCATION:Europe/Amsterdam
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Amsterdam:20080820T061500
DTEND;TZID=Europe/Amsterdam:20080820T073000
DTSTAMP:20080823T093536Z
UID:e5d47deb-fb12-4600-bf5e-7573fe745a9d
CLASS:PRIVATE
CREATED:20080823T092524Z
DESCRIPTION:
LAST-MODIFIED:20080823T093536Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:New Event
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H10M0S
END:VALARM
END:VEVENT
END:VCALENDAR</C:calendar-data>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

See also the corresponding Google issue at http://code.google.com/p/google-caldav-issues/issues/detail?id=25

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The obvious workaround is to not show alarms for Google. I'm not going to add specialcasing for this since Google's support is still at the beginning and the workaround is easy.

The "solution" for this bug in general is to provide a way to overlay events with local data, i.e if the server cannot write specific things then a local cache can save that data. Ideally this (stripped!) data should be exportable as ics, so that you can save extra data about readonly calendars on a webdav share of your choice, allowing even to sync alarm snooze times between computers.

The above ideas are in some other bug I cannot find right now.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Issue 25 was fixed, marking this bug as fixed too.

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I verified this bug with the just checked out version, seems to work now.

Comment 6

[Peter Lairo]

The problem has re-appeared. Re-open?

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

No, lets leave it to them. The only thing we can do on our side is to implement local alarms, which is being done in another bug.

Comment 8

[Peter Lairo]

I don't know the other bug number, so I'll ask here (sorry for the OT post):

Will local alarms have other benefits other than being a workaround for a bug(!) that a CalDAV provider has? The reason I ask is that it might introduce more complexity (also for the user) for something that might only be a temporary (and hopefully never-to-return) problem.

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Its bug 861594. I agree this needs good UI, but this will make things smoother especially for users that don't care about sharing alarms, or maybe for shared calendars where it is explicitly not wanted to save dismiss info on the calendar.