Gestion et Réservation de Ressources
Documentation

1.Présentation générale de GRR

1.1.Qu'est-ce que GRR ?

GRR est un système de Gestion et de Réservations de Ressources.

GRR est particulièrement adapté à la gestion et la réservation de salles et de matériels, mais il peut également être utilisé comme mini-agenda partagé.

Il s'agit d'une adaptation d'une application PHP/SQL sous licence GPL : MRBS (http://mrbs.sourceforge.net).

Cette adaptation est également sous licence GPL  donc libre et gratuite.

Les principales fonctionnalités de GRR sont :

1.2.Les utilisateurs

Les différentes catégories d’utilisateurs sont :

a) Les administrateurs

L'administrateur a accès à l’ensemble des fonctionnalités de l’application : il gère les ressources, la base de données et les autres utilisateurs. Il peut tout voir, réserver et modifier ou effacer toutes les réservations. Il a accès à l'ensemble des paramètres de configuration de GRR.

b) Les administrateurs restreints de sites (version 1.9.6)

Lorsque la fonctionnalité "multi-sites" est activée, il est possible de définir des "sites", qui sont des unités qui regroupent des domaines. Il est alors possible de définir des administrateurs de sites.
En plus de ses droits normaux, l'administrateur d'un site a la possibilité de gérer entièrement un site : création, suppression, modification d'un domaine ou d'une ressource, ajout et suppression de gestionnaires des réservations, d'administrateur de domaines, gestion des mails automatiques.

c) Les administrateurs restreints de domaines

L'administrateur de domaines est à la base un « usager » (voir plus bas) à qui l'administrateur a donné des droits supplémentaires pour administrer tel ou tel domaine.

Concernant les domaines dont ils ont la charge, les administrateurs restreints peuvent, pour le(s) domaine(s) qu'ils administrent :

d) Les gestionnaires

Le gestionnaire est à la base un « usager » (voir plus bas) à qui l'administrateur a donné des droits supplémentaires pour gérer telle ou telle ressource.

Concernant les ressources dont ils ont la charge, les gestionnaires peuvent :

e) Les usagers

l'usager :


Pour les domaines à accès restreint, seuls les usagers spécifiés par l'administrateur y ont accès. Les usagers autorisés y ont alors les même possibilités que dans les domaines publics.

Par défaut, un usager (ni même un gestionnaire ou un administrateur restreint de domaines) ne peut effectuer une réservation dans le passé, ni modifier ou supprimer une réservation passée. Seul l'administrateur a cette possibilité. Il est néanmoins possible de permettre pour une ressource donnée, réservation dans le passé ainsi que les modifications/suppressions de réservations passées.

f) Les usagers "gestionnaires d'utilisateurs"

Le gestionnaire d'utilisateurs, en plus des possibilités d'un usager normal peut :

g) Les visiteurs

Un « visiteur » peut voir les réservations dans les domaines publics (et dans les domaines à accès restreints selon la configuration) ainsi que le détail des réservations mais ne peut ni réserver, ni effacer, ni modifier une réservation. Le visiteur n'a pas accès à son compte et ne peut donc pas modifier son mot de passe. Selon le paramétrage dans la configuration générale, le visiteur a ou non accès à l'outil "Recherche - Rapports - Statistiques".

1.3.Propriétaires et bénéficiaires

Pour chaque réservation effectuée,  GRR distingue le propriétaire de la réservation (celui qui a effectué la réservation) et le bénéficiaire de  la réservation celui au nom duquel la réservation a été effectuée.

La plupart du temps (fonctionnement par défaut), le propriétaire et le bénéficiaire sont une même  personne.

Mais il est possible d'autoriser, ressource par ressource, des utilisateurs à réserver (ils sont alors propriétaires de la réservation) au nom d'autres utilisateurs (qui deviennent alors bénéficiaires de la réservation).

Délégation


L'administrateur général a toujours cette possibilité, mais il peut déléguer ce droit :
Par défaut, seul l'administrateur général dispose de ce droit.

Bénéficiaires : des utilisateurs de GRR ou bien des personnes extérieures

 

Les bénéficiaires sont en général des utilisateurs enregistrés dans GRR. Mais il est également possible de réserver au nom de personnes extérieures. Dans ce cas, le créateur de la réservation dispose de deux champs supplémentaire dans l'interface de réservation :
Remarques

Règles de fonctionnement

1.4.Type d'accès

L'administrateur a le choix entre deux types d'accès à l'application GRR, selon le paramétrage dans la configuration générale :

1.5.Liste des fonctionnalités et droits associés

Fonctionnalités

Administrateurs

Administrateur restreint de sites

(module "multi-sites" activé)

Administrateur restreint de domaines

Gestionnaires

de ressources

 Gestionnaires d'utilisateurs

Usagers

Visiteurs

Paramétrage général, suivi des connexions, calendrier des jours fériés ...

X

  



 



Actions sur la base de données (restauration, sauvegarde, mise à jour)

X

  



 



Création, modification, suppression des utilisateurs X       X    

Création, modification, suppression des types de réservation..

X

  



 



Création, modification, suppression des domaines, des utilisateurs.

X

 X (6)



 



Activation/désactivation d'un type de ressource

X

 X (6)

X (4)


 



Création, modification, suppression des ressources.

X

 X (6)

X (4)


 



Gestion des droits (mail automatique, accès aux domaines restreints, désignation des gestionnaires).

X

 X (6)

X (4)


 



Création, modification, suppression des champs additionnels

X

 X (6)

X (4)


 



Configuration des ressources

Modération des réservations d'une ressource

X

 X (6)

X (4)

X (1)

  



Signaler qu'une réservation est en cours d'utilisation

X

 X (6)

X (4)

X (1)

  



Rendre temporairement indisponible une ressource

X

 X (6)

X (4)

X (1)

  



Création des réservations

X

 X

X

X

 X

X


Modification, suppression des réservations

X

  X

X (4)

X (2)

 X (3)

X (3)


Gérer son compte

X

  X

X

X

 X

X


Visualisation des réservations

X

  X

X

X

 X

X

X

Utilisation de l'outil "Recherche - Rapports - Statistiques"

X

  X

X (5)

X (5)

 X (5)

X (5)

X (5)

(1) uniquement les ressources gérées par lui-même.

(2) uniquement ses propres réservations ou bien les réservations sur des ressources gérées par lui-même.

(3) uniquement ses propres réservations et sur des ressources disponibles.

(4) uniquement pour les domaines dont il a la charge.

(5) selon le paramétrage dans la configuration générale.

(6) uniquement pour les sites dont il a la charge.

