Modélisation de la base de données
Cliquez ici pour agrandir l'image
ElementType permet de définir le type d'objet à atteindre :
- Groupe
- Sujet
- Tâche
- Commentaire
- Question
l'ElementType est utilisé afin de gérer la généralisation les relations à tout type d'objets (listés plus haut). Typiquement pour gérer les abonnements aux différents objets (question, tâche, etc...) sans pour autant créer une table intermédiaire pour chaque type d'objet.
Pour le cas des notifications, il faut donc préciser le type de notifications possibles (NotificationType), cette liste est disponible sur la page
Dans une premier temps les notifications seront réalisées de manière globale, l'utilisateur reçoit les notifications liées aux groupes dont il est membre.
Après discussion il a été proposé de scoper les notifications dans une relation parent-enfant, cette relation étant déjà présente entre les différentes entités. L'idée est, par exemple, de pouvoir marquer une tâche ayant des notifications non lues si un de ses enfants liés a été modifié ou si un enfant lui a été ajouté.
L'état actuel de la base de donnée permet de remonter des infos liés à un groupe (ou autre parent) car on a toujours accès au groupe via la successions des relations parents-enfants. Cependant il faut prendre en compte que le nombre de parents à remonter pour trouver un type de parent (ici groupe) est dépendant du type de donnée sur laquelle on travail (tâche -> sujet -> groupe, commentaire -> question -> tâche -> sujet -> groupe) pour cette raison la requête SQL engendrée risque d'être lourde mais pas forcément complexe. Le tri ne peut se faire au niveau de Laravel car cela engendrerait une query trop large qui admettrait beaucoup trop de données.
Dans un premier temps, les professeurs et les élèves auront les mêmes paramètres par défaut par rapport au système de notifications. L'idée est d'avoir une système de notification fonctionnel, la gestion de la finesse prof/élève n'étant pas un priorité dans la mesure où il est possible pour chaque utilisateur de modifier les paramètres de notifications à sa guise. il s'agira simplement de trouve une matrice de paramètre qui convient au mieux pour les deux mondes (à terme il sera possible de définir un matrice de paramètre spécifique pour le type d'utilisateur)
Par souci de simplicité les paramètres de notifications seront gérés de manière globale, il ne sera pas possible de les gérer pour un groupe entier pour que cela soit possible il faudrait intégrer le groupId dans la table Settings_User et intégrer une gestion de paramètre dans chaque groupe. Cependant il faut noter qu'avec la base actuelle il est possible de se désabonner ou s'abonner spécifiquement sur un élément ce qui limite en partie la problématique de ne pas avoir de gestion de paramètre spécifique par groupe.
- Par défaut si aucune entrée n'est défini pour les sujets, les utilisateurs sont automatiquement abonnés
- Gestion des clés primaires composites