Updated recurring alarm values are not reflected in the indicator until phone reboot

Okay, after a bit of digging I think what we need to do is remove the "event.setDueDateTime(alarm.date);" line from ubuntu-ui-toolkit's AlarmsAdapter::organizerEventFromAlarmData().

Here's an abbreviated example of a vtodo written to tasks.ics by ubuntu-clock-app --> ubuntu-ui-toolkit --> qtorganizer5-eds:

    BEGIN:VCALENDAR^M
    CALSCALE:GREGORIAN^M
    PRODID:-//Ximian//NONSGML Evolution Calendar//EN^M
    VERSION:2.0^M
    X-EVOLUTION-DATA-REVISION:2014-02-25T04:39:19.361663Z(2)^M
    BEGIN:VTODO^M
    UID:20140225T043915Z-3142-32011-1543-9@ubuntu-phablet^M
    DTSTAMP:20140225T043915Z^M
    DTSTART:20140224T060000^M
    DUE:20140224T060000^M
    RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=DAILY;COUNT=-1^M
    SUMMARY:Alarm^M
    CREATED:20140225T043915Z^M
    END:VTODO^M
    END:VCALENDAR^M

indicator-datetime tries to find calendar events within a certain time window by using e_cal_client_generate_instances(), which doesn't find the above VTODO when searching in the date range [2014-02-24 22:52:33...2014-03-24 22:52:33]

e_cal_util_get_component_occur_times() (in evolution-data-server-3.10.1/calendar/libecale-cal-util.c) has a special rule for VTODO items, looking for the ending range by taking the higher value of "completed" or "due":

    > if (kind == ICAL_VTODO_COMPONENT) {
    > ....
    > e_cal_component_get_completed (comp, &tt);
    > ....
    > e_cal_component_get_due (comp, &dt_due);
    > ....
    > max_time = MAX (completed_time, due_time);

Since "completed" isn't set, EDS returns "due" as the end.

"due" comes from qtorganizer5-eds's qorganizer/qorganizer-eds-engine.cpp's QOrganizerEDSEngine::parseDueDate()'s call to e_cal_component_free_datetime().

That call appears to come from ubuntu-ui-toolkit's modules/Components/plugin/adapters/alarmsadapter_organizer.cpp's AlarmsAdapter::organizerEventFromAlarmData() function calling "event.setDueDateTime(alarm.date);"

If you remove the single line "DUE" from the above VTODO, e_cal_client_generate_instances() is able to find it using the same date range mentioned above.

Alarms fetched in Alarms API are getting their date from the due date, which is the due date of the next occurrence. The question is whether I get a proper date at fetch time if I do not set the due date for the original event. Or is the due date for the individual occurrences set independently from the original event's due date? If yes, we can make the change in UITK Alarms API.

Ahh, sorry, my comments are on the wrong bug :) Let me check if I can get rid of the dueDate() and rely only on startDate()

Status changed to 'Confirmed' because the bug affects multiple users.

Still present in r276.

I'm testing this out on r276 this morning and am getting confusing results. At first I thought it was an indicator-datetime caching bug, because the modified alarms are being successfully saved to tasks.ics.

However, even if I stop and restart indicator-datetime, the new session of indicator-datetime picks up the old values instead of the updated ones seen in tasks.ics. I added in debug statements to check the timestamps, and yes alarms being returned by indicator-datetime's call to e_cal_client_generate_instances() still have the old values.

However, if I kill and restart evolution-calendar-factory, *then* restart indicator-datetime, it picks up the new, modified versions.

The system is behaving like there's a cached version of the alarms in evolution-calendar-factory that's not getting updated after tasks.ics gets written out after qtorganizer5-eds modifies the objects.

Renato, Zsombor, any ideas on this?

Steps I used to test this:

1. ssh'ed into the phablet

2. built lp:~charlesk/indicator-datetime/log-instances-to-terminal, which is stock indicator-datetime plus this console message: http://bazaar.launchpad.net/~charlesk/indicator-datetime/log-instances-to-terminal/revision/337

3. "$ stop indicator-datetime" to kill the system copy of indicator-datetime

4. "$ log-instances-to-terminal/build/src/indicator-datetime-service" to start up the test build to run in its place

What happens:

The times returned by e_cal_client_generate_instances() get dumped to the terminal and match the alarms' old values, instead of the new ones, until I kill evolution-calendar-factory and restart.

@nick90, @charles, could you test my branch?
Looks like the problem is related with the update mode used during the event save.

Renato, yes! lp:~renatofilho/qtorganizer5-eds/fix-1283859 fixes this for the test I described in comments #5 and #6 :D

This bug was fixed in the package qtorganizer5-eds - 0.1.1+14.04.20140415.1-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+14.04.20140415.1-0ubuntu1) trusty; urgency=low

  [ Renato Araujo Oliveira Filho ]
  * Optimize eventid parse, and avoid memory leak. (LP: #1306112)
  * Used alarm component description as message field for visual
    reminders. (LP: #1284375)
  * Implemented support to update recurrence items with different modes.
    All (E_CAL_OBJ_MOD_ALL);. A single instance (E_CAL_OBJ_MOD_THIS),. A
    specific set of instances (E_CAL_OBJ_MOD_THIS_AND_PRIOR and
    E_CAL_OBJ_MOD_THIS_AND_FUTURE) (LP: #1283859)
  * Fixed recurrence date limit parse. (LP: #1292554)
  * Removed all debug messages. (LP: #1294426)
 -- Ubuntu daily release <email address hidden> Tue, 15 Apr 2014 19:43:13 +0000