Ce we, j’ai réfléchit au fait qu’il n’était pas pertinent de laisser dans le flux social des activités qui sont clôturées, ou en tout cas, il vaudrait mieux adapter le message affiché dans ce cas et supprimer l’activité du flux social plus tôt.
D’après mon analyse, voici les activités qui ont une date de fermeture :
- devoir et forum ont une date de fermeture (cutoffdate) et une date limite (duedate) à partir de laquelle les soumissions sont marquées comme en retard; (par défaut, quand aucune date n’est spécifiée, la valeur des dates est à 0)
- pour l’atelier, il y a 2 dates de fermeture différentes : une pour la remise du travail (submissionend) et une pour l’évaluation des travaux (assesmentend); (par défaut, quand aucune date n’est spécifiée, la valeur des dates est à 0); ces deux dates seront associées à des événements différents;
- agenda a une duedate qui par défaut prend la valeur null;
- bdd a deux dates limites et je propose d’enregistrer les 2 dates limites dans le champ closingdatefield, avec un séparateur; les libellés des champs sont timeavailableto (disponible jusqu’au) et timeviewfrom (en lecture seule dès le) qui ont par défaut une valeur 0; je pourrais aussi enregistrer une date limite pour l’action de lecture de la bdd sur base du champ timeviewto (0 par défaut);
- leçon a une date de fermeture dans le champ deadline qui prend par défaut la valeur 0;
- teamup a une date de fermeture dans le champ closed qui prend par défaut la valeur null; => suggérer au développeur de mettre 0
- hotpot a une date de fermeture dans le champ timeclose qui prend par défaut la valeur null; => suggérer au développeur de mettre 0
- feedback, scorm, sondage et test ont une date de fermeture dans le champ timeclose qui prend par défaut la valeur 0;
Je propose de gérer ces infos dans la bdd avec cette structure :
3 situations sont possibles :
- Si l’activité n’a ni closingdate, ni latedate, elle est affichée dans le flux social comme prévu et le nettoyage des données se fait quand le lasttime est dépassé de 2 semaines;
- Si l’activité a une closingdate et pas de latedate, dans le flux social, j’indique la closingdate « Date limite: 4 juin 2024 23h00 » et une fois la closingdate passée, j’affiche l’activité comme « Date limite dépassée », et j’opère une suppression sur base d’une closingdate dépassée de 48 heures pour que cette info ne reste pas pendant 15 jours dans le flux social.
- Si l’activité a une closingdate et une latedate, dans le flux social, lorsqu’on est entre la latedate et la closingdate, j’affiche l’activité avec le message « En retard » et la date de fermeture. Une fois la closingdate passée, j’affiche le message « Date limite dépassée ». Et j’opère une suppression sur base d’une closingdate dépassée de 48h.
- s’il y a une latedate et pas de closingdate, j’affiche un message « En retard » « avec la closingdate;
- Après réflexion, je ne gère pas le cas des activités qui ont deux closing date parce que ce serait très complexe en terme de requête.
A chaque nouveau hit, j’en profite pour écraser les dudate et cutoffdate.
Le nettoyage des données doit donc s’opérer en 2 étapes : supprimer tous les events avec un lasttime dépassé de 2 semaines puis supprimer les events avec un cutoffdate dépassé de 48 heures.
Dans ma nouvelle structure, j’en ai aussi profité pour introduire le paramètre « moduletable » dans la définition d’un événement. Ca me paraît plus sûr que de reconstruire son nom.
J’ai hésité à mettre plus que le contextid dans la table de log, mais ce serait lourd et redondant et seul le contextid permet d’identifier une activité de manière unique.
Temps de travail sur cet article : 1/2 jour