1.6.Licence (conditions d'utilisation)

Le code de GRR est couvert par la GNU General Public License.

GRR inclue des programmes et librairies protégés par leurs licences respectives. En voici la liste ci-dessous. Ils appartiennent tous à la famille des logiciels libres et leurs licences respectives sont compatibles avec la GNU General Public License.

2.Installation de GRR

2.1.Pré-requis

Du côté serveur

Du côté client (navigateur)

2.2.Avant l'installation : configuration du fichier config.inc.php

Le fichier "config.inc.php" contient un certain nombre de paramètres qui normalement, n'ont pas besoin d'être modifiés. Le cas échéant, il faut le configurer avant d'«uploader» tous les fichiers vers le serveur web.

2.3.Avant l'installation : configuration du fichier connect.inc.php

La configuration du fichier "connect.inc.php" n'est pas obligatoire si vous optez pour une installation automatisée de la base de donnée. En effet, la procédure d'installation vous invitera alors à entrer dans un formulaire vos paramètres de connexion.

Dans le cas contraire :

2.4.Installation - Etape 1 : transfert des fichiers

La première étape de l'installation consiste à transférer tous les fichiers de l'archive que vous avez téléchargée vers le serveur web/php.

Pour cela, munissez-vous des codes des paramètres de connexion au serveur et utilisez un logiciel de transfert de fichiers tel que « FileZilla ».

On pourra par exemple créer un répertoire "grr" dans le répertoire web du serveur ("htdocs" dans le cas d'Apache).

Une fois les fichiers transférés, vous devez modifier le cas échéant les droits d'accès à certainsfichiers et répertoires. Les droits d'écriture doivent être attribués

2.5.Installation - Etape 2 : création de la base Mysql

Si vous optez pour cette installation, il est nécessaire d'avoir renseigné le fichier "connect.inc.php".
Dans l'archive figure le fichier tables.my.sql à exécuter sur le serveur mysql et qui contient l'ensemble des tables mysql ainsi que les données minimales pour que ça fonctionne.

3.Configuration de GRR en ligne

Une fois le système installé, la première chose à faire est de configurer GRR à l'aide de l'interface web. Pour cela :

Vous avez alors la possibilité d'accéder à un certain nombre de rubriques réservées aux administrateurs :

Nous allons passer en revue quelques-unes de ces rubriques :

3.1.Configuration générale

La configuration générale de GRR s'organise en cinq parties : "Contenu / Apparence", "Accès et droits", "Interactivité",  "Sécurité / Connexions" et "Activation de modules"

Contenu / Apparence

Accès et droits

  

Interactivité

Sécurité / Connexions

Activation de modules

3.2.Types de réservation

Dans cette partie, sont précisées les différents types de réservation. Il est possible de spécifier jusqu'à 100 types (de A à Z, puis AA, jusqu'à AZ, etc...). Chaque type a une couleur et un nom ainsi qu'un ordre d'affichage dans les différents plannings.

Lorsqu'un type est crée, celui-ci est actif pour tous les domaines. Ensuite, pour chaque domaine, il est possible d'activer ou de désactiver un ou plusieurs types de réservation. Il est également possible de spécifier un type par défaut lors d'une nouvelle réservation.

3.3.Calendrier hors réservation

Il est possible de spécifier un calendrier de journées hors réservation : les journées cochées dans cette interface  correspondent à des journées pendant lesquelles il n'est pas possible de réserver.
En ce qui concerne les réservations avec périodicité, ces journées sont ignorées lors de la validation de la réservation.

Remarque : lors de la configuration de ce calendrier, si des réservations ont déjà été enregistrées sur les journées que l'administrateur coche, celles-ci sont automatiquement et irrémédiablement supprimées (les personnes concernées par les suppressions ne sont pas prévenues par email).

3.4.Gestion des domaines (ajout/modification)

Nom : le nom du domaine.
Ordre d'affichage : dans les différentes interfaces, les domaines sont affichés selon l'ordre d'affichage.
Accès restreint :
Configuration de l'affichage des plannings des ressources de ce domaine :

Début de la semaine : sur les plannings hebdomadaires, les semaines commencent par cette journée.
Jours à afficher sur les différents plannings : seuls les jours cochés apparaissent sur les différents plannings.

Les créneaux de réservation peuvent être soient basés sur le temps, soient basés sur des intitulés pré-définis.

Cas où les créneaux de réservation sont basés sur le temps.

Exemple 1

Pour mettre en place des réservations entre 8 h et 19 h, avec un pas de 15 minutes (900 secondes), la configuration doit être la suivante :

Exemple 2

Pour mettre en place deux créneaux de réservations [8 h - 14 h] et [14 h - 20 h], soit des bloc de réservation de 6 h (21600 secondes), la configuration doit être la suivante :

Cas où les créneaux de réservation sont basés sur des intitulés pré-définis

Il ne s'agit pas du mode normal de fonctionnement de GRR. N'utilisez ce mode uniquement dans le cas où le mode précédent ne correspond pas à votre cas de figure, c'est-à-dire lorsque vos créneaux de réservation sont de taille inégales et ne peuvent pas se subdiviser en blocs de tailles égales ou bien lorsque les créneaux ne couvrent pas uniformément la plage de début à la fin.
Exemple :
Créneau 1 : 8h10 - 9h00
Créneau 2 : 9h00 - 9h50
Créneau 3 : 10h05 - 10h55
Créneau 4 : 10h55 - 11h45
Créneau 5 : 11h45 - 12h35
Créneau 7 : 12h35 - 13h00
Créneau 8 : 13h00 - 13h50
Créneau 9 : 13h50 - 14h40
Créneau 10 : 14h40 - 15h30
Créneau 11 : 15h45 - 16h35
Créneau 12 : 16h35 - 17h25
Créneau 13 : 17h25 - 18h30
Créneau 14 : 18h30 - 19h30

Durée maximale d'une réservation pour une ressource donnée

Il est possible de définir une durée maximale pour une réservation donnée. Dans ce cas, une réservation ne pourra pas excéder une durée limite, suivant les propriétés suivantes :

Cette limitation ne touche pas les administrateurs et gestionnaires des ressources du domaine.

Remarque : actuellement, les journées hors réservation sont prises en compte dans le calcul de la longueur d’une réservation.

Exemple : supposons que la limite soit fixée à trois jours et que le week-end soit hors réservation. Une réservation débutant le vendredi matin et se terminant le lundi soir ne sera pas acceptée car GRR considère à tort que la réservation dure 4 jours. Il s'agit d'un là bug.

3.5.Gestion des ressources - Généralités

Pour chaque ressource :

on peut définir un nombre maximum de réservations par utilisateur, pour une ressource donnée. Par défaut (valeur -1) il n'y a pas de restriction. Attention : ces restrictions ne s'appliquent pas aux administrateurs généraux ainsi qu'aux administrateurs restreints du domaine ou aux gestionnaires chargés d'administrer la ressource. Vous pouvez également définir, dans la configuration générale de GRR, un nombre maximal de réservation qui s'applique toutes ressources confondues.

Possibilité de définir un nombre maximal de jours au-delà duquel l'utilisateur ne peut pas réserver ou modifier une réservation. Exemple : une valeur égale à 30 signifie qu'un utilisateur ne peut réserver une ressource que 30 jours à l'avance au maximum. Cette limitation ne touche pas les gestionnaires de la ressources ainsi que les administrateurs du domaine.

Possibilité de définir un temps en minutes en-deçà duquel l'utilisateur ne peut pas réserver ou modifier une réservation (0 si pas de restriction).
Exemple : une valeur égale à 60 signifie qu'un utilisateur ne peut pas réserver une ressource ou modifier une réservation moins de 60 minutes avant le début de la réservation.
Cette limitation ne touche pas les gestionnaires de la ressources ainsi que les administrateurs du domaine.

Possibilité (case à cocher) de permettre ou non les réservation dans le passé ainsi que les modifications et suppressions de réservations passées.
Si la case n'est pas cochée, un usager (ni même un gestionnaire ou un administrateur restreint de domaines) ne peut effectuer une réservation dans le passé, ni modifier ou supprimer une réservation passée. Seul l'administrateur général a cette possibilité.

L'administrateur et le(s) gestionnaire(s) désigné(s) ont la possibilité de déclarer la ressource « temporairement indisponible ». Ceci est alors clairement signalé sur les plannings de réservation (« jour » et « semaine ») et a pour effet de rendre impossible toute nouvelle réservation et toute modification de réservations existantes (sauf pour l'administrateur et les gestionnaires de la ressource).

L'administrateur et le(s) gestionnaire(s) désigné(s) peuvent choisir de rendre visible ou non la fiche de présentation d'une ressource. Pour cette fiche, ils disposent d'un champ permettant une description complète de la ressource. Ce champ dispose d'une barre d'outils de mise en forme utilisant l'application FckEditor. Il est possible de désactiver cette fonctionnalité dans la page de configuration générale de GRR. Le répertoire "fckeditor" et tout ce qu'il contient n'est alors pas nécessaire au bon fonctionnement de GRR).

On peut également choisir une image pour la ressource qui sera alors visible dans la fiche de présentation.

Dans la page de modification des paramètres d'une ressource, l'administrateur a la possibilité d'activer la fonction « Poser des réservations sous réserve ». Dans le cas, la personne effectuant une réservation a la possibilité de remplir un champ supplémentaire : « Réservation à confirmer au plus tard le ... ». Si l'utilisateur ne confirme pas sa réservation avant la date indiquée, la réservation est automatiquement supprimée et un mail automatique est envoyé aux personnes concernées.

3.6.Champs additionnels

Dans cette partie, vous avez la possibilité de définir, domaine par domaine, des champs additionnels de votre choix et qui apparaîtront dans les formulaires de saisie des réservations comme autant de champs supplémentaires.

Il est possible de définir trois types de champs : « text » (une seule ligne), « textarea » (champ multi-lignes), ou bien « liste ».

Il est également possible de :

Cas particulier des listes

Dans le cas d'une liste, l'administrateur doit spécifier dans un champ spécifique la liste des choix possibles sous la forme d'une seule chaîne de caractères comportant les différents choix séparés par le caractère |.

Exemple : choix1|choix2|choix3 permet de définir une liste de trois items (choix1, choix2 et choix3).

Attention, une fois GRR en production, l'administrateur ne devrait pas être amené à changer la formulation d'un item de la liste car toutes les réservations déjà enregistrées avec cet items perdraient alors cette informations. Même chose si l'administrateur supprime un item de la liste.

3.7.Gestion des utilisateurs

La page [Administration]->[Utilisateurs] permet de gérer les utilisateurs de GRR.

Utilisateurs autorisés à modifier leur nom, prénom et email
L'administrateur choisit quels utilisateurs ont le droits de modifier leurs informations personnelles (nom, prénom, email). Il y a trois niveaux possibles :

Remarques :
Utilisateurs autorisés à modifier leur mot de passe 
L'administrateur choisit quels utilisateurs ont le droits de modifier leur mot de passe. Il y a trois niveaux possibles :

Remarques :

tableau général
Le tableau général permet de visualiser d'un seul coup d'oeil l'ensemble des utilisateurs, de leur statut et des éventuels privilèges.

Privilèges :
La colonne « privilèges » affiche pour chaque utilisateur, jusqu'à six lettres A, S, G, U, E et R :

La présence de telle ou telle lettre signale que l'utilisateur dispose de certains privilèges. En cliquant sur le lien à gauche des nom et prénom de l'utilisateur, on a alors tous les détails liés à ces privilèges.

Statut :
Quatre statuts possibles (cliquez ici pour en savoir plus) :
Il est possible de modifier le statut d'un utilisateur en cliquant sur le lien à gauche des nom et prénom de l'utilisateur.

Authentification :
La colonne « authentification » affiche le type d'utilisateur : local ou ext. Voir aussi Authentification et ldap.

Suppression :
La suppression d'un utilisateur est définitive et irréversible. L'utilisateur est alors effacé de la base mais pas les réservations effectuées par celui-ci.

