Configuration-des-réservations-internes

Présentation

Cette page présente le paramétrage du module de réservations interne.

Gestion du planning (Admin > Structure > Paramétrage > Réservations internes)

Error creating thumbnail: File missing

Mode de réservation

Réservations standards

Cette option permet de faire des réservations classiques, c'est-à-dire que l'on réserve directement une ressource en fonction de son nom (exemple : son immatriculation), cela ne diffère en rien des réservations "papier".

Réservation par type de ressource

La réservation par type permet non pas de choisir une ressource particulière mais un type de ressource. Dans les structures aéronautiques possédant plusieurs aéronefs d'une même famille (plusieurs DR400/120 par exemple) on choisit alors de réserver un DR400/120 parmi ceux de la flotte. Le programme choisira l'immatriculation en fonction de la disponibilité des appareils (entretien mécanique par exemple).

La réservation par type comporte un double intérêt :

• pouvoir donner la priorité à une ressource par rapport à une autre et ainsi pousser telle ou telle ressource à être plus utilisée en fonction des souhaits de programmation (pour les opérations de maintenance par exemple) ;
• créer une ressource fictive supplémentaire pour mettre en place le surbooking.

Si des ressources de même type sont indisponibles, que ce soit parce qu'elles sont réservées ou immobilisées, alors c'est la 1ère ressource disponible qui est choisie par OpenFlyers.

Il est possible de modifier l'ordre de tri des ressources à n'importe quel moment.

De même, pour les utilisateurs disposant du droit "Surpasser la réservation par type", il est possible de forcer une réservation sur une ressource donnée.

Attention : dans le cas où la structure exploite plusieurs ressources d'un même type mais qu'elle souhaite séparer la gestion des réservations pour chaque ressource, il faut créer autant de type de ressource que de ressources. Exemple : une structure aéronautique dispose de 2 avions de type DR420. Si les 2 avions sont identifiés avec un même type "DR420" alors les réservations seront faite toujours en priorité sur le DR420 du plus forte priorité. Si ce comportement n'est pas souhaité, il faut créer 2 types (DR420-1 et DR420-2 par exemple) et associer un avion au type DR420-1 et l'autre avion au type DR420-2.

Code couleur

Permet de définir quelle code couleur doit être utilisée pour l'affichage des réservations :

• Par utilisateur

deux champs de sélection s'affichent :

• Couleur par défaut pour les réservations qui ne concernent pas l'utilisateur

Il s'agit d'une paire de couleurs [Couleur claire (réservation en solo) / couleur foncée (réservation en instruction)] utilisé pour afficher les réservations qui ne concernent pas l'utilisateur connecté.

• Couleur par défaut pour les réservations qui concernent l'utilisateur

Il s'agit d'une paire de couleurs [Couleur claire (réservation en solo) / couleur foncée (réservation en instruction)] utilisé pour afficher les réservations qui concernent l'utilisateur connecté.

Il est possible de configurer une paire de couleurs par utilisateur.

• Par type d'activité

Affichage des activités réalisées

Permet d'afficher sur le planning de l'interface dynamique les activités réalisées. Il est possible de définir ce qui doit être affiché par défaut sur le planning :

• Réservations uniquement
• Réservations et activités
• Activités uniquement

L'option Désactivé permet de désactiver cette fonctionnalité et donc de ne pas afficher les activités réalisées.

Réservation multi-ressources

Cette fonctionnalité permet d'autoriser à un utilisateur de réserver plusieurs ressources sur des créneaux horaires qui se chevauchent.

Attention : cette fonctionnalité n'est pas conçue pour les formateurs/instructeurs et entraine des bugs d'affichage sur le planning de réservation. La version 4 d'OpenFlyers corrigera ce défaut.

Affichage du nom des ressources dans le planning

Ce paramétrage permet d'afficher ou cacher le nom des ressources dans le planning. Cela permet de diminuer la taille verticale des lignes du planning et de cacher ces noms lorsqu'ils ne sont pas nécessaires.

Afficher les alertes non bloquantes lors des glisser-déposer

Ce paramétrage permet d'afficher les alertes non bloquantes lors des glisser-déposer des réservations sur le planning.

