Page Comparison

...

class Study {
  List<CustomEvent> customEvents;
  List<AutoCustomEvent> automaticCustomEvents;
}

Custom events and automatic custom events will function identically to their App model counter-parts. For study-scoped events, but they will be configured with some additional information, through some model collections (objects will be in separate tablesreferenced for validation rather than the app-scoped custom events and automatic custom events (which are being replaced with study bursts, see below):

/**
 * This is the same event as in the App map, but with a display label.
 */
class CustomEvent {
  String identifier;
  ActivityEventUpdateType updateType;
}

/**
 * Almost identical to automatic custom events in the App, but with a label
 * and a means of finding all the automatic custom events that are generated
 * from a study burst configuration.
 */
class AutomaticCustomEvent

Schedules will take a new array of StudyBurst objects which will be used to validate submitted events and to trigger schedules:

class Schedule2 {
  StringList<StudyBurst> identifierstudyBursts;
}

String// studyBurstPrefix;Session is augmented Stringto originEventId;reference one or Periodmore offset;study // positive or negative
}

The new configuration is the StudyBurst, which must go into the Schedule2 object. which describes how to generate a set of automatic custom events:

class Schedule2bursts
class Session {
  List<StudyBurst>List<String> studyBurstsstudyBurstIds;
}

class StudyBurst {
  String prefixidentifier;
  String originEventId;
  String int occurrences;
  Period interval; // positive or negative
}

On study create and update, the server will remove all automatic custom events with a study burst prefix, then iterate through the study burst configurations and create the automatic custom events specified by that configuration. NOTE: this will eventually involve doing this for all schedules in a study every time one schedule is saved, which is a bit of a drag. I’ll continue thinking about thisWhen an event is published (this can be a custom event or a compound system event, like the time a session is finished), and it matches a study burst originEventId, then a sequence of events will be published based on the StudyBurst configuration. The event ID will be in the format burst:<studyBurstIdentifier>:# where the # is the occurrence number of the new event (1-based). The value will be the timestamp of the event + (the interval specified by the study burst * the occurrence number). All these events are published up-front because they are mutable. If the internal publication of these events finds that the event is already in the user’s event map, then it will not be regenerated.

(Note that a lot of this might be configurable.)

When a study is converted to a Timeline, each session that has one or more study bursts will determine the event identifiers of the study burst (which does not require calculation of a time), and all these event IDs will be added to the session’s startEventIds before the session is then converted into scheduled sessions that encode one starting event each.

For example, a study burst named “foo” triggered from “enrollment” four times, at an interval of P1W, would (in the old notation) generate the automatic custom events “foo1 → enrollment:P1W”, “foo2 → enrollment:P2W”, “foo3 → enrollment:P3W”, “foo4 → enrollment:P4W”.

...