Mot de passe :
Les mots de passe sont stockés cryptés (MD5) donc pas de possibilité de les voir en clair, une fois qu'il sont définis. En cas de perte d'un mot de passe d'un utilisateur l'administrateur peut évidemment écraser l'ancien par un nouveau : en cliquant sur le lien des nom et prénom de l'utilisateur, il est possible de modifier le mot de passe d'un utilisateur.

Utilisateurs actifs/inactifs
Lorsqu'un utilisateur est ajouté à la base, il est actif par défaut. Par la suite, l'administrateur peut rendre inactif un utilisateur. Un utilisateur inactif reste présent dans la base mais ne peut pas se connecter à GRR. Dès qu'il est à nouveau actif, l'utilisateur peut à nouveau se connecter et retrouve le cas échéant tous ses privilèges.

3.8.Accès aux domaines restreints

Vous avez la possibilité de définir des domaines à accès restreint : [Administration] -> [Domaines et ressources] , puis cliquer sur l'icone de modification du domaine.
Par défaut, aucun utilisateur n'a accès à ces domaines (hormis les administrateurs).

L'administrateur du domaine doit explicitement désigné les personnes autorisées à accéder aux ressources de ces domaines ([Administration] -> [Accès aux domaines restreints]).

Remarque : les domaines à accès restreints peuvent notamment servir à rendre visible une ressource uniquement pour certains utilisateurs.

3.9.Gestion des ressources

Parmi les différentes catégories d'utilisateurs, il y a le gestionnaire de ressource. Par défaut, un simple utilisateur peut modifier ou effacer uniquement ses propres réservations. En revanche, s'il devient gestionnaire d'une ressource, il peut alors modifier ou effacer n'importe quelle réservation de cette ressource. Il a de plus de nombreux droits supplémentaires lui permettant de gérer cette ressource.

Voir aussi :

3.10.Nombre max. de réservations par utilisateur

Astuce : Comment rendre visible une ressource pour tous les utilisateurs, mais « réservable » par un nombre restreint de personnes ?

3.11.Méthode d'exécution automatique de tâches

L'activation de certaines fonctionnalités de GRR nécessite la possibilité de mettre en place l'exécution automatiques de tâches.

C'est le cas par exemple lors de la suppression automatique de certaines réservations dans le cas des « réservations sous réserve », ou encore lors de l'envoi d'une notification de retard en cas de non restitution d'une ressource.

Pour effectuer ces tâches automatiques, rendez-vous dans Administration -> Configuration générale -> Interactivité.

Il y a deux configurations possibles, chacune ayant ses inconvénients et ses avantages.

La tâche  automatique est déclenchée une fois par jour lors de la connexion du premier utilisateur

La tâche automatique est réalisée une fois par jour, lorsqu'un utilisateur se connecte : chaque jour, lors de la première connexion, la procédure de vérification des tâches à effectuer est lancée. C'est donc la connexion du premier utilisateur qui déclenche l'exécution du script.

La tâche automatique est déclenchée par l'exécution du script « verif_auto_grr.php »


ATTENTION : dans ce cas, il faut avoir la possibilité de programmer l'exécution automatique et périodique du script verif_auto_grr.php. Sur un serveur Linux, par exemple, le script verif_auto_grr.php peut être programmé en tâche « cron » avec une commande du type :
php -f /chemin_complet_du_site_grr/verif_auto_grr.php mot_de_passe
La périodicité conseillée est de 1 jour, en début de journée avant les premières connexions.


Si GRR est installé sur un serveur mutualisé, l'accès aux tâches « cron » est exclue. La solution consiste alors à faire appel à une serveur conçu pour rendre ce genre de service. Il en existe plusieurs sur Internet. Parmi les service gratuits, citons :
htttp://webcron.org
http://cronjob4you.at
http://cronjob.de
Certains hébergeurs offrent également ce service à leurs clients.

