Zeitpläne für Access Policies
Auf dieser Seite
Die Zeit ist der Teil When jeder Access Policy. Wählen Sie Anytime oder Scheduled; eine geplante Policy enthält ein oder mehrere Fenster vom Typ Weekly oder One-time. Informationen zur Seite Settings → Access Time Windows finden Sie unter Kulanzzeiten und Zeitzone.
Eine Policy gewährt nur dann Zugriff, wenn Who UND Where UND When zutreffen. Die Fenster innerhalb einer Policy sind mit ODER verknüpft, und benannte Policies ebenfalls. Policies sind ausschließlich erlaubend: Eine inaktive Policy entzieht keinen Zugriff, der durch eine andere zutreffende Policy, eine dauerhafte Berechtigung oder ein separates Fenster eines Administrators oder einer Integration gewährt wird.
Jederzeit
Anytime bedeutet, dass Who und Where der Policy ohne zeitliche Einschränkung zutreffen können. Prüfungen zu Sicherheit, Wartung, Geofence, Sperren, Ratenbegrenzung und Geräten werden dadurch nicht umgangen.
Weekly-Fenster
Ein Weekly-Fenster wiederholt sich anhand von Blöcken in lokaler Uhrzeit, etwa Montag 06:00–08:30.
- Die ausgewählte IANA-Zeitzone bestimmt Wochentag, Ortszeit und das Verhalten bei der Sommerzeitumstellung.
- Optionale Zeitpunkte für Beginn und Ende der Gültigkeit können die Wiederholung begrenzen; das Ende ist exklusiv.
- Blöcke dürfen sich nicht überschneiden und nicht über Mitternacht reichen. Teilen Sie einen Zeitraum über Nacht auf zwei Tage auf.
- Bei der Umstellung auf Sommerzeit treten übersprungene Ortszeiten nicht auf. Bei der Umstellung auf Winterzeit gelten beide realen Zeitpunkte, die einer wiederholten Ortszeit entsprechen.
One-time-Fenster
Ein One-time-Fenster hat genau einen Start- und einen Endzeitpunkt. Verwenden Sie es für einen bekannten, einmaligen Zeitraum.
- Beginn und Ende sind ganzzahlige Unix-Sekunden, die UTC-Zeitpunkte bezeichnen.
- Die Grenze ist halboffen:
[from, to). Der Beginn zählt dazu, das Ende nicht. - Die angezeigte Zeitzone dient der Eingabe, der Anzeige und dem Prüfkontext. Sie ändert keinen gespeicherten Zeitpunkt.
Separate Benutzer- und Integrationsfenster
Benutzerfenster, die Administratoren gehören, und von Integrationen bereitgestellte Fenster bleiben separate, zusätzliche Wege; sie werden nicht in Access Policies umgewandelt und können nicht durch Bearbeiten einer Policy entfernt werden. Sie können gemäß ihrem eigenen Vertrag die Einrichtung, Türen oder Zugriffsbereiche als Ziel haben.
Integrationsfenster behalten ihr Verhalten hinsichtlich Quellzugehörigkeit, Revision, Aktualität und Zuordnung von scope_key bei. Unbekannte, deaktivierte, nicht zugeordnete, veraltete oder entkoppelte Quellfenster gewähren keinen Zugriff. Eine Quelle kann die Fenster einer anderen Quelle nicht löschen, und weder Aktualisierungen einer Quelle noch Änderungen an Policies löschen Fenster, die Administratoren gehören.
Dauerhafte Berechtigungen sind ein weiterer separater, zusätzlicher Weg. Ihre bestehenden optionalen Betriebszeiten bleiben unabhängig von den Zeitplänen der Policies.
Kulanzzeiten und Zeitzone
Abbildung 1: Settings → Access Time Windows → Access grace periods
Settings → Access Time Windows → Access grace periods legt fest, wie viel Spielraum Personen rund um ihre geplanten Fenster erhalten. „Scheduled start and end times remain unchanged. These buffers only expand when door access is allowed.“
- Zeitzone der Einrichtung – die Zeitzone, die Weekly-Fenster verwenden; Sommerzeitumstellungen werden automatisch berücksichtigt. Um sie zu ändern, verwenden Sie Zeitzone in der Einrichtungs- und Systemkonfiguration ändern; siehe Zeitzone.
- Allow early access – „Allow users to unlock doors shortly before their scheduled window starts.“ Off, 5 minutes, 10 minutes, 15 minutes oder 30 minutes.
- Allow access after end – „Keep door access available briefly after the scheduled window ends.“ Off, 5 minutes, 10 minutes, 15 minutes oder 30 minutes.
Die Kulanzzeiten gelten für alle One-time- und Weekly-Fenster an der Einrichtung, einschließlich der Fenster, die von Buchungsintegrationen bereitgestellt werden. Sie zählen auch für No visit recorded: Eine Person, die während der Kulanzzeit entsperrt, gilt als erschienen. Ein Hotel kann zum Beispiel Allow access after end auf 15 Minuten setzen, um späte Check-outs bei Gästepässen abzudecken.
Bestehende Zeitpläne
Bestehende Betriebszeiten werden automatisch in den Abschnitt When der entsprechenden Access Policies importiert. Abweichende Zeiten, die bisher für bestimmte Bereiche oder Türen galten, bleiben in Policies mit expliziten Zielen unter Where erhalten. Administratoren müssen Zeitpläne nicht manuell umwandeln.
Autorisierung und Verfügbarkeit
Beim Zugang für Mitglieder werden zuerst die Sicherheitsprüfungen für Benutzer und Tür ausgeführt. Anschließend wertet der Server die Erlaubniswege über Policies, dauerhafte Berechtigungen, Administratorfenster und Integrationsfenster aus. Geofence- und Controllerprüfungen bleiben nachgelagerte, maßgebliche Kontrollen.
Ein künftiges Policy-Fenster kann strukturierte Verfügbarkeitsangaben mit seinem nächsten konkreten Beginn und Ende, seiner Art, seiner Bezeichnung und seiner Zeitzone zurückgeben. Unterstützte Clients verwenden diese Daten zur Anzeige; sie berechnen die Autorisierung nicht lokal. Die genauen Grenzen bleiben [from, to).
Die detaillierte Ablehnung für ein künftiges Fenster ist outside_access_time_window. Kompatibilitäts-Clients können weiterhin den bisherigen Grund outside_access_hours mit deniedReasonDetail: outside_access_time_window erhalten.
Zuordnung
Eine Policy-Entscheidung nennt die zutreffende Policy mit Namen. Bei geplantem Zugriff können die Zugriffsprotokolle zusätzlich das aktive Fenster und seinen konkreten Beginn und sein konkretes Ende anzeigen, sodass klar ist, welcher Eintrag unter When den Zugriff gewährt hat.