Relationship Graph

Relationship Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

IDProjectCategoryView StatusLast Update
0002895SOGoBackend Calendarpublic2022-01-27 14:54
ReporterMarcel Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
OSiOS Calendar.app or MacOSX iCal 
Target Version2.3.7 
Summary0002895: Calendars without showCalendarAlarms have alarms added by Apple clients
Description

When a default alarm is set in Apple's CalDAV clients, they add the default alarm to any event that does not already have an alarm. It is debatable whether this is a good thing, but we have to live with it.

Unfortunately, it makes the function to hide calendar alarms in SOGo completely useless, as all these entries get alarms added locally by the respective clients. This is especially annoying when having access to delegations or resources.

Disabling default alarms in iCal makes it very inconvenient if you want manually entered entries to have an alarm.

Steps To Reproduce
  1. Have default alarms set on your iOS/MacOSX Calendar app
  2. Create a new calendar with showCalendarAlarms off
  3. Add events to this calendar (with or without alarms)
  4. Look at the entries on iOS/MacOSX; they have alarms set (which will fire on this device)
Additional Information

This can be easily achieved by adding the following to every event which have their alarms stripped (with fresh GUIDs, of course):

BEGIN:VALARM
X-WR-ALARMUID:0B7DF392-2791-430C-AB67-861F1A736E17
UID:0B7DF392-2791-430C-AB67-861F1A736E17
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
X-APPLE-LOCAL-DEFAULT-ALARM:TRUE
ACTION:NONE
X-APPLE-DEFAULT-ALARM:TRUE
END:VALARM

A good place to do this seems SOGoCalendarComponent.m's - _secureContentWithoutAlarms after [currentComponent removeAllAlarms].

As I don't know whether some non-Apple devices will fire an alarm anyway (implied by http://tools.ietf.org/html/draft-daboo-valarm-extensions-04), it might be good to add

ACKNOWLEDGED: 19760401T005545Z

to the VALARM or export this only to Apple devices.

TagsNo tags attached.

Relationships

related to 0002896 new Provide an option whether Apple devices should add default alarms 

Activities

ludovic

ludovic

2014-09-12 18:27

administrator   ~0007501

I still don't understand what is the purpose of that dummy entry.

Its trigger is bogus, and its action is none.

Marcel

Marcel

2014-09-14 08:40

reporter   ~0007504

Last edited: 2014-09-14 08:51

Yes, I agree it's weird. Let me first summarize draft-daboo-valarm-extensions, which gives insight into Apple's line of thinking, and then provide some interpretation:

  • SUMMARY

In https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-11, Cyrus Daboo (Apple) provides an explanation:

  1. Default Alarms in CalDAV

    Users often want to have a default alarm applied to new events that
    they create or to new invitations that arrive on a CalDAV [RFC4791]
    server. Since this behavior is expected to occur no matter which
    client a user is using, or whether any client is even connected at
    the time, it is beneficial if the server itself is responsible for
    managing the creation of the default alarm.

ACTION:NONE as a placeholder for "User does not want a default alarm" is described in Section 11.3 (https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-11.3).

The last paragraph before Section 10.1 (https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-10.1) explains the use of the dummy 19760401T005545Z DATETIME for backward compatibility (although for a different use case).

  • INTERPRETATION

Current servers do not provide support for the default alarm properties (and are unlikely to do ever, since the I-D has not been updated in over two years). Apple tries to approximate this client-side, with a similar behavior as explained in the rest of Section 11 in the above I-D.

Therefore, each Apple client checks to see whether any alarm is set at all; if none is set, and it has a default alarm, it adds its default alarms. This creates two usability problems:

  1. With multiple devices and shared calendars, finding the culprit which added an alarm to an event can be very hard. (Only a few days ago I changed a repeating event in one of the calendars and now they all happily alarm again, even if they should not)

  2. Disabling default alarms on all devices also has the disadvantage that for the 90%+ of events that I want to have alarms (and typically two), the UI on MacOSX iCal now requires what feels like 20 mouse movements, delays, and clicks to add these two alarms.

The dummy entry (expired alarm with no action) prevents the clients from doing this automatic addition. In fact, any entry would do, but this one is defined to do nothing and is the one that the other clients would insert themselves.

Marcel

Marcel

2014-09-14 09:32

reporter   ~0007505

Last edited: 2022-01-27 14:54