Le principe est le suivant :
1) Inscription en ligne sur le site afin d'obtenir un compte avec login et mot de passe.
2) A l'aide du compte, créer des tâches en fournissant l'adresse du script à exécuter (dans notre cas, quelque chose du genre http://mon-site.fr/grr/verif_auto_grr.php?mdp=mot-de_passe), la périodicité et l'heure d'exécution du script.

Remarque : l'exécution du script verif_auto_grr.php requiert un mot de passe.
Le mot de passe  est défini dans la même page de configuration que le paramètre précédent.

3.12.Administration des sites

Lorsque le module "multi-sites" est activé (version 1.9.6), il est possible de définir des  administrateurs restreints de sites  habilités à administrer tel ou tel site.

Les sites sont des unités qui regroupent des domaines. Concrètement, il peuvent correspondre à des localisations géographiques de domaines.

Les administrateurs restreints de sites disposent, pour le ou les sites dont il a la charge, des même droits que l'administrateur général : création, suppression, modification de domaines, de ressources dans les domaines, ajout et suppression de gestionnaires des réservations, gestion des mails automatiques, etc...

3.13.Administration des domaines

Parmi les différentes catégories d'utilisateurs, il y a les administrateurs restreints de domaines. L'administrateur général de GRR peut désigner des personnes habilitées à administrer tel ou tel domaine. ces administrateurs restreints disposent, pour le ou les domaines dont il a la charge, des même droits que l'administrateur général : création, suppression, modification d'une ressource, ajout et suppression de gestionnaires des réservations, gestion des mails automatiques, etc...

Voir aussi :

4.Utilisation de GRR

4.1.Accéder à GRR

L'accès au logiciel se fait à partir d'un simple navigateur Internet (FireFox, Mozilla, Internet Explorer, Safari, ...). Selon la configuration du serveur, l'accès sera possible uniquement en Intranet ou bien  de l'Internet, à partir de n'importe quel poste connecté à Internet, en tapant l'adresse qui convient du type "http://votre.domaine.fr/dossierGRR/" dans la barre d'adresse du navigateur.

4.2.Consulter les plannings de réservation

Selon la configuration choisie par l'administrateur de GRR, la consultation des plannings est possible avec ou sans un identifiant et un mot de passe.
L'utilisateur a le choix entre plusieurs interfaces de visualisation.

L’utilisateur peut

En cliquant sur une réservation dans le planning, l'utilisateur peut visualiser les détails de la réservation.

4.3.Réserver une ressource

Pour effectuer une réservation, il est nécessaire d'être connecté, quelle que soit la configuration de GRR.

Pour réserver une ressource sur une plage horaire donnée, l'utilisateur choisit le planning (vue "jour", "semaine" ou "mois") et la ressource à réserver. Puis il clique, dans le planning, sur la petite croix verte de la case qui correspond au début de la réservation. Une fiche de réservation apparaît alors, que l'utilisateur doit compléter avant de valider.

Remarque :
De façon générale, les réservations sont effectuées au nom de la personne connectée. Par défaut, hormis les administrateurs, personne de peut réserver au nom d'une autre personne. Mais il est possible de spécifier pour une ressource donnée, quels types d'utilisateurs ont le droit de faire des réservations au nom d'autres utilisateurs ("Administration" -> "Domaines et ressources" -> choix du domaine, puis propriétés de la ressource).

Voir aussi la rubrique "Propriétaires et bénéficiaires"

4.4.Modifier ou supprimer une réservation

Comme pour la réservation, il est nécessaire de s'identifier pour modifier ou supprimer une réservation.
Les personnes habilitées à supprimer ou modifier une réservation sont :

L'utilisateur clique sur la réservation à modifier ou supprimer puis, dans la nouvelle page qui s'ouvre, il clique sur le lien correspondant à l'action qu'il désire (suppression ou modification).

4.5.Poser des réservations sous réserve

Dans la page de modification des paramètres d'une ressource, l'administrateur a la possibilité d'activer la fonction « Poser des réservations sous réserve ».

Si l'utilisateur ne confirme pas sa réservation avant la date limite, la réservation est automatiquement supprimée et un mail automatique est envoyé aux personnes concernées.

il est possible de configurer dans les paramètres de configuration générale, la méthode suppression automatique utilisée.



4.6.Les périodicités (réservations qui se répètent)

Comment créer une réservation qui se répète ?

Après avoir cliqué sur l'heure désirée, l'écran de réservation s'affiche. En cliquant sur le lien en bas de la page, vous ouvrez les options de périodicité.
Choisissez le type de Périodicité approprié. La ressource sera réservée à la même heure, jusqu'à la date de fin de Périodicité, et seulement pour les jours spécifiés par le type de Périodicité.


Comment fonctionnent les périodicités ?

Prenons un exemple :

 J'effectue une réservation "A1" avec périodicité. Supposons que cette périodicité entraîne la création de n créneaux de réservation. Que se passe-t-il au niveau de l'application ?
  1. GRR génère les réservation "A1", "A2", .... "An" (correspondant à autant d'entrées dans une table de la base de données nommée grr_entry),
  2. GRR génère une entrée supplémentaire dans une table spéciale grr_repeat qui mémorise les informations liées à la périodicité,
  3. enfin, pour chaque réservation de la table grr_entry, un champ mémorise sous forme d'un identifiant, la périodicité à laquelle la réservation est rattachée.
Que se passe-t-il si je modifie une des réservations A1, A2, ... ?

 L'entrée correspondante dans la table grr_entry est modifiée avec les nouvelles informations. C'est tout ! Cela signifie qu'il n'y a plus concordance entre cette réservation et les informations de périodicité. De même, je peux supprimer la réservation "A2". Il restera alors dans la table grr_entry, les réservations "A1", "A3", .... "An".

Que se passe-t-il alors si je modifie la périodicité ?
  1. Toutes les réservations dans la table grr_entry sont mises à jour avec les nouvelles informations,
  2. la périodicité dans la table grr_repeat est également mise à jour.
Il y a donc à nouveau concordance entre les informations individuelles de la table grr_entry et les informations de périodicité. Ainsi, si une réservation, par exemple "A2", avait auparavant été supprimée, elle est alors réinsérée dans la table.

Que se passe-t-il alors si je supprime la périodicité ?
  1. GRR supprime l'information de périodicité dans la table grr_repeat,
  2. pour chaque réservation de la table grr_entry, le champ qui mémorisait la périodicité à laquelle la réservation était rattachée, est vidé.
Les réservations "A1", "A2", .... "An" sont devenues complètement indépendantes les unes des autres.

4.7.Signaler qu'une ressource est empruntée

Dans la page de renseignement d'une réservation d'une ressource, une possibilité supplémentaire est offerte aux gestionnaires de cette ressource : en cochant une case, il peuvent signaler qu'une ressource est empruntée. une petite image (panneau représentant une main sur un fond rouge) apparaît alors dans les plannings de visualisation (« jour » et « semaine ») dans la case correspondante à la réservation.

Concrètement, le gestionnaire de la ressource a le choix entre trois possibilités :
  1. La ressource a été restituée. (Sélectionner également cette option si vous n'utilisez pas cette fonctionnalité) ;
  2. Signaler que la ressource est empruntée.
  3. Signaler que la ressource est empruntée et envoyer un mail notifiant le retard  (nécessite que la fonction d'envoi automatique de mail soit activée).
En cochant la 2ème ou la 3ème option, le gestionnaire signale que la ressource est empruntée et n'est donc pas restituée. Lorsque la ressource a bien été restituée, le gestionnaire ne doit pas oublier de sélectionner l'option n° 1 ci-dessous.

Il est également possible, en cochant une case, d'envoyer immédiatement un mail de notification de retard.

Remarque : pour une ressource donnée, une seule réservation peut être signalée "empruntée".

Dans le cas où l'option n° 3 a été sélectionnée, un email notifiant le retard est envoyé quotidiennement à l'utilisateur ayant réservé la ressource et ceci dès le lendemain de la fin de réservation.
Un email est également envoyé aux gestionnaires de la ressource, ou  à défaut, aux administrateurs de la ressource (ou en dernier recours aux administrateurs généraux).

Pour mettre fin à l'envoi des email, un gestionnaire de la ressource ou un administrateur doit changer le statut de la réservation en sélectionnant l'option n°1 ( "La ressource a été restituée") dans la page de visualisation de la ressource.

4.8.Mise en forme du texte

Par sécurité, depuis la version 195, les balises HTML ne sont plus autorisées dans les champs "brève description", "description complète" et dans les champs additionnels.

En revanche, depuis la version 196, il est possible d'utiliser le BBcode pour mettre en forme le texte dans ces champs.

Le BBcode est une simplification du langage HTML dans lequel les balises sont délimitées par les crochets [ et ].
Voici la liste des balises BBcode autorisées dans GRR :

Fonction Syntaxe
Texte en gras [b]Texte[/b]
Texte en italique [i]Texte[/i]
Texte souligné [u]Texte[/u]
Texte barré [s]Texte[/s]
Texte colorié (en rouge) [color=red]Texte[/color]
Lien hypertexte (sauf dans le champ "brève description")
 [url]URL du lien[/url]
[url=URL du lien]Titre du lien[/url]
Image (sauf dans le champ "brève description") [img]URL de l'image[/img]
Adresse email
[email]adresse email[/email]
[email=adresse email] Nom prenom[/email]
Taille des caractères [size=taille] Texte [/size]
Barre horizontale [/] ou [hr]
Alignement centré [center] Texte [/center]
Alignement à droite [right] Texte [/right]
Alignement justifié [justify] Texte [/justify]

5.Outils divers

5.1.Mails automatiques

Dans le panneau "interactivité" de la configuration générale, l'administrateur peut activer ou désactiver l'option permettant l'envoi d'emails automatiques. En effet, dans un certain nombre de cas (création d'une réservation, suppression/modification, modération, ...), GRR peut envoyer automatiquement des mails à certains utilisateurs.

Cas général

Un email est envoyé au bénéficiaire de la réservation lorsque :

Cas des réservations de ressources avec modération

  1. un mail est envoyé à l'utilisateur pour l'avertir que sa demande est en attente de modération,
  2. un mail est également envoyé aux gestionnaires responsables de la ressource, ou à  défaut aux administrateurs de la ressource (ou en dernier recours aux administrateurs généraux) afin d'avertir qu'une demande est en attente de modération.

Notification d'un retard dans la restitution d'une ressource.

Et des utilisateurs systématiquement avertis

Par ailleurs, certains utilisateurs désignés par l'administrateur peuvent également être prévenus par email pour chaque opération ci-dessus. Pour chaque ressource l'administrateur peut désigner un ou plusieurs utilisateurs à prévenir. La configuration des utilisateurs à prévenir par mail s'effectue dans : [Administration] -> [Mails automatiques].

5.2.Suivi des connexions

L'outil de suivi des connexions permet de :

Concernant le journal des connexions :
- Les dates apparaissant en rouge marquent les utilisateurs déconnectés automatiquement après un trop long délai d'inactivité.
- Les lignes apparaissant en vert marquent les utilisateurs actuellement connectés (cela peut correspondre à une connexion actuellement close mais pour laquelle l'utilisateur ne s'est pas déconnecté correctement).
- Les lignes en noir signalent une session close normalement.

Remarque : il est possible à tout moment de  désactiver les connexions ([Administration] -> [Configuration générale]). En désactivant les connexions, vous rendez impossible la connexion au site pour les utilisateurs, hormis les administrateurs. De plus, les utilisateurs actuellement connectés sont automatiquement déconnectés. Néanmoins, si la connexion n'est pas obligatoire pour l'accès au site en visualisation, cet accès reste possible.

5.3.Modération des réservations

L'administrateur d'un domaine ou le gestionnaire d'une ressource peut décider de modérer les réservations d'une ressource dont il a la charge. L'activation de cette fonctionnalité se fait en cochant une case dans la page de configuration de la ressource. Ce qui suit explique le fonctionnement de la modération lorsque cette option est activée :

1) Un utilisateur fait une demande de réservation en remplissant normalement les différents champs du formulaire de réservation.

2) Une fois la demande enregistrée, le ou les gestionnaires responsables de la ressource, ou à défaut, le ou les administrateurs de la ressource (ou en dernier recours les administrateurs généraux) reçoivent un mail automatique leur indiquant qu'il y a une réservation à modérer.

Le demandeur reçoit également un mail lui rappelant sa demande et le fait que celle-ci est en attente de modération.

Remarques :

Dans le mail envoyé aux gestionnaires de la ressource, un lien pointe vers la page de validation de GRR leur permettant de valider rapidement. Sur cette page, le gestionnaire choisit d'accepter la réservation ou bien de la refuser. Le refus entraîne la suppression de la réservation.

Dans le cas de plusieurs réservations liées par une périodicité, le gestionnaire peut accepter ou refuser en bloc l'ensemble des réservations qui n'ont pas encore été modérées individuellement.

Remarque : lorsque le gestionnaire refuse en bloc un ensemble de réservations, cela entraîne automatiquement la suppression des informations de périodicité pour les réservations qui auraient éventuellement déjà été validées individuellement.

L'interface de modération contient une zone de saisie texte facultative dans laquelle le gestionnaire peut motiver sa décision.

Lorsque le gestionnaire valide le formulaire de modération, une sauvegarde des informations liées à la réservation est effectuée dans une table prévue à cet effet. Dans cette même table sont enregistrées le motif de la décision ainsi que l'identifiant de l'utilisateur ayant procédé à la modération.

Une fois que le gestionnaire a validé, le demandeur reçoit par email la décision de modération ainsi qu'un rappel de la demande.

5.5.Réservation en blocs

cette procédure vous permet de réserver ou de libérer très rapidement des créneaux horaires simultanément sur plusieurs ressources de plusieurs domaines et selon un calendrier.

Exemple : Vous pouvez ainsi bloquer à l'année certains jours tels que les week-end, les vacances, les jours fériés ...

Attention : s'il y a conflit avec des réservations existantes, celles-ci seront automatiquement et irrémédiablement supprimées au profit de la nouvelle réservation. De plus, les personnes concernées par les suppressions ne seront pas prévenues par email.

Cette procédure se déroule en trois étapes :

5.6.Recherche, rapports et statistiques

L'outil "Recherche - Rapports - Statistiques" permet d'effectuer des recherches sur les réservations déjà effectuées et d'afficher les résultats sous la forme d'un tableau de statistiques ou bien sous la forme d'un rapport donnant le détail des réservations.

Le résumé statistique

Le résumé statistique est un tableau à double entrée : une ressource par  colonne et un item par ligne correspondant selon la valeur du champ "résumé par".

Par exemple, dans le cas d'un résumé statistique par bénéficiaire, chaque cellule affiche pour chaque utilisateur (un utilisateur par ligne) et pour une ressource
donnée (colonne) :

Autre exemple, dans le cas d'un résumé par "type" : chaque cellule affiche pour chaque type (un type par ligne) et pour une ressource donnée (colonne) :

Fichier CSV

Les fichiers CSV permettent une exploitation des résultats à l'aide d'un tableur. Le séparateur utilisé est le point-virgule.

5.7.La configuration par « jours cycle »

La configuration par « jours cycle » offre la possibilité de réorganiser le calendrier de GRR pour qu'il corresponde non pas aux jours du calendrier « normal », mais à des « jours cycle ».

Ainsi, un établissement peut par exemple fonctionner sur des cycles de 9 jours, appelés « jours cycle ». Soient par exemple « J1 », « J2 », ... « J9 », chacun de ces « jours cycle ».

Dans GRR, une interface permet de faire correspondre, à chaque jour du calendrier « normal », un des « jours cycle » ou éventuellement aucun (jours fériés...).

Par exemple, au lundi 12 février peut correspondre « J1 », au mardi 13 févier, « J2 », au mercredi 14 février, aucun jour cycle, au lundi 20 février on peut faire correspondre « J3 », etc...

Une fois ce calendrier des « jours-cycle » créé, Il est alors possible d'effectuer des réservations avec périodicité selon ses jours cycle.

Dans certains établissements scolaires du Québec, cette organisation des horaires est habituelle.

La marche à suivre est la suivante

 Du point de vue de l'utilisateur, celui-ci dispose, dans les options de périodicité, d'un type supplémentaire de périodicité selon les  "Jours Cycle".

5.8.Numéro de version et mise à jour de la base de donnée

Cet outil indique le numéro de la version de GRR utilisée et permet de mettre à jour la base de données en cas de besoin.

La mise à jour de GRR s'effectue en deux étapes :
- une mise à jour des scripts,
- suivi d'une mise à jour de la base de données

Une fois la mise à jour des scripts effectuées, connectez-vous en administrateur et rendez-vous sur la page de mise à jour de la base de données ([Administration] -> [Numéro de version et mise à jour]). La  page vous propose alors de mettre à jour la base Mysql.

Remarques :

6.Authentification et ldap

GRR s'intègre souvent dans un environnement comportant d'autres applications demandant également une identification. Un des soucis des  administrateurs est alors de mettre en place une structure évitant à l'utilisateur de s'identifier auprès de chaque application. La solution de ce genre de problème réside dans l'installation d'un système d'authentification unique qui "chapeaute" les applications telles que GRR, autrement dit un SSO (Single Sign-On).  SSO désigne des systèmes d'authentification unique permettant de simplifier pour l'utilisateur la gestion de ses mots de passe.

Il existe actuellement plusieurs solutions. Parmi celles-ci, on peut retenir :

Certaines plate-forme ont également développé leur propre SSO. C'est le cas du serveur de communication LCS (http://wwdeb.crdp.ac-caen.fr/LcsDoc/index.php/Accueil)

La difficulté consiste alors à adopter une solution SSO compatible avec les applications que l'on veut mettre en place.

Actuellement, GRR est compatible avec plusieurs SSO (LemonLDAP, CAS, LASSO, LCS).

6.1.Configuration LDAP

Depuis la version GRR 1.7, il est possible de se connecter à GRR en s'authentifiant auprès d'un  annuaire LDAP. LDAP (Lightweight Directory Access Protocol) est un protocole permettant d’interroger un annuaire contenant des informations d’utilisateurs (nom, login, email, ...).

Dans le panneau d'administration de GRR, une page « configuration LDAP » permet d'activer et de configurer l'authentification LDAP. A l'ouverture de cette page, GRR détecte si PHP a été compilé avec le support LDAP. Dans le cas contraire, un message en avertit l'administrateur qui ne peut aller plus loin dans le paramétrage LDAP.

L'activation LDAP consiste à choisir le statut par défaut des utilisateurs venant de l'annuaire (« usager » ou « visiteur »).

Une fois LDAP activé, il faut configurer le fichier « config_ldap.inc.php », ce qui est relativement simple en utilisant la procédure automatique accessible à partir de cette page (attention à donner les droits d'écriture sur le fichier « config_ldap.inc.php »).

Attention : si vous configurez manuellement le fichier « config_ldap.inc.php » (sans passer par la configuration en ligne), vous devez tout de même activer LDAP en choisissant le statut par défaut des utilisateurs importés.

Une fois la configuration correctement effectuée, deux types d'utilisateurs peuvent cohabiter :
Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Quand le type d'authentification d'un utilisateur est « ext », il ne peut changer son mot de passe dans GRR (celui-ci en effet n'est pas stocké dans GRR mais dans l'annuaire LDAP).
L'administrateur peut modifier tous les paramètres d'un utilisateur « ext » tout comme pour un utilisateur « local », à l'exception du mot de passe qui est laissé vide dans la base locale.
L'administrateur a la possibilité de changer un utilisateur « ext » en un utilisateur « local ». La procédure est irréversible. Il y a alors perte de synchronisation entre GRR et LDAP pour cet utilisateur.
GRR n'inscrit aucune donnée dans l'annuaire. Ainsi GRR n’a besoin que d’un accès en lecture seule à l’annuaire LDAP.

Concrètement, quand un utilisateur tente de se connecter à GRR en tapant un identifiant et un mot de passe, GRR suit la procédure suivante :

Une fois un utilisateur « ldap » connecté, il est traité par la voie classique, c’est-à-dire simplement avec le cookie de session. Ainsi on ne se connecte à LDAP que lors de la procédure de connexion à GRR. De même, les paramètres pris en compte dans la navigation dans GRR (affichage par défaut, nom, prénom, email, ...) sont ceux de GRR.

6.2.Authentification IMAP/POP

Il est possible de se connecter à GRR en s'authentifiant à l'aide d'un compte IMAP ou POP3.

L'activation de l'authentification IMAP/POP consiste à choisir le statut par défaut des utilisateurs venant de l'annuaire (« usager » ou « visiteur »).

Une fois authentification activée, il faut configurer le fichier « config_imap.inc.php », soit manuellement, soit en utilisant la procédure automatique accessible à partir de la même page.

Une fois la configuration correctement effectuée, deux types d'utilisateurs peuvent cohabiter :
Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Quand le type d'authentification d'un utilisateur est « ext », il ne peut changer son mot de passe dans GRR puisqu'il s'agit du mot de passe IMAP ou POP.
L'administrateur peut modifier tous les paramètres d'un utilisateur « ext » tout comme pour un utilisateur « local », à l'exception du mot de passe qui est laissé vide dans la base locale.
L'administrateur a la possibilité de changer un utilisateur « ext » en un utilisateur « local ». La procédure est irréversible. Il y a alors perte de synchronisation entre GRR et IMAP/POP pour cet utilisateur.

Concrètement, quand un utilisateur tente de se connecter à GRR en tapant un identifiant et un mot de passe, GRR suit la procédure suivante :
Remarque : l'authentification IMAP/POP ne permet pas de récupérer les données (nom, prénom, ...) de l'utilisateur : celui-ci est donc invité lors de la première connexion à compléter son profil.

6.3.Intégration de GRR dans CAS SSO

L’université de Yale aux Etats-Unis (http://www.ja-sig.org/products/cas/index.html) a développé le logiciel open source CAS (Central Authentification Service) pour centraliser toutes les identifications à différentes applications afin d'éviter les identifications multiples (SSO).
Depuis la version 1.7, GRR est prévu pour fonctionner dans un environnement CAS SSO.

Les Pré-requis :

Version PHP supérieure ou égale à 4.2.2, compilée avec les options suivantes :
--with-curl, --with-openssl, --with-dom, --with-zlib
Installation de la librairie phpCAS (http://esup-phpcas.sourceforge.net/) :
1. téléchargement du package phpCAS
2. Extraction du package dans un sous-répertoire « CAS » dans le répertoire correspondant à l'include_path du php.ini (exemple : /var/lib/php)
3. Création du fichier cas.sso contenant les informations de connexions au serveur CAS, à mettre dans la même répertoire  /var/lib/php

Exemple de fichier cas.sso :
<?php
$serveurSSO="nom.du.serveur.fr";
$serveurSSOPort=8443;
$serveurSSORacine=CAS;
?>

Il est possible de modifier les chemins d'accès au fichier « cas.sso » et à la librairie phpCAS dans le fichier « cas.inc.php ».

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement CAS. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié CAS (« usager » ou « visiteur »).

Remarque :
Depuis la version GRR197, il est possible de configurer le serveur CAS et GRR de façon à pouvoir récupérer dans GRR des attributs LDAP envoyés par le serveur CAS. Il est alors possible d'associer à un attribut LDAP le statut de l'utilisateur dans GRR. Dans ce cas, le statut par défaut précédent n'est utilisé que lorsque la procédure d'association échoue. Reportez-vous à l'annexe 1 de cette documentation pour plus de détails.

Tout comme pour LDAP, deux types d'utilisateurs peuvent cohabiter :
Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

Que se passe-t-il une fois que l'utilisateur a été authentifié par CAS ?

Lorsque GRR est paramétré pour s'intégrer dans un environnement CAS, le processus suivant s'applique :
Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement non CAS à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci étant géré par le serveur CAS).

Lorsqu'un utilisateur se déconnecte, la session GRR est détruite et le navigateur est redirigé vers une page dont l'URL est spécifié dans la page de configuration générale.

6.4.Intégration de GRR dans LemonLdap SSO

ATTENTION :
GRR supporte LemonLDAP mais pas LemonLDAP::NG qui est une réécriture complète de LemonLDAP. En attendant qu'un contributeur me propose les modifications nécessaires pour adapter GRR à LemonLDAP::NG, vous pouvez simplement configurer GRR avec l'authentification HTTP. En effet, LemonLDAP::NG simule une authentification Apache, ce qui permettra à GRR de fonctionner dans un environnement LemonLDAP::NG.


Lemonldap (http://lemonldap.sourceforge.net/) est un système SSO sous GPL utilisé par des grands ministères (MINEFI, Défense, Justice, ...). Depuis la version 1.9.1, GRR est prévu pour fonctionner dans un environnement LemonLdap.

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement Lemonldap. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié (« usager » ou « visiteur »).

Tout comme pour LDAP et CASS SSO, deux types d'utilisateurs peuvent cohabiter :
Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

Que se passe-t-il une fois que l'utilisateur a été authentifié par LemonLadap ?

Lorsque GRR est paramétré pour s'intégrer dans un environnement LemonLdap, le processus suivant s'applique :
Une fois authentifié, GRR regarde si un utilisateur dont le type d'authentification est « ext » ayant cet identifiant est présent dans la base des utilisateurs de GRR.
Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement normal à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci étant géré par le serveur Lemonldap).

Lorsqu'un utilisateur se déconnecte, la session GRR est détruite et le navigateur est redirigé vers une page dont l'URL est spécifié dans la page de configuration générale.

6.5.Intégration de GRR dans un serveur LCS

LCS (http://lcs.ac-caen.fr/) est un serveur de communication développé par l'équipe Académique TICE de Caen et déployé dans l'ensemble des lycées et collèges de l'académie, ainsi que dans de nombreux autres établissements de France.

Depuis la version 1.9.3, GRR est prévu pour s'intégrer sur une serveur LCS.

Intégration de GRR dans un serveur LCS

La mise en place de GRR sur un serveur LCS peut se faire de deux façons : automatique ou manuelle.

1) Mise en place automatique à l'aide du plugin (recommandé)

Connecté en admin sur le serveur LCS, il vous suffit d'installer le plugin LCS (voir documentation LCS). Il se peut que le plugin LCS ne soit pas basé sur la dernière version de GRR. Dans ce cas, voir plus bas ce qui concerne la mise à jour de GRR.

Dans le panneau d'administration de GRR, une page « configuration SSO » permet de modifier le statut par défaut dans GRR (« usager » ou « visiteur ») des élèves et des « non-élèves » (professeurs et administratifs).

2) Mise en place manuelle (expert)

Cette procédure nécessite une assez bonne connaissance du système LCS et se décompose en plusieurs étapes que nous ne développerons pas entièrement dans ce document :

a) Installation dans le répertoire « /usr/share/lcs/ ».

Les modules applicatifs de LCS sont en général installés dans le répertoire « /usr/share/lcs/ » :

b) Installation dans le répertoire « public_html » d'un utilisateur « grr ».

Une autre façon d'installer GRR consiste à créer un utilisateur du groupe « Profs » ayant le nom « grr ». Le chemin d'accès à l'application est alors du type : « http://mon-site-lcs.fr/~grr/ » :

c) Activation de la prise en charge de l'environnement LCS

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement LCS. L'activation consiste à choisir le statut par défaut des élèves et des « non-élèves » (professeurs et administratifs) authentifiés (« usager », « visiteur » ou « ne pas importer »).

d) Mettre en place un lien vers GRR

