CRM Manara

Le projet

CRM Manara est un système d'inscription pour un centre communautaire montréalais qui organise des activités pour enfants, de l'éveil coranique au hip-hop. Les parents inscrivent leurs enfants à des sessions, les moniteurs enregistrent les présences, et les administrateurs gèrent le catalogue, le personnel et les listes d'attente.

Une équipe de trois personnes l'a construit sur une session d'hiver : une API REST Spring Boot sur MySQL derrière un frontend Angular.

Ma contribution

Le domaine backend : activités, sessions et inscriptions, plus les utilisateurs, rôles et profils en dessous. Cela voulait dire entités, repositories, services, contrôleurs REST et DTO, avec les tests unitaires des trois services principaux. Côté Angular, j'ai construit les écrans de session pour l'administrateur, les écrans du moniteur et les services qu'ils appellent. J'ai aussi travaillé sur l'authentification et sur la messagerie entre les parents et le centre, et construit le chatbot avec Ollama et Llama 3.2.

Le plus difficile

Le plus difficile était le cycle de vie de l'inscription, parce que la dernière place d'une session a plusieurs prétendants. S'inscrire exécute ses vérifications dans une seule transaction : la session doit être ouverte, l'enfant ne doit pas déjà être inscrit, et les inscriptions non annulées doivent rester sous la capacité. Sous la capacité, l'inscription est confirmée; à capacité, elle rejoint une liste d'attente ordonnée par ordre d'arrivée et la session passe à COMPLÈTE. Annuler renverse tout cela : le premier enfant en attente est promu et notifié, ou la session rouvre.

Le courriel de confirmation dépend du prix : une session gratuite l'envoie tout de suite, une session payante attend le callback Stripe. Se tromper là-dessus dirait à un parent que son enfant a une place avant qu'elle ne soit payée.

Ce que je changerais

La vérification de capacité compte puis écrit, sans verrou ni colonne de version, donc deux parents qui réclament la dernière place au même moment peuvent tous les deux passer la vérification et remplir la session au-delà de sa capacité; la condition devrait faire partie de l'écriture elle-même, ou la session a besoin d'un verrouillage optimiste. Chaque refus renvoie aussi le même code 400 avec une simple phrase descriptive, donc l'appelant doit interpréter le texte plutôt qu'un code. Et les identifiants étaient commités dans application.properties au lieu d'être lus depuis l'environnement, l'erreur que j'aimerais le plus corriger rétroactivement.