Plannings des Access Policies
Sur cette page
Le temps constitue la partie When de chaque Access Policy. Choisissez Anytime ou Scheduled ; une politique planifiée contient un ou plusieurs créneaux Weekly ou One-time. Pour la page Settings → Access Time Windows, voir Périodes de grâce et fuseau horaire.
Une politique n'accorde l'accès que lorsque Who ET Where ET When correspondent. Les créneaux d'une même politique sont combinés par un OU logique, de même que les politiques nommées. Les politiques ne font qu'autoriser : une politique inactive ne révoque pas l'accès accordé par une autre politique correspondante, par une autorisation permanente ou par un créneau d'administrateur ou d'intégration distinct.
À tout moment
Anytime signifie que les critères Who et Where de la politique peuvent correspondre sans restriction horaire. Cela ne contourne pas les contrôles de sécurité, de maintenance, de geofence, de blocage, de limitation du débit ou d'appareil.
Créneaux Weekly
Un créneau Weekly se répète à l'aide de plages exprimées en heure locale, comme le lundi de 06:00 à 08:30.
- Le fuseau horaire IANA sélectionné détermine le jour de la semaine, l'heure locale et le comportement lors des changements d'heure.
- Des instants facultatifs de début et de fin d'activité peuvent délimiter la récurrence ; la fin est exclue.
- Les plages ne peuvent ni se chevaucher ni franchir minuit. Répartissez une période de nuit sur deux jours.
- Lors du passage à l'heure d'été, les heures locales sautées n'existent pas. Lors du retour à l'heure d'hiver, les deux instants réels correspondant à une heure locale répétée sont pris en compte.
Créneaux One-time
Un créneau One-time a un instant de début et un instant de fin exacts. Utilisez-le pour une période ponctuelle connue.
- Le début et la fin sont des secondes Unix entières identifiant des instants UTC.
- L'intervalle est semi-ouvert :
[from, to). Le début est inclus ; la fin ne l'est pas. - Le fuseau horaire affiché sert à la saisie, à l'affichage et au contexte d'audit. Il ne modifie pas un instant enregistré.
Créneaux distincts d'utilisateur et d'intégration
Les créneaux d'utilisateur créés par un administrateur et les créneaux fournis par une intégration restent des voies cumulatives distinctes ; ils ne sont pas convertis en Access Policies et ne peuvent pas être supprimés en modifiant une politique. Ils peuvent cibler l'installation, des portes ou des Portées d'accès, selon leur propre contrat.
Les créneaux d'intégration conservent leur comportement en matière de propriété de la source, de révision, de fraîcheur et de mappage scope_key. Les créneaux de source inconnus, désactivés, non mappés, obsolètes ou découplés n'accordent pas d'accès. Une source ne peut pas effacer les créneaux d'une autre source, et ni les mises à jour de source ni les modifications de politique n'effacent les créneaux créés par un administrateur.
Les autorisations permanentes constituent une autre voie cumulative distincte. Leurs heures de fonctionnement facultatives existantes restent indépendantes des plannings des politiques.
Périodes de grâce et fuseau horaire
Figure 1 : Settings → Access Time Windows → Access grace periods
Settings → Access Time Windows → Access grace periods définit la marge de tolérance accordée aux personnes autour de leurs créneaux planifiés. « Scheduled start and end times remain unchanged. These buffers only expand when door access is allowed. »
- Facility timezone — le fuseau horaire utilisé par les créneaux Weekly, qui suit automatiquement les changements d'heure. Utilisez Change timezone in Facility & System Configuration pour le modifier ; voir Fuseau horaire.
- Allow early access — « Allow users to unlock doors shortly before their scheduled window starts. » Off, 5 minutes, 10 minutes, 15 minutes ou 30 minutes.
- Allow access after end — « Keep door access available briefly after the scheduled window ends. » Off, 5 minutes, 10 minutes, 15 minutes ou 30 minutes.
Les périodes de grâce s'appliquent à tous les créneaux One-time et Weekly de l'installation, y compris les créneaux fournis par les intégrations de réservation. Elles comptent également pour No visit recorded : une personne qui déverrouille une porte pendant la période de grâce est considérée comme étant venue. Par exemple, un hôtel peut régler Allow access after end sur 15 minutes pour couvrir les départs tardifs avec les pass clients.
Plannings existants
Les heures d'ouverture existantes sont importées automatiquement dans la section When des Access Policies correspondantes. Les horaires différents qui s'appliquaient auparavant à certaines portées ou portes sont conservés dans des politiques avec des cibles Where explicites. Les administrateurs n'ont pas besoin de convertir les plannings manuellement.
Autorisation et disponibilité
Pour l'accès des membres, les contrôles de sécurité de l'utilisateur et de la porte sont exécutés en premier. Le serveur évalue ensuite les voies d'autorisation par politique, par autorisation permanente, par créneau d'administrateur et par créneau d'intégration. Les contrôles de geofence et du contrôleur restent des étapes décisives ultérieures.
Un créneau de politique futur peut renvoyer une disponibilité structurée avec ses prochains début et fin concrets, son type, son libellé et son fuseau horaire. Les clients pris en charge utilisent ces données pour l'affichage ; ils ne calculent pas l'autorisation localement. Les limites exactes restent [from, to).
Le refus détaillé lié à un créneau futur est outside_access_time_window. Les clients de compatibilité peuvent continuer à recevoir le motif existant outside_access_hours avec deniedReasonDetail: outside_access_time_window.
Attribution
Une décision de politique identifie la politique correspondante par son nom. Pour un accès planifié, les Journaux d'accès peuvent également afficher le créneau actif ainsi que ses début et fin concrets, ce qui permet de savoir clairement quelle entrée When a accordé l'accès.