Contrairement à l'installation automatique (plugin), l'installation manuelle de GRR sur un serveur LCS ne fournit pas automatiquement l'icône « grr » dans la partie « Applications » de LCS. Nous ne détaillerons pas ici les différentes façons de personnaliser le serveur LCS afin de mettre à la disposition des utilisateurs dans l'espace LCS, un lien vers GRR.

3) Mise à jour automatique de GRR

Connecté en admin sur le serveur LCS, il vous suffit de procéder à une mise à jour par le plugin LCS (voir documentation LCS) si elle existe !

4) Mise à jour manuelle de GRR

Il se peut qu'une nouvelle version de GRR soit disponible sur le site de GRR et que le plugin de mise à jour ne soit pas disponible. Dans ce cas, vous pouvez mettre à jour GRR manuellement :

5) Paramétrage de GRR

a) Le fichier « config.inc.php »

Dans le menu « administration », la page « configuration générale » permet de configurer un grand nombre de paramètres.

Attention : en plus de ceux-ci, d'autres paramètres de configuration de GRR, moins courants, sont à votre disposition dans le fichier « config.inc.php » (consulter la documentation de GRR). La modification de paramètres présents dans ce fichier est évidemment plus délicate car elle suppose l'accès à ce fichier qui est normalement présent dans le répertoire du type « /usr/share/lcs/Plugins/Grr/include » (dans le cas d'une installation par le plugin).

Ce fichier « config.inc.php » contient des paramètres très importants et il convient de l'examiner en détail. Toutes les indications nécessaires à la configuration de ce fichier sont disponibles dans la documentation complète ainsi que dans le fichier lui-même.

Parmi ces paramètres, deux sont particulièrement importants dans le cas d'une intégration de GRR dans LCS :

b) Type d'accès à GRR