BTW: As part of the initial PROPFIND on /SOGo/dav/user/Calendar/ iCal (MacOSX) asks for the properties at the end of this note. This – interestingly – includes default-alarm-vevent-date and default-alarm-vevent-datetime.

Apple's CalendarServer also seems to implement this property (look for default-alarm in https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-5.2/twistedcaldav/caldavxml.py and DefaultAlarm in https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-5.2/twistedcaldav/resource.py), which does allow the clients to synchronize their default alarm settings (which would be helpful in itself to have a consistent view).

I did not find code where the server modifies calendar entries, so these four properties could be implemented as transparent properties for client-to-client exchange with minimal impact as well.

<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
  <A:prop>
    <A:add-member/>
    <C:allowed-sharing-modes xmlns:C="http://calendarserver.org/ns/"/>
    <D:autoprovisioned xmlns:D="http://apple.com/ns/ical/"/>
    <E:bulk-requests xmlns:E="http://me.com/_namespace/"/>
    <D:calendar-color xmlns:D="http://apple.com/ns/ical/"/>
    <B:calendar-description xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:calendar-free-busy-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <D:calendar-order xmlns:D="http://apple.com/ns/ical/"/>
    <B:calendar-timezone xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:current-user-privilege-set/>
    <B:default-alarm-vevent-date xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:default-alarm-vevent-datetime xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:displayname/>
    <C:getctag xmlns:C="http://calendarserver.org/ns/"/>
    <D:language-code xmlns:D="http://apple.com/ns/ical/"/>
    <D:location-code xmlns:D="http://apple.com/ns/ical/"/>
    <A:owner/>
    <C:pre-publish-url xmlns:C="http://calendarserver.org/ns/"/>
    <C:publish-url xmlns:C="http://calendarserver.org/ns/"/>
    <C:push-transports xmlns:C="http://calendarserver.org/ns/"/>
    <C:pushkey xmlns:C="http://calendarserver.org/ns/"/>
    <A:quota-available-bytes/>
    <A:quota-used-bytes/>
    <D:refreshrate xmlns:D="http://apple.com/ns/ical/"/>
    <A:resource-id/>
    <A:resourcetype/>
    <B:schedule-calendar-transp xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:schedule-default-calendar-URL xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <C:source xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-alarms xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-attachments xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-todos xmlns:C="http://calendarserver.org/ns/"/>
    <B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:supported-report-set/>
    <A:sync-token/>
  </A:prop>
</A:propfind>

Issue History

Date Modified Username Field Change
2014-08-14 11:46 Marcel New Issue
2014-08-15 12:27 Christian Mack Relationship added related to 0002896
2014-09-12 15:19 ludovic Target Version => 2.2.9
2014-09-12 18:27 ludovic Note Added: 0007501
2014-09-14 08:40 Marcel Note Added: 0007504
2014-09-14 08:40 Marcel Note Edited: 0007504
2014-09-14 08:51 Marcel Note Edited: 0007504
2014-09-14 09:32 Marcel Note Added: 0007505
2014-09-26 13:37 ludovic Target Version 2.2.9 => 2.2.10
2014-11-07 20:41 ludovic Target Version 2.2.10 => 2.2.11
2014-12-04 19:30 ludovic Target Version 2.2.11 => 2.2.12
2014-12-18 14:38 ludovic Target Version 2.2.12 => 2.2.13
2014-12-30 15:28 ludovic Target Version 2.2.13 => 2.2.14
2015-01-20 16:23 ludovic Target Version 2.2.14 => 2.2.15
2015-01-30 18:10 ludovic Target Version 2.2.15 => 2.2.16
2015-02-12 16:15 ludovic Target Version 2.2.16 => 2.2.17
2015-03-24 18:25 francis Target Version 2.2.17 => 2.3.0
2015-05-12 19:51 ludovic Target Version 2.3.0 => 2.3.1
2015-07-23 17:44 ludovic Target Version 2.3.1 => 2.3.2
2015-09-16 19:20 ludovic Target Version 2.3.2 => 2.3.3
2015-11-11 14:23 ludovic Target Version 2.3.3 => 2.3.4
2015-12-16 16:08 ludovic Target Version 2.3.4 => 2.3.5
2016-01-07 14:56 ludovic Target Version 2.3.5 => 2.3.6
2016-01-18 18:20 ludovic Target Version 2.3.6 => 2.3.7
2022-01-27 14:52 francis Additional Information Updated
2022-01-27 14:54 francis Note Edited: 0007505