Aller au contenu
SuperScheduler
SuperScheduler

Qui planifie avec

Thème de couleur
Essayer une démo

Salles et équipements partagés

Réserver salles, laboratoires et équipements partagés

Les ressources partagées sont planifiées par de nombreuses personnes qui ne s’intéressent chacune qu’à une petite partie du calendrier : un formateur qui cherche une salle de vingt places, un chercheur qui a besoin d’un instrument pendant six heures. Le planning doit les aider à trouver ce qui convient et les empêcher de prendre plus que ce que les règles autorisent.

Beaucoup de demandeurs, des règles communes

Contrairement à un agenda de clinique ou à un tableau de dispatch, il y a rarement un planificateur unique. Les réservations viennent de formateurs, d’équipes projet et de chercheurs à titre individuel, chacun avec ses priorités. Le responsable des installations fixe les règles : qui peut réserver quelle ressource, pour combien de temps, combien de temps à l’avance, et ce qui doit se passer entre deux réservations.

Les ressources diffèrent d’une manière qu’un nom ne montre pas. Les salles ont une capacité, une disposition et un équipement, et certaines peuvent être divisées en deux. Les instruments demandent une mise en température, un étalonnage ou un nettoyage ; certains exigent un opérateur formé, et quelques-uns se réservent via une étape d’approbation.

L’usage récurrent domine. Un cours a lieu tous les mardis pendant douze semaines et une équipe de labo occupe un créneau permanent : les réservations ponctuelles doivent s’insérer autour de ces séries sans que personne ne perde le fil des unes ou des autres.

Ce que décident les demandeurs et les responsables des installations

  1. 01

    Quelle salle ou quel instrument convient

    Faire correspondre capacité, équipements et emplacement à la demande, et comparer les candidats retenus côte à côte sur les mêmes jours.

  2. 02

    Quelle durée de réservation autoriser

    Durées maximales, horizons de réservation et quotas par groupe empêchent une équipe de monopoliser un instrument partagé.

  3. 03

    Ce qui se passe entre deux réservations

    Étalonnage, mise en température, nettoyage ou remise en place d’une salle doivent s’intercaler entre les utilisateurs sans qu’on puisse réserver par-dessus.

  4. 04

    Comment gérer une salle modulable

    Réserver la salle entière bloque les deux moitiés ; réserver une moitié laisse l’autre disponible.

  5. 05

    Déplacer une série quand une salle ferme

    Quand une salle est indisponible pendant une semaine, chaque séance concernée doit trouver une autre place, idéalement en une seule opération.

Modéliser des ressources partagées

Les lignes sont les salles ou instruments réservables, avec leurs attributs en colonnes, les événements sont des réservations avec un titulaire, et les règles de l’établissement s’exécutent dans vos handlers et sur votre serveur.

Ressources
Regroupez les lignes par bâtiment et par étage, ou par famille d’instruments. Les colonnes d’en-tête de ligne affichent la capacité, l’équipement ou l’emplacement, et rows.filter avec onRowFilter restreint la liste aux salles qui ont assez de places ou aux instruments du bon type.
Événements
Chaque réservation porte son titulaire, son groupe et son objet comme champs personnalisés. La préparation ou l’étalonnage est soit un événement verrouillé d’un type à part, soit, quand il suit un horaire fixe, une plage de cellules désactivées : on ne peut donc pas réserver par-dessus.
Échelle de temps
Les salles de formation se lisent bien en cellules d’une heure sur une semaine, les instruments en heures sur quelques jours. L’état de vue enregistré restaure le zoom, la position de défilement et les groupes repliés de chaque utilisateur ; votre application le stocke avec les éventuels filtres.
Règles
Dans onTimeRangeSelecting et onEventResizing, réglez args.allowed sur false avec un message quand une réservation dépasse la durée maximale ou sort de l’horizon de réservation. Utilisez la sélection multiple pour déplacer plusieurs séances d’un coup quand une salle ferme.

Ce que la frise applique, ce qui revient au système de gestion

  • Filtres de lignes, colonnes et ressources groupées pour trouver ce qui convient
  • Refus, avec message, des sélections et redimensionnements qui enfreignent une règle
  • Cellules désactivées pour l’étalonnage, l’entretien et les fermetures
  • Sélection multiple et déplacement de plusieurs réservations à la fois
  • Un état de vue que vous pouvez enregistrer et restaurer pour chaque utilisateur
  • Rendu personnalisé du statut des réservations et des instruments
  • Identité, groupes et droits de réservation par ressource
  • Quotas, approbations et horizons de réservation appliqués comme règles
  • Séries récurrentes, développées en réservations individuelles
  • La logique des salles modulables, où une réservation bloque des lignes liées
  • Le stockage des vues enregistrées, les notifications et la refacturation des coûts

Exemples fonctionnels

Les problèmes que rencontrent les calendriers partagés

Des règles qui n’existent que dans l’interface

Une sélection refusée guide les utilisateurs de bonne foi ; elle n’arrête pas une requête directe à votre API. Chaque limite affichée par la frise doit aussi être vérifiée sur le serveur.

Un cours récurrent en un seul long événement

Une barre unique de septembre à décembre bloque toutes les heures intermédiaires. Développez la série en séances pour que chacune puisse être déplacée ou annulée.

Des identifiants de ligne instables

Les vues enregistrées mémorisent la ligne du haut par son identifiant. Si les salles sont renumérotées ou si les identifiants sont générés à chaque chargement, les vues restaurées tombent sur les mauvaises lignes.

Oublier l’autre moitié d’une salle modulable

Une réservation de la salle entière doit bloquer les deux moitiés, et inversement. Vérifiez les lignes liées dans votre validation ; la frise ne connaît que la ligne sur laquelle on dépose.

Questions

Comment empêcher de réserver un instrument plus de quatre heures ?

Vérifiez la durée dans onTimeRangeSelecting pour les nouvelles réservations et dans onEventResizing pour les modifications, et réglez args.allowed sur false avec un message comme « Les réservations sont limitées à 4 heures ». Appliquez la même limite sur le serveur.

Chaque utilisateur peut-il enregistrer sa propre vue du planning ?

Oui. getViewState, de super-scheduler/views, renvoie une description sérialisable en JSON du zoom, du défilement, de la densité, des groupes repliés et des largeurs de colonnes, et applyViewState la restaure. Votre application décide où la stocker, par exemple par utilisateur dans votre backend.

Comment modéliser un temps d’étalonnage ou de nettoyage après une réservation ?

Soit vous créez un événement verrouillé après chaque réservation, avec moveDisabled et resizeDisabled, soit vous incluez ce tampon dans votre contrôle de chevauchement pour que la réservation suivante ne puisse pas commencer avant qu’il soit écoulé. La première approche est visible de tous ; la seconde garde la grille plus sobre.

SuperScheduler prend-il en charge les réservations récurrentes ?

Les options de récurrence sont réservées et n’ont aucun effet. Développez chaque série en événements individuels dans votre backend, avec un identifiant de série commun, pour que votre application puisse proposer « modifier cette séance » et « modifier toutes les séances suivantes ».

Deux démos d’installations partagées

Morrow modifie une séance de formation et vérifie quelles salles sont libres au même moment ; Benchlab réserve du temps d’instrument avec une fenêtre de préparation. Les deux organisations sont fictives.

Exemples fonctionnels