L'administrateur a le choix entre deux types d'accès à l'application GRR :

c) La variable use_function_mysql_real_escape_string

Au moment où cette documentation est écrire, la version de PHP des serveurs LCS est inférieure à 4.3.0. Or, GRR utilise la fonction « mysql_real_escape_string() » qui n'est disponible qu'à partir de la version 4.3.0 de PHP. Pour que GRR fonctionne dans un environnement LCS, il est donc nécessaire de positionner la variable $use_function_mysql_real_escape_string à "0" (zéro).

Attention : la valeur par défaut dans le cas d'une installation manuelle est $use_function_mysql_real_escape_string = 1.

Fonctionnement

1) Généralités

Lorsque GRR est intégré à un serveur LCS, deux types d'utilisateurs peuvent cohabiter :

Dans la table « grr_utilisateurs » un champ (« source ») indique le type d'authentification de l'utilisateur : « local » ou « ext » (c'est-à-dire ici « LCS »).


2) Cas d'un utilisateur authentifié sur LCS

Concrètement, quand un utilisateur authentifié sur LCS accède à GRR :


A tout moment, chaque utilisateur a accès à la gestion de son compte pour modifier ses paramètres personnels, propres à GRR (paramètres par défaut, langue, ...), stockés dans la base locale de GRR.

Lorsqu'un utilisateur se déconnecte de LCS, la session GRR est automatiquement détruite et l'accès à GRR (en tant qu'utilisateur connecté) est impossible.

Cette procédure de déconnexion automatique est une fonctionnalité des plugins de LCS. Néanmoins, même si GRR est intégré manuellement à LCS, une procédure interne à GRR assure également la déconnexion de GRR lorsqu'un utilisateur se déconnecte de LCS.

3) Cas d'un utilisateur local

Un utilisateur local, non présent dans l'annuaire LDAP de LCS peut se connecter à GRR à l'adresse du type : « http://monserveur.fr/Plugins/Grr/login.php » (dans le cas d'une installation avec plugin).

La possibilité de créer des utilisateurs locaux est intéressante pour permettre l'accès à GRR à des personnes ne disposant pas de compte LCS.

Il est fortement recommandé de créer un administrateur local de GRR. En effet, certaines mises à jour de GRR nécessite un accès particulier pour effectuer la mise à jour.

Gestion des utilisateurs

Dans la partie administration, la page « utilisateurs » permet d'accéder à la gestion des utilisateurs.

La plupart des fonctionnalités disponibles sur cette page ne sont pas propres au cas d'une installation dans un environnement LCS. En revanche, les deux procédures suivantes concernant uniquement le cas de GRR dans un environnement LCS :

1) Nettoyage de la base locale

Lorsqu'un utilisateur est définitivement supprimé de la base LCS, celui-ci peut rester présent dans la base locale de GRR. Au fil des mois, la base locale peut ainsi contenir un certain nombre d'informations obsolètes.

La procédure « Nettoyage de la base locale » recherche et supprime de la base locale de GRR, les utilisateurs LCS qui ne sont plus présents dans la base LCS : ces utilisateurs sont effacés de la table locale « grr_utilisateurs » ainsi que des tables de liaison le cas échéant.

2) Mise à jour de la base locale

Lorsqu'un utilisateur est ajouté à la base LCS, celui-ci peut immédiatement se connecter à GRR, comme cela a déjà été dit plus haut. A sa première connexion à GRR, l'utilisateur est ajouté à la base locale de GRR et apparaît alors dans la liste des utilisateurs.

De même lorsque des informations concernant le nom, le prénom ou l'adresse email d'un utilisateur sont modifiés dans la base LCS, les modifications sont automatiquement répercutées dans la base locale de GRR à la prochaine connexion de l'utilisateur à GRR.

L'administrateur peut néanmoins forcer une mise à jour des utilisateurs de la base locale de GRR.

