6.0.0-git
2019-04-24

[#12865] Reminder times synchronization with IOS
Summary Reminder times synchronization with IOS
Queue Kronolith
Queue Version 4.1.3
Type Bug
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org
Requester spam (at) portabile (dot) net
Created 2013-11-26 (1975 days ago)
Due
Updated 2013-11-27 (1974 days ago)
Assigned 2013-11-27 (1974 days ago)
Resolved 2013-11-27 (1974 days ago)
Milestone
Patch No

History
2013-11-27 09:39:40 Jan Schneider Taken from Michael Rubinsky
State ⇒ Resolved
 
2013-11-27 09:39:32 Git Commit Comment #14 Reply to this comment
Changes have been made in Git (master):

commit 9422ef8f18c86220138c07d89738d856f4114da9
Author: Jan Schneider <jan@horde.org>
Date:   Wed Nov 27 10:36:35 2013 +0100

     [jan] Ignore iCalendar alarms without action, and use first, not 
last alarm (Bug #12865).

     Conflicts:
             kronolith/docs/CHANGES
             kronolith/package.xml

  kronolith/docs/CHANGES  |    2 ++
  kronolith/lib/Event.php |    7 +++++++
  kronolith/package.xml   |    2 ++
  3 files changed, 11 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/9422ef8f18c86220138c07d89738d856f4114da9
2013-11-27 09:23:41 Jan Schneider Comment #13 Reply to this comment
iOS sends two alarms with the event. Baikal probably uses the first 
one, which is correct, while Kronolith uses the second one, which is 
completely broken and senseless:

BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Erinnerung
TRIGGER:-PT5M
UID:9AF86893-DC43-4B41-BE3E-45D32D9046C1
X-WR-ALARMUID:9AF86893-DC43-4B41-BE3E-45D32D9046C1
END:VALARM
BEGIN:VALARM
ACTION:NONE
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
END:VALARM

We might want to simply ignore alarms with no action.
2013-11-27 02:29:32 spam (at) portabile (dot) net Comment #12 Reply to this comment
Tested with Baikal server 0.2.6, which is also relying on the
  sabredav framework.
It can handle the IOS default alert at time of the event.


2013-11-27 02:08:10 spam (at) portabile (dot) net Comment #11 Reply to this comment
I can confirm this.
Setting the default alert times to none in IOS makes the bug disappear.
At least there is a workaround.

Thanks again for your efforts!

2013-11-27 02:02:53 Michael Rubinsky Comment #10
Assigned to Jan Schneider
Assigned to Michael Rubinsky
State ⇒ Assigned
Priority ⇒ 1. Low
Reply to this comment
Ok. I can reproduce now. This are the steps:

1) Create an event on the client, while the default alarm setting is 
"At Time of Event". If this is not set, or the alarm is set to a 
different initial value it doesn't trigger the bug.

2) After event syncs, change the alarm on the client to a different 
value, such as "15 minutes" prior.

WIll investigate further, but this sounds like a bug in iOS.
2013-11-27 01:46:16 spam (at) portabile (dot) net Comment #9 Reply to this comment
On OSX 10.9, the OS calendar app does not introduce this bug.
It is just the IOS doing this. However, I can move entries to a later
date on IOS without trouble, for example. It is just the alarm entry.

If I view a OSX 10.9 created calendar entry with just one alarm,
the IOS client shows the correct alarm time as a second alert,
with a default alert at the time of the event.


2013-11-27 01:40:23 spam (at) portabile (dot) net Comment #8 Reply to this comment
Still cannot reproduce. Changing alerts on the iOS device correctly 
changes it on the server.
In the Mysql database I use, I mostly get the value 19804384
for event_alarm in kronolith_events.
Initial event creation from IOS gives the value 0, then on any change
on the client it changes to the 19804384 value.
2013-11-27 01:22:26 Michael Rubinsky Comment #7 Reply to this comment
Still cannot reproduce. Changing alerts on the iOS device correctly 
changes it on the server.
2013-11-27 01:19:48 spam (at) portabile (dot) net Comment #6 Reply to this comment
...and what do you mean that it mixes first and second alerts?
Not directly mixing, but adding when not requested, for example:
All on IOS: Create event with alert at time of event.
Then change alert to 15 minutes before. This creates two alerts,
one with "at time of event", one with "8 days, 15 hours...".
There is, however, other weird behavior related to first and second
alert as well.

If this can not be reproduced, I will have a look at my configuration.

Thanks anyways for the effort!
2013-11-27 00:55:58 Michael Rubinsky Comment #5 Reply to this comment
...and what do you mean that it mixes first and second alerts?
2013-11-27 00:52:02 Michael Rubinsky Comment #4 Reply to this comment
Cannot reproduce on iOS 5, 6, or 7.
2013-11-27 00:05:03 spam (at) portabile (dot) net Comment #3 Reply to this comment
Using which synchronization protocol?
Caldav, sorry.

2013-11-27 00:00:56 Michael Rubinsky Comment #2
State ⇒ Feedback
Reply to this comment
Using which synchronization protocol?
2013-11-26 23:29:27 spam (at) portabile (dot) net Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Reminder times synchronization with IOS
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
IOS 6 and 7 does not synchronize alert times correctly.
If I set an alert time on IOS, it changes to some random huge value 
like 8 days, 15 hours, 2 minutes before the event, and mixes first and 
second alert.
From web interface to IOS seems to work, though.

Saved Queries