#869: SeriesModificationMode.kt

projectforge-business/src/main/kotlin/org/projectforge/business/calendar/event/model/SeriesModificationMode.kt Type: Kotlin enum class
Purpose: Specifies which events in a recurring series are affected by a modification
Source path: projectforge-business/src/main/kotlin/org/projectforge/business/calendar/event/model/SeriesModificationMode.kt 30 lines · 2 code · 26 comments · 2 blank

SeriesModificationMode is a simple three-valued enum that controls the scope of changes when a user edits an event that belongs to a recurring series. This pattern is common in calendar UIs (Google Calendar, Outlook, etc.) and governs whether the edit applies to a single occurrence, all occurrences, or this and all future occurrences.

Enum Values

ValueDescription
ALL Modification applies to every event in the series — past, present, and future. This is the broadest scope of change.
FUTURE Modification applies to the selected event and all subsequent occurrences. Past occurrences of the series are left unchanged. This typically creates a split point in the series.
SINGLE Modification applies only to the specific occurrence being edited. Other occurrences in the series are unaffected. This creates an exception record in the series data model.

Usage Context

This enum is part of the event.model package alongside ICalendarEvent and is used when processing edit/save operations on recurring calendar events. The frontend likely presents a dialog asking "Edit this event? / Edit all events in the series? / Edit this and all following events?" with the corresponding enum value submitted to the backend.

Git History

Design Rationale

A dedicated enum for series modification scope (rather than a boolean flag or an integer code) provides type safety and self-documentation. The three values mirror the standard calendar UX pattern (single / all future / all), which users already understand from other calendar applications. By placing it in the event.model package alongside ICalendarEvent, the enum is co-located with the event contract, making it obvious to developers that this governs event editing behavior for the event model layer.