Zulu - Recurrence

From 360Works Product Documentation Wiki
Jump to navigation Jump to search
Recurring events are partially supported with Apple Calendar integrations, and fully supported with Google and Exchange configurations. Recurring events are difficult to manage without a calendar interface, and Zulu uses the RRULE and EXDATE properties from the CalDAV specification to accomplish this. You can see more examples of RRULE here: 3.8.5.3. Recurrence Rule
Again, Recurring events are very tricky to deal with, and should probably be managed in the calendar application you are integrating with. This page is meant as a guide for those who want to better understand how recurring events work and want to manage them from FileMaker.

Recurring Event Components

RRULE

  • The RRULE defines how the recurring event should iterate, and is best documented in the original spec, shown here: Recurrence Rule
  • You can see more examples of RRULE here: 3.8.5.3. Recurrence Rule
  • In FileMaker, the RRULE is stored in the parent event in the recurrence field.

EXDATE

  • EXDATEs are children of a recurring series that have been deleted.
  • These manifest as EXDATEs in the ICAL_DATA field for Apple Calendar, and the "exdates" property for Google and Exchange
  • EXDATEs are a date-time property for standard events with times, and a date only property for all-day events.
  • You can read more about EXDATE documentation here: Exception Dates
  • EXDATEs are stored in the parent record in the recurrence field.

Overrides

  • Overrides are children of a recurring series that have been modified. They are still part of the series, but they do not obey the RRULE as some property has been modified.
  • These are the most complicated thing to deal with in recurring events.
  • In FileMaker, these will be represented as a new record for the event, but they will have a recurrence-id that links them back to the parent in some way.
  • In most cases, it will be easier to write an EXDATE to the parent event to delete the event you want to override, then create a new event that represents the override.

Recurrence in Apple Calendar

Zulu has partial support for recurring events in Apple Calendar. These are the abilities and limitations:

  • If you create a recurring event in Apple Calendar, you will see the RRULE show up in the iCAL_DATA field in FileMaker.
  • You can delete occurrences from Apple Calendar, and you will see EXDATEs show up in the ICAL data
  • However, if you try to modify an occurrence, the event will revert back to the series definition. Overriden events are not allowed in Apple Calendar integrations.

ZuluRecurrenceICAL.png

Recurrence in Google and Exchange

Google and Exchange have almost identical implementations when handling recurring events.

Consider the following:

  • A recurring event is created in Google with the rule that it should recur daily, ending after 4 times

ZuluGoogleRecurringEvent.png


  • We can see in the recurrence field the RRULE is: RRULE:FREQ=DAILY;COUNT=4
  • Now if an event is deleted in the series we see an EXDATE show up:

ZuluGoogleRecurrenceEXDATE.png


  • This is all well, but what happens if we modify a child? Changing its start time, end time, and summary:

ZuluGoogleRecurrenceOVERRIDE.png


  • As you can see, there is now an "Override" added to the parent. This "override" value contains the recurrence id of the child that was overridden. If we search on the recurrence id field for that value, we find the modified child:

ZuluGoogleRecurrenceOverridenChild.png



  • In order to capture overridden children properly, a new event record is necessary. As any piece of information changed will constitute an override. In addition to capturing changing values, by using a new record we can take advantage of Zulu's time zone conversion processes for these child events.