| 1434 |
ariadna |
1 |
# **local_moofactory_notification**
|
|
|
2 |
Gestion de notifications via des tâches programmées.
|
|
|
3 |
|
|
|
4 |
### **Fonctionnalités principales**
|
|
|
5 |
- **siteevents_notification**
|
|
|
6 |
- **coursesevents_notification**
|
|
|
7 |
- **coursesenroll_notification**
|
|
|
8 |
- **coursesaccess_notification**
|
|
|
9 |
- **modulesaccess_notification**
|
|
|
10 |
|
|
|
11 |
---
|
|
|
12 |
|
|
|
13 |
## **modulesaccess_notification**
|
|
|
14 |
Cette fonctionnalité gère les notifications envoyées après la levée de restrictions d’accès à une activité.
|
|
|
15 |
|
|
|
16 |
### **Cas d’usage**
|
|
|
17 |
1. À l’issue des cours, une enquête à chaud est mise à disposition des étudiants.
|
|
|
18 |
2. Les étudiants ne peuvent voir l’enquête qu’après la levée des restrictions.
|
|
|
19 |
3. Une notification est émise lorsque la ou les restrictions sont levées.
|
|
|
20 |
4. Des relances peuvent être envoyées si l’étudiant n’a pas achevé l’enquête.
|
|
|
21 |
|
|
|
22 |
#### **Fréquence d’exécution**
|
|
|
23 |
- La tâche programée s’exécute par défaut toutes les **2 minutes**.
|
|
|
24 |
|
|
|
25 |
#### **Conditions d’envoi des notifications**
|
|
|
26 |
1. **Les notifications sont activées sur la plateforme**.
|
|
|
27 |
2. **Les notifications pour la "levée de restrictions" sont activées** sur la plateforme.
|
|
|
28 |
|
|
|
29 |
Si ces deux conditions sont remplies :
|
|
|
30 |
1. On vérifie toutes les activités ayant des restrictions d’accès.
|
|
|
31 |
2. Parmi ces activités, on vérifie si **les notifications de levée de restrictions** sont activées pour chacune.
|
|
|
32 |
3. Si elles sont activées, les étapes suivantes sont réalisées pour **chaque participant inscrit au cours** :
|
|
|
33 |
- Vérification des permissions de l’utilisateur pour recevoir les notifications.
|
|
|
34 |
- Vérification si l’utilisateur est bloqué par une restriction pour accéder à l’activité.
|
|
|
35 |
4. Si toutes les conditions sont satisfaites, **une trace est stockée en base de données** :
|
|
|
36 |
- **TRACE 1** (situation initiale).
|
|
|
37 |
|
|
|
38 |
#### **Comparaison à la prochaine exécution du CRON**
|
|
|
39 |
- Lors de l’échéance suivante :
|
|
|
40 |
- La nouvelle situation (**TRACE 2**) est comparée à **TRACE 1**.
|
|
|
41 |
- Si l’utilisateur **reste bloqué** par la restriction :
|
|
|
42 |
- **Pas d’envoi de notification.**
|
|
|
43 |
- Si l’utilisateur **n’est plus bloqué** :
|
|
|
44 |
- Vérification s’il a **achevé l’activité** :
|
|
|
45 |
- **Oui** → Pas d’envoi de notification.
|
|
|
46 |
- **Non** → Notification envoyée.
|
|
|
47 |
|
|
|
48 |
### **A noter**
|
|
|
49 |
|
|
|
50 |
/!\ Pour que la tâche CRON soit opérationnelle, il faut lui laisser le temps de s’exécuter de façon à ce que le système puisse comparer la TRACE 1 à la TRACE 2.
|
|
|
51 |
|
|
|
52 |
Lorsqu’une restriction est ajoutée à une activité, il faut laisser le temps à la tâche CRON de s’exécuter afin de vérifier une première fois si les utilisateurs ont accès à l’activité (TRACE 1).
|
|
|
53 |
|
|
|
54 |
Si la restriction est levée immédiatement après avoir été ajoutée, la tâche CRON n’a pas le temps de s’exécuter à nouveau (TRACE 2). La levée de restriction n’est donc pas enregistrée dans la tâche et la notification ne peut pas être envoyée.
|
|
|
55 |
|
|
|
56 |
C’est un élément à prendre en compte lors des phases de test.
|
|
|
57 |
|
|
|
58 |
---
|