Cette procédure effectue les deux opérations suivantes :

Insertion dans la base locale de GRR des utilisateurs LCS qui ne sont pas présents localement.

Mise à jour de la base locale de GRR à partir des informations de la base LCS, pour les utilisateurs déjà présents.

3) Quelques remarques

Le fait de rendre inactif un utilisateur a pour effet de rendre son accès à GRR impossible, qu'il s'agisse d'un utilisateur authentifié LCS ou bien d'un utilisateur local.

Dans le panneau d'administration de GRR, la « configuration SSO » permet de spécifier le statut par défaut dans GRR (« usager » ou « visiteur ») des élèves et des « non-élèves » (professeurs et administratifs). Il s'agit du statut qui est attribué à chaque utilisateur lors de sa création dans la base locale.

Il est ensuite possible à tout moment de modifier le statut d'un utilisateur particulier : « usager », « visiteur » ou « administrateur » (voir la documentation complète de GRR pour plus de détails).

6.6.Authentification HTTP

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer l'authentification HTTP. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié (« usager » ou « visiteur »).

Deux types d'utilisateurs peuvent cohabiter :
Dans le tableau de gestion des utilisateurs un champ indique le type d'authentification (« local » ou « ext ») de l'utilisateur.

Remarques :

Que se passe-t-il lorsqu'un utilisateur a été authentifié par HTTP ?

Une fois authentifié par HTTP, GRR regarde si un utilisateur dont le type d'authentification est « ext » ayant cet identifiant est présent dans la base des utilisateurs de GRR.

