Quelles données sont nécessaires au bon fonctionnement des applications AppScho ?

C’est un article technique que nous vous proposons cette semaine sur notre blog. Nous y listons les données pouvant être fournies par l’ERP d’un établissement et permettant le bon fonctionnement de nos applications. Cette liste est donc susceptible d’être complétée en fonction du besoin.

Veuillez noter que, pour chaque élément renvoyé par vos systèmes d’information, il est nécessaire de fournir un ID unique afin de permettre à AppScho d’identifier correctement les modifications.

Nous rappelons également que le respect de la vie privée est une des valeurs essentielles d’AppScho. Aucune des données personnelles mentionnées ici n’est stockée chez nous.

C’est parti pour ce tour d’horizon des données minimales nécessaires au bon fonctionnement de nos applications ! 👇

🔓 Authentification utilisateurs

Deux possibilités s’offrent à nous ici :

• Utiliser un système d’authentification géré par l’outil établissement : ici, l’utilisateur concerné est intrinsèquement identifié par le token d’authentification généré et fourni par l’outil établissement.
• Authentifier l’utilisateur côté AppScho et faire en sorte que l’outil établissement fasse confiance aux requêtes faites par AppScho. Dans ce cas, les requêtes à l’API contiennent l’identifiant de l’utilisateur concerné en paramètre.

ℹ️ Informations utilisateurs

Une fois l’utilisateur connecté, nous avons la possibilité de récupérer des informations sur sa personne et son profil au sein de l’établissement. Les données essentielles sont le prénom et le nom. La photo peut également être utilisée si l’établissement est en mesure de la fournir. 

D’autres données annexes et / ou composites peuvent être fournies dans cette réponse, comme par exemple le programme d’inscription, la promotion, le nombre de crédits ECTS obtenus, une liste de groupes dont l’étudiant fait partie. Cette liste de groupes est utilisée par les systèmes de push d’iOS et Android, de ce fait, ils doivent rester des ID simples (lettre, chiffres, et tirets).

🧑‍🤝‍🧑 Groupes

En plus des groupes renvoyés à travers les informations utilisateurs (voir ci-dessus), il est nécessaire de nous fournir la liste intégrale des groupes disponibles (afin de les afficher aux administrateurs de la plateforme My AppScho). Ces groupes doivent posséder un nom commun ainsi qu’un ID (qui est celui renvoyé pour l’utilisateur). 

🖍️ Résultats d’examens

Ici, nous devons récupérer une liste d’examens, possédant les attributs propres à ceux-ci, par exemple : le nom de la matière, la date, la note obtenue et le nombre de crédits ECTS en jeu. 

Ces examens peuvent être organisés en une hiérarchie permettant le classement en années, semestres, groupes, etc. Nous nous adaptons à votre modèle académique, quel que soit votre mode de fonctionnement (trimestre ou semestre par exemple). Nous recommandons cependant de limiter au maximum la profondeur hiérarchique, afin d’optimiser l’usage sur mobile (par exemple Année > Semestre > Matière > Examen).

📅 Emploi du temps

Une simple liste d’événements comprenant, au minimum, les informations suivantes : un ID unique pour l’événement, le nom de l’événement, la date et heure de début, la date et heure de fin.

L’ID unique à renvoyer avec l’événement nous est utile afin de déterminer si un événement a été modifié (nous comparons les champs pour les événements possédant le même ID). Il est donc important que cet ID ne change pas lorsqu’un événement est modifié.

Le format pour les dates renvoyées importe peu tant que celui-ci est précis (avec fuseau horaire).

Chaque événement peut aussi, si disponibles, inclure les informations suivantes : le nom de la salle où se situe l’événement, le nom du professeur, une description plus complète de l’événement ou un lien vers une plateforme LMS. A présent, vous pouvez également intégrer les liens visios des cours pour permettre aux étudiants de rejoindre l’événement directement depuis leur smartphone.

⚠️ Alertes personnalisées

Nous récupérons ici une liste d’alertes. Chaque alerte possède un ID unique, un titre ainsi qu’une description. Elles seront affichées directement sur le tableau de bord de l’application.

🙅‍♂️ Absences

Une liste d’absences comprenant, au minimum, les données suivantes : le nom du cours concerné, la date et l’heure de l’absence, un booléen indiquant si l’absence est justifiée ou non

Optionnellement, une absence peut aussi contenir sa justification si elle est disponible.

📕 Annuaire

L’annuaire peut avoir une ou deux interfaces différentes.

L’interface indispensable concerne la recherche. Un paramètre fournit la chaîne de caractères recherchée, encodée pour être connue dans une URL (et donc pouvant contenir des espaces). Par exemple : /directory/search?term=antoine%20 popineau .

Votre service ou API doit au minimum nous renvoyer un ID unique pour la personne ainsi que son nom, et peut agrémenter son retour avec des informations plus détaillées concernant la personne, comme un ou plusieurs numéros de téléphone ou adresses email, un nom de bureau, une photo, et autres…

📄 Documents

La liste de documents doit être organisée de manière similaire aux notes, à savoir une hiérarchie de descripteurs de documents, qui sera répliquée dans l’application de l’utilisateur.

Chaque niveau peut contenir des enfants (dans ce cas, le niveau en question est un dossier). Si un nœud de l’arbre ne contient aucun enfant, il s’agit d’un document et doit donc contenir des informations supplémentaires décrivant le document en question. 

Un point important est à noter : le document doit être téléchargeable à travers HTTPS directement par le terminal mobile, cela signifie deux choses : celui-ci est accessible publiquement, sans authentification, ou bien il peut être authentifié directement à travers des paramètres fournis dans l’URL du document.

Il est possible d’indiquer, à travers un attribut spécifique, le nom que doit avoir le fichier une fois téléchargé, dans la mesure du possible.

💰 Paiements

La fonctionnalité Paiements affiche deux types d’informations : une liste de “situations” permettant d’afficher au moins un solde, une liste de paiements et leurs états respectifs.

Ces informations peuvent être renvoyées dans un seul appel ou deux appels différents, en fonction de ce qui est plus pratique côté établissement.

Un élément de situation doit contenir les éléments suivants : ID unique, titre, description, solde (positif ou négatif).

Un élément de paiement doit contenir les éléments suivants : ID unique, titre, description, montant, booléen indiquant si le paiement a été réalisé, booléen indiquant si le paiement a échoué et la date de paiement. 

☑️ Si vous souhaitez en savoir plus sur le fonctionnement de nos applications, vous pouvez consulter notre documentation technique ou échanger directement avec un membre de notre équipe commerciale qui vous expliquera tout sur le sujet !