Gestion de l’agenda d’une association en Symfony

Comment gérer l’activité d’une association de jeu, comment gérer l’occupation des différentes tables ? Aucun logiciel ou service n’existe vraiment. Eh bien, développons-le, et pourquoi pas en Symfony !

La plupart de mes projets est impossible à voir, inaccessible, car les sources appartiennent aux clients. Ce sont des logiciels propriétaires, dédiés, et si vous ne faites pas partie de la maison, impossible de voir quoi que ce soit.

La problématique

L’association Crazy Orc propose tous les samedis et dimanche des parties de jeux de rôle ou de plateau. Chacun est libre de proposer une partie, ou de participer à une table de jeu. Mais comment faciliter la gestion des tables de jeu ?

Pour cela, il leur faut une application web. Les données sont centralisées, et on peut l’héberger sur un serveur mutualisé au prix compétitif. Du coup, il faut prévoir de préférence une architecture en PHP / MySQL, ce que propose la plupart des hébergeurs mutualisés. Il faut également que le code de l’application soit relativement simple de manière à pouvoir être repris par un bénévole de l’association qui s’y connaisse un peu en développement et en hébergement.

Du coup, j’ai choisi le framework Symfony. Symfony est gratuit et open source, les librairies sont bien documentées, c’est du PHP / MySQL… De plus la structure MVC est facile à appréhender ce qui rend le code lisible et assez facile à comprendre, même pour un néophyte.

Autant que possible, j’ai limité volontairement l’usage du Javascript. La partie frontend est presque exclusivement faite en HTML + CSS, avec l’utilisation du framework d’affichage Bootstrap. Pourquoi ne pas avoir utilisé Angular, VueJs ou ReactJs ? Eh bien pour limiter le nombre de langages ou de frameworks à connaitre pour maintenir l’application. Ainsi, si un autre développeur doit plus tard prendre le relais, il aura moins d’effort à faire pour comprendre la structure de l’application.

Le Planificatorc

C’est le nom choisi pour cette application. Son ergonomie reste simple. La page d’accueil montre l’occupation des tables de la prochaine session de jeu. En semaine, ça affiche le prochain samedi, et en week-end, on reste sur la date du jour. Des flèches permettent de se déplacer d’une session à une autre. Et on peut choisir une date particulière avec un calendrier.

Même si l’association n’ouvre ses portes qu’en week-end, rien n’empêche de créer un évènement en semaine. On ne sait jamais, si une convention extérieure se prépare sur un long week-end, ou si on doit finir une campagne chez l’habitant en semaine, c’est possible.

Les tables de jeu

Chaque table de jeu dispose d’un numéro de repère. On peut y associer un jeu, optionnel, et chaque jeu est typé. Au niveau des entités Symfony, cela veut dire qu’on a une entité TableJeu, avec une relation avec une entité Jeu, qui a aussi une relation avec une entité JeuType. Et tout cela est administrable avec EasyAdmin.

Chaque table de jeu dispose évidemment d’une date, mais aussi d’une localisation, qui est posée à « club » par défaut. On peut également renseigner le nombre maximum de joueurs, et aussi si l’inscription à cette table est ouverte ou fermée. En cas de campagne, ça permet de garder les mêmes joueurs d’une session à une autre.

On peut inscrire à une table des joueurs enregistrés, qui possèdent un compte sur l’application. Mais on peut également y ajouter des joueurs sans compte. Et par table de jeu, on peut définir un utilisateur responsable de la table, en général le Maître de Jeu, le MJ.

Les droits et les rôles

Grâce à Symfony, il a été relativement simple de gérer des niveaux d’accès.

• Utilisateur anonyme
• Utilisateur enregistré mais non approuvé
• Utilisateur approuvé
• Modérateur
• Administrateur

L’utilisateur anonyme, sans compte, a juste un droit de consultation sur l’agenda. Il peut voir aussi la liste des jeux.

