Das Modul repräsentiert einen einzelnen Online-Kalender.
Kalender-Instanzen nicht manuell anlegen oder lediglich über „Gateway ändern“ mit einem Konto verbinden. Sie sollen über den zum Konto gehörenden Kalender Konfigurator erstellt werden. Nur der Konfigurator trägt den tatsächlichen Kalendernamen, die interne Identität, die Farbe, die Schreibrechte und die korrekte Kontoverbindung vollständig ein. Das ist besonders bei Konten mit mehreren Kalendern erforderlich.
Nach der Erstellung durch den Konfigurator darf die Instanz im Objektbaum beliebig verschoben oder vom Benutzer umbenannt werden.
Das Ändern oder einzelne Löschen von Vorkommen einer Terminserie ist noch nicht freigegeben. Dadurch verhindert das Modul, dass eine komplette Serie versehentlich überschrieben oder gelöscht wird.
| Eigenschaft | Beschreibung |
|---|---|
| Aktiv | Aktiviert die regelmäßige Synchronisation |
| Aktualisierungsplan | Vorgegebener Rhythmus von fünf Minuten bis jährlich oder ausschließlich manuelle Synchronisation |
| Benutzerdefiniertes Intervall | Eigener Abstand in Minuten; wird nur beim Zeitplan „Benutzerdefiniertes Intervall“ angezeigt |
| Vergangene Termine laden | Anzahl der Tage vor dem aktuellen Datum |
| Zukünftige Termine laden | Anzahl der Tage nach dem aktuellen Datum |
| Kalenderidentität | Vom Konfigurator gesetzte, schreibgeschützte Anbieterinformationen |
Bestehende Instanzen behalten ihren bisherigen Minutenwert als benutzerdefiniertes Intervall. Monatliche und jährliche Zeitpläne werden intern täglich auf Fälligkeit geprüft, damit keine für lange Zeiträume ungeeigneten Millisekunden-Timer verwendet werden. Jetzt synchronisieren bleibt unabhängig vom Zeitplan jederzeit verfügbar.
| Variable | Typ | Beschreibung |
|---|---|---|
| Anzahl Termine | Integer | Anzahl der aktuell zwischengespeicherten Termine |
| Letzte Synchronisation | Integer | Unix-Zeitpunkt der letzten erfolgreichen Abfrage |
Die eigentlichen Termindaten werden bewusst nicht in einer Statusvariable gespiegelt, sondern nur im internen Modulcache gehalten. Sie werden über IPSKAL_GetEvents() abgerufen. Dadurch werden große JSON-Datenmengen nicht bei jeder Synchronisation als Variablenwert durch Symcon verteilt.
Ein Termin enthält unter anderem id, uid, resourceUrl, etag, summary, description, location, start, end, startTimestamp, endTimestamp, allDay, status, recurrenceRule und recurrenceId. Wurde der Titel durch ein ausgewähltes iCalendar-Übersetzungsprofil angepasst, enthält originalSummary zusätzlich den unveränderten Originaltitel.
bool IPSKAL_Synchronize(int $InstanzID);
string IPSKAL_GetEvents(int $InstanzID);
string IPSKAL_CreateEvent(int $InstanzID, string $EventJSON);
string IPSKAL_UpdateEvent(int $InstanzID, string $EventJSON);
bool IPSKAL_DeleteEvent(int $InstanzID, string $EventJSON);
string IPSKAL_GetCalendarStatus(int $InstanzID);
void IPSKAL_ClearCache(int $InstanzID);
$result = IPSKAL_CreateEvent(12345, json_encode([
'summary' => 'Besprechung',
'description' => 'Projektstatus abstimmen',
'location' => 'Büro',
'start' => '2026-07-20T10:00:00+02:00',
'end' => '2026-07-20T11:00:00+02:00'
]));
Bei ganztägigen Terminen werden start und end als Datum angegeben. Das Ende ist entsprechend iCalendar exklusiv:
$result = IPSKAL_CreateEvent(12345, json_encode([
'summary' => 'Urlaub',
'start' => '2026-08-03',
'end' => '2026-08-08',
'allDay' => true
]));
uid, resourceUrl und etag stammen aus IPSKAL_GetEvents. Unter changes werden nur die zu ändernden Felder übergeben:
$result = IPSKAL_UpdateEvent(12345, json_encode([
'uid' => 'event-uid@example',
'resourceUrl' => 'https://server.example/calendar/event.ics',
'etag' => '"123456"',
'changes' => [
'summary' => 'Geänderte Besprechung',
'location' => 'Konferenzraum'
]
]));
$success = IPSKAL_DeleteEvent(12345, json_encode([
'resourceUrl' => 'https://server.example/calendar/event.ics',
'etag' => '"123456"'
]));
Nach jeder erfolgreichen Schreiboperation wird der lokale Termincache erneut vom Server geladen.