Heure de début et fin (useau X) d'activité

Permet de définir la plage horaire du planning de réservation dans le fuseau horaire de la structure.

Interdire d'effectuer une réservation débutant dans moins de

Permet d'empêcher d'effectuer une réservation débutant dans moins de X temps. Cette fonctionnalité est notamment utile en réservation par type lorsque la distribution des ressources réelles par ligne de planning est faite le matin pour la journée. Elle est également utile lorsque la facturation se fait la veille au vu des réservations du lendemain.

Limitation dans le temps des réservations

Permet de limiter dans le temps les réservations.

Limitation du nombre de réservations

Permet de limiter le nombre de réservations par utilisateur.

Saisie de la destination (si champ lieu d'arrivée coché)

Permet de demander à l'utilisateur d'indiquer sa destination et ce en fonction de la durée de sa réservation.

Durée minimale d'une réservation

Permet de définir la durée minimale d'une réservation.

La durée maximale d'une réservation peut se définir pour chaque type de ressource.

Durée par défaut d'une réservation

Permet de définir la durée par défaut.

Afficher ces champs

Permet de définir les champs visibles dans le formulaire de réservation :

• Même jour
• Places à disposition
• Lieu de départ
• Lieu d'arrivée

Les lieux cochés sont ainsi définis avec une valeur par défaut lorsqu'un vol est entré à partir d'une réservation.

Type d'activité par défaut

Permet de définir le type d'activité à cocher par défaut :

• lors d'une nouvelle réservation ou lorsqu'on sélectionne une personne en première place sur le formulaire de réservation de l'ancienne interface
• lors d'une nouvelle réservation sur le planning de la nouvelle interface

Pour définir le type :

• Aller dans Admin > Structure > Paramétrage > Planning
• Champ Type d'activité par défaut : Sélectionner le type d'activité
• Cliquer sur Enregistrer

Type d'activité par défaut pour la seconde place (ancienne interface)

Permet de définir le type d'activité à cocher par défaut lorsqu'on sélectionne une personne en seconde place sur le formulaire de réservation de l'ancienne interface.

Pour définir le type :

• Aller dans Admin > Structure > Paramétrage > Planning
• Champ Type d'activité par défaut pour la seconde place (ancienne interface) : Sélectionner le type d'activité
• Cliquer sur Enregistrer

Règles de saisies XML

Permet d'éditer les Règles de saisie qui s'appliquent, pour le moment, uniquement pour le planning.

Règles de saisies

Les règles de saisie sont utilisées uniquement par le moteur de réservation pour construire l'affichage des champs du formulaire de réservation et pour vérifier, après la saisie d'une réservation, que les données saisies respectent bien les règles de saisie.

Elles sont écrites en XML. cf. l'exemple de règles de saisie.

Le moteur de vérification des règles s'enclenche dès qu'une réservation n'est plus "nue", c'est à dire lorsqu'au moins un élément est renseigné (activité, ressource, etc.). Alors il vérifie quelles sont les règles compatibles et en déduit les contenus possibles dans les champs de saisie de l'interface utilisateur.

La compatibilité d'une règle se détermine par restriction en vérifiant dans cet ordre les informations suivantes :

1. Activités
2. Ressources
3. Profils
4. Places

Pour chaque information, le moteur regarde si elle est renseignée. Si ce n'est pas le cas alors il passe à l'information suivante. Par exemple s'il n'y a pas encore d'activité de saisie alors il ne vérifie pas ce point-là dans la règle.

Pour les activités et les ressources, il regarde les règles qui acceptent celles renseignées. S'il y a des règles qui pose problème alors elles sont rejetées.

Pour les profils ce sont les personnes qui sont étudiées et ce de deux manières différentes selon si sur la saisie il y a une ressource de renseignée ou non.

• Lorsqu'il y a une ressource de renseignée, le fonctionnement est similaire aux autres informations. le moteur regarde pour toutes les personnes renseignées si sur la place où elles sont, elles ont au moins un profil valide. Si une personne n'a aucun profil pour la place où il est alors la règle est rejetée.
• Lorsqu'il n'y a pas de ressource le fonctionnement est différent. Au lieu de faire par restriction, le moteur va faire par ajout. C'est-à-dire qu'au lieu de dire "il ne faut que des pilotes", il va dire "je veux au moins un pilote". Pour ce faire il va regarder les profils de chaque personne. S'il trouve une personne avec un profil valide, il accepte la règle. Si aucune des personnes ne correspond, il va faire une seconde vérification au niveau des places. Si pour cette règle l'une des places n'est pas définie, il considère que les personnes présentes vont potentiellement aller sur cette place et il ne rejette pas la règle. Par contre, si toutes les places sont définies et qu'aucune des personnes ne correspond alors la règle est rejetée.

Pour les places, il vérifie qu'il n'y a pas trop de monde. Comme pour les profils il y a deux manières de les étudier en fonction de s'il y a une ressource ou non.

• Lorsqu'il y a une ressource, il va regarder pour chaque place si le nombre de personnes autorisées n'est pas dépassé. Si sur l'une des places le nombre est dépassé alors la règle est rejetée. Cependant, si le nombre est atteint mais pas dépassé alors la règle n'est pas rejetée.
• Lorsqu'il n'y a pas de ressource, il va parcourir chaque place pour compter le nombre total de personnes autorisées pour cette règle. Si le nombre est dépassé alors la règle est rejetée. Comme précédemment si le nombre est simplement atteint alors la règle n'est pas rejetée.

Si pour chaque information saisie, la règle est compatible alors elle est conservée.

Pour qu'une saisie soit valide, il faut qu'il existe au moins une règle de conservée, c'est à dire de compatible.

Exemple

<?xml version="1.0" encoding="UTF-8"?>
<ruleList>
    <rule>
        <!-- Liste des activités autorisées et requises -->
        <activityTypeList needs="bookAlone">
            <activityType>1</activityType> <!-- Local -->
        </activityTypeList>
        <!-- Liste des ressources autorisées -->
        <resourceList minQty="1" maxQty="1">
            <resourceType>1</resourceType> <!-- F-001 -->
            <resourceType>2</resourceType> <!-- F-002 -->
        </resourceList>
        <!-- Définition des places -->
        <placeList>
            <place index="0"  minQty="1" maxQty="1" status="1" needs="bookAnyone"> <!-- Pilote -->
                <!-- Liste des profils autorisés -->
                <profile>2</profile> <!-- Pilote -->
            </place>
        </placeList>
    </rule>
    <rule>
        <!-- Liste des activités autorisées et requises -->
        <activityTypeList needs="*(bookAlone)(bookWithInstr)">
            <activityType>1</activityType> <!-- Local -->
            <activityType>2</activityType> <!-- Instruction -->
        </activityTypeList>
        <!-- Liste des ressources autorisées -->
        <resourceList minQty="1" maxQty="1">
            <resourceType>*</resourceType> <!-- F-001, F-002, F-00X -->
        </resourceList>
        <!-- Définition des places -->
        <placeList>
            <place index="0"  minQty="1" maxQty="1" status="1"> <!-- Pilote-->
                <!-- Liste des profils autorisés -->
                <profile>1</profile> <!-- Elève -->
                <profile>2</profile> <!-- Pilote -->
            </place>
            <place index="1" minQty="1" maxQty="1" status="2"> <!-- Instructeur -->
                <!-- Liste des profils autorisés -->
                <profile>4</profile> <!-- Instructeur -->
            </place>
        </placeList>
    </rule>
    <rule>...</rule>
</ruleList>

attribut needs

L'attribut needs peut être utilisé pour les éléments :

• activityTypeList
• place

Il contient un ou plusieurs droits qui sont requis par l'utilisateur effectuant la saisie pour que la règle puisse s'appliquer.

Lorsqu'il n'y a qu'un droit de requis, il faut écrire needs="nomDuDroit".

Lorsqu'il y a plusieurs droits possibles, un seul étant requis, il faut commencer par le signe * puis lister chaque droit en l'entourant de parenthèses : needs="*(bookAlone)(bookWithInstr).

ruleList

Élément racine de la structure XML ne peut contenir comme élément enfant que des éléments "rule" qui correspondent, chacun, à une règle.

Il n'y pas d'attribut possible.

rule

Définit une règle.

Les éléments possibles sont :

• formulaList
• activityTypeList
• resourceList
• placeList

Il n'y a pas d'attribut possible.

Chaque règle définit les types d'activités, types de ressources et places qui la rendent compatible.

L'exemple suivant définit une règle qui autorise une saisie pour le type d'activité Local, les types de ressources F-001 ou F-002 et pour laquelle il faut exactement 1 utilisateur avec le profil Pilote à la place 0. Le statut attribué sera celui de numéro 1. De plus, La personne qui fait la réservation doit avoir le droit "bookAlone" et si elle dispose du droit "bookAnyone" alors elle verra en plus la liste des utilisateurs compatibles avec cette règle pour lui permettre d'en choisir une : <xml><rule>

       <activityTypeList needs="bookAlone">
           <activityType>1</activityType> 
       </activityTypeList>
       <resourceList minQty="1" maxQty="1">
           <resourceType>1</resourceType> 
           <resourceType>2</resourceType> 
       </resourceList>
       <placeList>
           <place index="0"  minQty="1" maxQty="1" status="1" needs="bookAnyone"> 
               <profile>2</profile> 
           </place>
       </placeList>
   </rule></xml>

formulaList

Contient la liste des formules que la règle doit respecter au travers des éléments formula.

formula

Doit contenir les attributs :

• action : indique l'action concernée pour la vérification de la formule. Si l'action effectuée par l'utilisateur n'est pas celle de la formule, alors la formule n'est pas vérifiée. Par contre, la règle peut quand être compatible. Il est possible de remplacer le nom d'une action par * pour indiquer que la formule doit être vérifiée quelque soit l'action.
• title : pour indiquer le message d'alerte devant s'afficher lorsque la formule n'est pas respectée

Le contenu de l'élément formula est une formule qui est testée lors de la saisie.

Attention : dans la formule, pour les signes de comparaison supérieur ou inférieur, il faut saisir leur équivalent HTML :

• > doit être remplacé par >
• < doit être remplacé par <
• >= doit être remplacé >=
• <= doit être remplacé <=

Exemple : <xml> <formula action="update" title="Vous ne pouvez pas faire de réservation ayant une durée supérieure à 30 minutes.">(%DURATION <= 300)</formula></xml>

activityTypeList

Contient la liste des types d'activités qui sont compatibles avec la règle.

Peut contenir l'attribut needs.

activityType

Contient l'identifiant d'un type d'activité.

resourceList

Contient la liste des types de ressources qui sont compatibles avec la règle.

Peut contenir les attributs maxQty et minQty pour définir le nombre de ressources maximum et minimum.

placeList

Contient la liste définissant les places.

place

Contient la définition de chaque place.

Peut contenir des éléments profile pour indiquer un profil requis parmi plusieurs pour qu'un utilisateur puisse occuper la place.

Doit contenir l'attribut index pour numéroter la place définie.

Peut contenir les attributs maxQty, minQty, needs et status.

L'attribut needs permet de définir le droit requis pour l'utilisateur effectuant la saisie afin qu'il puisse choisir l'utilisateur dans la liste des utilisateurs compatibles. typiquement, cet attribut est utilisé ainsi : needs="bookAnyone".

L'attribut status permet de définir le statut de la personne à laquelle on attribut la place. Cette définition se fait en utilisant l'identifiant du statut. Exemple : status="1".

profile

Contient l'identifiant du profile requis.

Wildcard

Le caractère * peut être utilisé dans les éléments resourceType. Il indique que la règle s'applique à tous les types de ressources existants de la plateforme.

Exemple avec wildcard : <xml><resourceTypeList minQty="1" maxQty="1">

   <resourceType>*</resourceType>

</resourceTypeList></xml>

Exemple sans wildcard : <xml><resourceTypeList minQty="1" maxQty="1">

   <resourceType>1</resourceType>
   <resourceType>2</resourceType>
   <resourceType>3</resourceType>

</resourceTypeList></xml>