Parmi les utilisateurs enregistrés, on distingue deux groupes : les approuvés et ceux qui ne le sont pas. En effet, dans l’association, on doit régler une cotisation, ce qui ouvre à des droits d’utilisation des applications. Gérer cela avec un simple curseur true/false était plus simple pour les tris, pour la visualisation générale que de gérer une date de fin de cotisation.

Un utilisateur non approuvé n’a pas vraiment plus de droit qu’un non enregistré. Par contre, une fois approuvé, l’utilisateur peut s’inscrire lui-même à une table, voire créer une session de jeu. S’il crée une session, il en devient responsable, MJ, par défaut.

Par contre, un utilisateur ne peut pas s’inscrire sur une table fermée, ou si la table est complète. Mais un MJ peut gérer sa table comme il l’entend, et donc supprimer ou rajouter des joueurs, que la table soit ouverte ou fermée, que le nombre maximum de joueur soit atteint ou non. Il est capitaine de son navire.

Un Modérateur peut gérer toutes les tables, qu’il en soit responsable (MJ) ou non. On doit toujours pouvoir faire appel à eux en cas de difficulté.

Un Administrateur peut, en plus, accéder à EasyAdmin, et donc gérer les utilisateurs et leurs droits, ainsi que la liste des jeux et des types de jeux.

Au niveau de Symfony, c’est géré dans le fichier .env :

###> Rôles ###
# À RESPECTER : séparer les éléments par ' || '. Entre le label et sa définition : ' :: '
ROLES="ROLE_USER :: Utilisateur standard, droits minimum par défaut || ROLE_MODO :: Peut gérer les tables de jeu || ROLE_ADMIN :: Administrateur général, tous les droits possibles"
###< Rôles ###

De plus, l’entité User possède une propriété booléenne $active. Les contrôleurs permettent ou non l’accès à différents groupes.

    #[IsGranted('ROLE_USER')]
    #[IsGranted('USER_IS_ACTIVE')]

Et pour l’affichage conditionnel des différents éléments, on le fait dans les vues Twig.

{# Vérifier si la table est ouverte et si le nombre de joueurs est inférieur au maximum autorisé #}
{% if 
	app.user
	and app.user.active
	and tableJeu.isOpen 
	and tableJeu.tableJeuUsers|length < tableJeu.maxJoueurs 
	and not isUserResponsible
	and not tableJeu.isUserAlreadyInTable
%}

Des astuces en plus

L’avantages des entités Symfony, c’est qu’elles sont faciles à manipuler sans avoir à faire des requêtes SQL complexes. Du coup, sans avoir trop de code abscons, j’ai pu rajouter un vérificateur de présence. Le pseudo de l’utilisateur enregistré est surligné pour qu’il repère facilement sa présence. De plus, s’il vaut s’inscrire à une seconde table lors de la même journée, c’est possible. Mais une boîte de dialogue lui demande de confirmer son autre inscription.

De plus, un MJ peut enregistrer la configuration de sa table de jeu, les propriétés de la table et les joueurs inscrits, pour la répéter un autre jour. C’est bien pratique lors des campagnes !

Affichage des statistiques et des données

Avec un tout petit peu de Javascript / Jquery et des librairies adaptées, on peut avoir un rendu sympathique à peu de frais. Avec DataTable, par exemple, on peut rendre les tableaux triables par colonnes, avec un moteur de recherche intégré. Pour afficher la liste des utilisateurs et la liste des jeux, c’est très pratique.

Et avec Chart.js on peut afficher des graphiques en barre ou en camembert des statistiques de fréquentation et d’usages des jeux. C’est beau, personnalisable et interactif.

Ainsi, cette application Symfony possède toutes les qualités pour un logiciel de grade professionnel dans le cadre d’une petite association :

• Facile à héberger
• Facile à maintenir
• Facile à prendre en main
• Facile à faire évoluer tant au niveau des fonctionnalités que des impératifs techniques

Avec cela, on est tranquille encore pour quelques années.

Voir le Planificatorc en action.