Une fois l'utilisateur connecté, rien ne diffère pour celui-ci par rapport à un environnement normal à la différence près qu'il ne peut pas modifier son mot de passe (celui-ci n'étant pas stocké dans la base de GRR).

Déconnexion

Lorsqu'un  utilisateur  est authentifié par HTTP, il le reste tout au long de la session.
Conséquence : même si l'utilisateur se déconnecte de GRR (destruction de la session sur le serveur et du cookie de session sur le navigateur), dès qu'il accède à l'URL du type http://monserveur.fr/Grr/, il est à nouveau automatiquement reconnecté à GRR puisqu'il  est authentifié par HTTP.

Kerberos

Les premiers tests effectués montrent que l'authentification HTTP fonctionne également au travers d'un environnement SSO  Kerberos (via le module auth_kerb).

6.7.Intégration de GRR dans le SSO LASSO

LASSO (Liberty Alliance Single Sign On) est une implantation libre des spécifications Liberty Alliance développées par la Société Entr'Ouvert ( http://www.entrouvert.org). Il s'agit d'une bibliothèque écrite en langage C qui permet de mettre en oeuvre les spécifications Liberty Alliance, disponible sous licence GNU General Public Licence.

GRR est prévu pour fonctionner dans un environnement SSO LASSO.

Les Pré-requis :

  1. Pour la configuration du serveur, reportez vous à la documentation disponible sur : http://lasso.entrouvert.org/.
  2. Vous devez également installer spkitlasso, une interface haut niveau pour Lasso disponible ici :  http://perso.entrouvert.org/~bdauvergne/bzr/spkitlasso/
  3. Optionnel: si vous avez installé spkitlasso dans un emplacement personnalisé (en dehors de l'include_path PHP), vous devez également spécifier, dans /include/config.inc.php, le chemin d'accès au répertoire d'installation.
  4. Allez sur http://votre-serveur/grr/lasso/configure.php pour configurer votre nouveau fournisseur de service Lasso (SP, pour Service Provider).
  5. Puis enregistrez ce SP dans le fournisseur d'identité de votre environnement Lasso (IdP, pour Identity Provider), par exemple Authentic.

Fonctionnement

Dans le panneau d'administration de GRR, une page « configuration SSO » permet d'activer la prise en charge de l'environnement LASSO. L'activation consiste à choisir le statut par défaut des utilisateurs authentifié LASSO (« usager » ou « visiteur »).

Tout comme pour les autres SSO, deux types d'utilisateurs peuvent cohabiter :
Néanmoins, LASSO présente la particularité  de "fédération d'identité", avec "anonymisation" des comptes, et la possibilité de lier un compte local existant au SSO.
Il est ainsi possible, pour un compte local existant (avec mot de passe local) de se "fédérer" au SSO LASSO.

7.Personnaliser GRR

7.1.Adapter les fichiers de langue

GRR utilise des fichiers de langue pour l'affichage. Ces fichiers de langue sont situés dans le répertoire /language de votre installation de GRR.

Afin de préserver la compatibilité avec les futures versions de GRR, vous avez la possibilité de substituer vos propres textes aux messages ou libellés officiels, sans pour autant modifier les fichiers fournis avec GRR.

Exemple pour avoir une version française personnalisée
Remarque :
Entre les balises <?php et ?>, vous pouvez placer autant de lignes que vous voulez, chacune correspondant à un texte à substituer.
Fichiers de personnalisation de langue par domaine

Il est possible de personnaliser les fichiers de langue par domaine. Pour cela, il suffit de repérer l'identifiant du domaine (il s'agit d'un nombre facilement repérable dans les adresses URL). Appelons numero, cet identifiant. il suffit alors de créer un fichier nommé lang_subst_numero.fr de la même façon que le fichier lang_subst.fr ci-dessus.

Remarque :
Un fichier lang_subst.fr. peut coexister avec des fichiers lang_subst_numero.fr : ces derniers sont alors prioritaires par rapport au fichier lang_subst.fr.

7.2.Feuilles de style et CSS

Vous pouvez créer votre propre feuille de style.

Pour cela, créez un nouveau répertoire dans le dossier "themes" de votre installation de GRR et prenez pour modèle un des différents répertoires de ce dossier "themes".

Supposons que vous ayez nommé votre répertoire "automne", il vous reste à ajouter ce nom dans la liste des thèmes du fichier misc.inc.php situé dans le répertoire include en prenant pour modèle la façon dont les autres thèmes sont écrits.

Enfin, n'hésitez pas à proposer votre thème à l'équipe des développeurs de GRR pour qu'il soit éventuellement intégré à une future version de GRR.

8.Documentation technique

8.1.Les tables de la base de données

La table grr_room

Elle contient la liste des ressources

La table grr_area

Elle contient la liste des domaines c'est à dire les groupes de ressources.

 

La table grr_site

Table des sites

La table grr_area_periodes

Table utilisée uniquement dans le cas où enable_periods = 'y'. Stocke les numéros et intitulés des créneaux pour chaque domaine :

La table grr_entry

Elle contient la liste des réservations

La table grr_repeat

Elle contient la liste des périodicités

La table grr_utilisateurs

Elle contient les utilisateurs et tous les renseignements les concernant

La table grr_type_area

Table des types de réservation, communs à tous les domaines

La table grr_j_type_area

Table de jointure des type des réservation désactivés dans les domaines

La table grr_j_mailuser_room

Table de jointure des utilisateurs à avertir par mails automatiques

La table grr_j_user_area

Table de jointure des utilisateurs ayant accès aux domaines restreints

La table grr_j_user_room

Table de jointure des utilisateurs gestionnaires de ressources.

La table grr_j_useradmin_area

Table de jointure des utilisateurs administrateurs de domaines.

grr_j_useradmin_site

Table de jointure des utilisateurs administrateurs de sites.

La table grr_j_site_area

Table de jointure qui relie les domaines aux sites

La table grr_log

Table du journal des connexions

La table grr_setting

Cette table contient un certain nombre de paramètres.

La table grr_calendar

Cette table contient les valeurs UNIX des jours hors réservation (jours « fériés »).

La table grr_overload

Cette table contient les noms et types des champs additionnels pour un domaine donné.

La table grr_entry_moderate

Table de sauvegarde des informations de la table grr_entry des réservations après modération.

 

La table grr_calendrier_jours_cycle

Table des "jours cycle"

 

La table grr_correspondance_statut

Table de correspondance entre le statut dans GRR et la fonction LDAP (cas d'un SSO CAS)

 

8.2.Le schéma de la base données

Le schéma ci-dessous permet d'appréhender globalement le schéma de la base de données de GRR.
Remarque : ce schéma ne prétend à aucune rigueur et a juste vocation à donner une idée d'ensemble des tables et des interactions entres elles.

schema

9.Annexe 1 : Configurer CAS pour la récupération d'attributs LDAP

Annexe 1 : Configurer CAS pour la récupération d'attributs LDAP

9.1.Introduction

Quand le SSO CAS est activé dans GRR; il y a deux moyens de récupérer les attributs LDAP d'un utilisateur (email, nom, prénom)

La première méthode est plus difficile à mettre en oeuvre mais permet, selon la structure de l'annuaire de récupérer, en plus des email, nom et prénom, la langue préférée de l'utilisateur ainsi que le profil qui peut alors être associé au statut dans GRR (simple visiteur, utilisateur, administrateur).

C'est cette première méthode que nous allons décrire maintenant.

9.2.Configuration du serveur CAS pour la diffusion des attributs LDAP

Rappel

GRR supporte l’authentification SSO avec CAS mais celui-ci est livré de base sans la librairie phpCAS qui permet de mettre en place ce mécanisme.

La première étape consiste donc à télécharger la librairie phpCAS à l'adresse suivante :

http://www.ja-sig.org/wiki/display/CASC/phpCAS

Il faut ensuite décompresser le contenu de l’archive dans un répertoire nommé « CAS » à l’intérieur du répertoire de l’application web GRR.

Par défaut, CAS n'envoie à GRR que le nom de l'utilisateur lors de la validation du ticket.

Afin de mettre en place la récupération dans GRR d'attributs des utilisateurs depuis l’annuaire LDAP, il est nécessaire de modifier le fichier \WEB-INF\deployerConfigContext.xml du serveur CAS.

Modification du bean attributeRepository

Dans le fichier deployerConfigContext.xml, repérer le bean « attributeRepository ». Ce bean indique à CAS tous les attributs qui devront être envoyés à GRR.

La modification consiste à ajouter les attributs que l’on souhaite récupérer.

Ci-dessous, par exemple on configure une récupération dans LDAP des attributs : sn, givenName, ENTPersonFonction, preferredLanguage et mail :

<bean id="attributeRepository" class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
 ...
 <property name="ldapAttributesToPortalAttributes">
 <map>
 <entry key="sn" value="user_nom_ldap"/>
 <entry key="givenName" value="user_prenom_ldap" />
 <entry key="ENTPersonFonction" value="user_code_fonction_ldap" />
 <entry key="ENTPersonFonction" value="user_libelle_fonction_ldap" />
 <entry key="preferredLanguage" value="user_language_ldap" />
 <entry key="mail" value="user_mail_ldap" />
 ...
 </map>
 </property>
</bean>

Modification du bean serviceRegistryDao

Dans le fichier deployerConfigContext.xml, repérer le bean «serviceRegistryDao» et modifiez le pour qu'il ressemble à l'exemple ci-dessous (en l'adaptant à votre situation).

<bean id="serviceRegistryDao" class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
  <property name="registeredServices">
    <list>
      <bean class="org.jasig.cas.services.RegisteredServiceImpl"
         p:id="1"
         p:description="Acces GRR"
         p:serviceId="*://*.nom_du_site.fr/GRR/**"
         p:name="GRR"
         p:theme="default"
         p:allowedToProxy="true"
         p:enabled="true"
         p:ssoEnabled="true"
         p:anonymousAccess="false">
        <property name="allowedAttributes" value="uid,sn,givenName,mail,ENTPersonFonctions,prefererredLanguage" />
      </bean>
    </list>
  </property>
</bean>


Remarques : l’élément qui permet à CAS de faire la différence entre GRR et les autres applications est le serviceId, qui est un champ permettant d’expliquer à CAS quelle est la forme de l’url d’accès à l’application GRR ;

L’élément allowedAttribute permet d’énumérer tous les attributs qui devront être renvoyés par CAS pour cette application.

9.2.Configuration de GRR

Le serveur CAS envoie donc à GRR Les valeurs suivantes :

user_nom_ldap, user_prenom_ldap, user_code_fonction_ldap, user_libelle_fonction_ldap, user_language_ldap et user_mail_ldap.

L'étape suivante consiste à configurer le fichier « include/config_CAS.inc.php ».

Remarque :

Le fichier « include/config_CAS.inc.php » n'existe pas dans le paquetage de GRR. En revanche, un fichier « config_CAS.inc.php.ori » est présent dans le répertoire « include ». Commencez par renommer ce fichier en config_CAS.inc.php. De cette façon, lors d'une mise à jour de GRR, vous ne risquez pas d'écraser ce fichier « config_CAS.inc.php » car il n'est pas présent dans l'archive.

Idéalement, GRR peut récupérer les 5 valeurs suivantes :

La correspondance entre ces champs et les valeurs envoyées par le serveur CAS (user_nom_ldap, user_prenom_ldap, user_code_fonction_ldap, user_libelle_fonction_ldap, user_language_ldap et user_mail_ldap) se fait de la manière suivante :

Par défaut, le fichier « include/config_CAS.inc.php » comporte les lignes suivantes :

$user_nom=recuperer_nom(phpCAS::getAttribute('user_nom_ldap'));
$user_prenom=recuperer_prenom(phpCAS::getAttribute('user_prenom_ldap'));
$user_language=recuperer_language(phpCAS::getAttribute('user_language_ldap'));
$user_code_fonction=recuperer_code_fonction(phpCAS::getAttribute('user_code_fonction_ldap'));
$user_libelle_fonction=recuperer_libelle_fonction(phpCAS::getAttribute('user_libelle_fonction_ldap'));
$user_mail=recuperer_mail(phpCAS::getAttribute('user_mail_ldap'));

Explications :

Explication de la première ligne :

$user_nom=recuperer_nom(phpCAS::getAttribute('user_nom_ldap'));

Traitement des attributs LDAP

Pour chacun des attributs LDAP envoyé par CAS à l'application GRR il est possible de personnaliser dans le fichier « include/config_CAS.inc.php », des fonctions de traitement de ces attributs.

Par exemple, dans le cas d'un ENT basé sur l'annuaire fédérateur de l'Education Nationale, les informations concernant le profil sont lues dans l’annuaire LDAP, dans l’attribut « ENTPersonFonctions ». Or ce champ multivalué est constitué de 5 valeurs. L'identifiant du profil et son libellé sont respectivement les 2ème et 3ème champs.

Dans le fichier « include/config_CAS.inc.php » figurent des exemples de code permettant de traiter ces champs multivalués.

Gestion de la correspondance profil / statut

Le profil de l'utilisateur (identifiant et libellé) est disponible grâce aux variables $user_code_fonction et $user_libelle_fonction.

Mais les profils de l'annuaire LDAP ne correspondent pas à priori aux différents statuts possibles dans GRR.

Une interface dans GRR permet donc à l'administrateur de faire correspondre le profil d’un utilisateur (appelé fonction dans l’annuaire LDAP), et le statut qu'il se verra attribué au sein de GRR à sa première connexion à GRR.

Cette interface n'est pas visible par défaut. L'activation de cette interface se fait dans le menu générale de configuration SSO.

Une fois cette fonctionnalité activée, l'administrateur peut compléter le tableau de correspondance.

Ainsi, à la première connexion d'un utilisateur externe authentifié par CAS, son statut dans GRR est déduit du tableau de correspondance.

Remarque : si le profil de l’utilisateur ne possède pas d’entrée dans la table de correspondance une nouvelle entrée est alors automatiquement créée pour ce profil et le statut par défaut (défini dans la page de gestion du SSO) lui est associé.

L’administrateur peut par la suite changer le statut associé à ce profil.

9.3.Autres paramètres de configuration de GRR dans un environnement CAS

Dans le menu « Configuration générale » (onglet « Sécurité / Connexions »)

Dans le menu « Configuration SSO »

Dans le fichier « include/config.inc.php »

1) Paramètre « $sso_super_admin » (prend la valeur false ou true) :

Mettre la valeur du paramètre $sso_super_admin à « true » pour rendre possible l'accès à la page login.php même si l'administrateur a coché dans l'interface en ligne le choix « Empêcher l'accès à la page de login ».

2) Paramètre « $sso_restrictions » (prend la valeur false ou true)

Mettre la valeur du paramètre « $sso_restrictions » à « true » permet de cacher dans l'interface de GRR l'affichage de la rubrique « Authentification et ldap »

9.4.CAS et GRR : gestion du Single Sign-Out

Ce paragraphe est mis à disposition dans la documentation à titre uniquement d'information et sa lecture n'est pas utile pour la configuration de l'environnement CAS dans GRR.

Le Single Sign-Out est implémenté dans phpCAS à partir de la version 1.0.0 : http://www.ja-sig.org/wiki/display/CASC/phpCAS+ChangeLog.

Le Single Sign-Out est implémenté dans CAS à partir de la version 3.0

Le Single Sign-Out est la possibilité d'utiliser le serveur CAS pour déconnecter automatiquement l'utilisateur sur toutes les applications à la fois.

Sans single sign-out, l'utilisateur est déconnecté de CAS, mais toutes les sessions ouvertes sur les applications en SSO restent ouvertes (ce qui pose un problème essentiel de sécurité...). En effet, après réception d'un ticket valide, les applications clients ne revérifient pas systématiquement que la session est toujours active sur le serveur d'authentification (cela génèrerait un flux inutile de requêtes).

Ce n'est que dans les versions les plus récentes de phpCAS que le single-sign out est pris en charge. Une application PHP utilise des connexions stateless (la connexion n'est pas maintenue au-delà de la requête initiale et de sa réponse), et il n'est donc pas possible de transmettre aux applications l'ordre de terminer une session lors d'un logout de CAS.

La manière dont phpCAS a réglé le problème est d'utiliser le nom de la session pour conserver le numéro de ticket CAS, et donc savoir quelle session interrompre. Concrètement, cela se passe de la manière suivante :

Remarque : pour avoir une session qui contient le numéro de ticket, il est indispensable que ce soit phpCAS qui s'occupe d'initier la session php, et non Grr lui-même. C'est à cela que sert le dernier argument "true" de :

phpCAS::client(CAS_VERSION_2_0,$serveurSSO,$serveurSSOPort,$serveurSSORacine,true);

Ainsi, phpCAS gére lui-même la création du cookie de session.

Voir aussi :

http://wiki.esco-portail.org/index.php/Documents:Single_Sign_Out#Traitement_de_la_requ.C3.AAte_via_handleLogoutRequest.28.29_de_phpCAS