Démarches

Pour :ParentÉlèveEnseignant Niveaux :1er degré2nd degré

Les Démarches (WorkflowHub) sont disponibles en natif dans l'application mobile, ouvertes depuis le lanceur « Mes apps » (famille Vie de l'établissement, comme sur le portail web).

Périmètre mobile assumé

Le mobile sert à remplir une démarche : lister celles qui sont ouvertes, saisir le formulaire et l'envoyer. Concevoir une démarche (constructeur de formulaire, workflow, diffusion, étiquettes) et suivre les dossiers reçus restent sur le portail web : ces écrans supposent une largeur d'écran et des droits d'administration que le mobile n'a pas vocation à reproduire.

Les démarches à remplir

L'écran liste les démarches ouvertes des établissements de l'utilisateur : intitulé, type (collecte d'informations, autorisation à accorder, inscription), année scolaire et étiquettes. Une démarche en brouillon ou fermée n'apparaît pas — c'est la même règle que le serveur applique en renvoyant workflowhub.campagne.fermee.

Démarches ouvertes de l'établissement

Le formulaire, rendu à partir de son schéma

Le formulaire n'est pas codé en dur dans l'application : il est rendu à partir du JSON Schema de la démarche et de son ui-schema, exactement comme sur le web (le même schéma sert d'ailleurs à la validation côté serveur). L'application mobile porte le même ordre de priorité de rendu :

Déclaration	Rendu mobile
ui:widget: hidden	rien — la valeur reste dans le dossier (identifiant prérempli par le carnet, paraphe posé par le serveur)
type: object	section encadrée, titre et description
type: array	liste répétable (Ajouter / Supprimer, bornes minItems/maxItems)
referentiel-select, referentiel-etablissement, annee-select, ville-from-cp	liste servie par le référentiel de l'ENT (classes, structures, villes d'un code postal…)
enum	choix parmi les valeurs
boolean / checkbox	interrupteur
integer, number	saisie numérique
format: date	saisie AAAA-MM-JJ
reste	saisie texte (clavier adapté pour un courriel)

ui:order fixe l'ordre des champs, ui:title et ui:help leurs libellés et aides.

Formulaire rendu depuis le JSON Schema de la démarche

Contrôle de saisie : champs obligatoires manquants

Parcours capturé en test e2e live — apps/mobile/e2e/lanceur/parcours-demarches.yaml (compte enseignant réel lilit.upreti001, démarche réelle Autorisation de sortie — Musée de Morlaix). Le test n'envoie pas la démarche : il s'arrête au contrôle de saisie, donc aucun dossier n'est créé.

Contrôle de saisie, RGPD et envoi

Avant l'envoi, l'application vérifie localement la saisie : champs obligatoires, formats courriel et date, longueurs, valeur minimale. Les erreurs sont listées avec le chemin lisible du champ fautif (« Responsables → #1 → Prénom : champ obligatoire »). C'est un confort, pas une autorité : le serveur revalide le dossier contre le JSON Schema au moment de l'envoi.

Quand la démarche porte un texte RGPD, il est affiché et l'envoi n'est possible qu'après en avoir pris connaissance.

L'envoi crée le brouillon puis le transmet ; la référence du dossier est affichée en confirmation, et l'accusé de réception habituel du module part côté serveur.

Données réelles

• Source : module workflowhub. GET /workflowhub/campagnes (démarches des établissements de l'utilisateur), puis les routes de saisie GET /workflowhub/pub/:token/schema, GET /workflowhub/pub/:token/referentiel/:source, POST /workflowhub/pub/:token/dossier, POST /workflowhub/pub/:token/dossier/:reference/piece-jointe (dépôt d'un justificatif), GET/DELETE sur …/pieces et …/piece-jointe/:id, puis POST /workflowhub/pub/:token/dossier/:reference/submit.
• Jeton public : ce sont les routes « publiques » du module qui portent le remplissage — le jeton de la démarche suffit, et la session ENT reste envoyée par le cookie natif.
• Visibilité pilotée par les droits : les Démarches n'apparaissent dans « Mes apps » que si l'instance les autorise à l'utilisateur.

Pièces justificatives

Un justificatif se dépose en le photographiant : l'application crée alors le brouillon du dossier — les pièces s'y rattachent, elles n'existent pas sans lui — puis téléverse le fichier (justificatif, 10 Mo maximum, comme sur le portail). Les pièces déposées sont listées et peuvent être retirées avant l'envoi.

À l'envoi, le brouillon déjà créé pour les pièces est mis à jour puis transmis : la démarche part avec une seule référence, ses pièces attachées.

Tests

• Jest : moteur de formulaire pur — résolution des $ref, ui:order, nature de chaque champ (dont un champ masqué prioritaire sur son type), valeurs initiales, validation (obligatoires, courriel, date, champs masqués ignorés), écriture immuable, filtrage des démarches remplissables et messages d'erreur du module ainsi que la normalisation des pièces déposées (apps/mobile/__tests__/demarches-schema.test.ts).
• e2e Maestro live : apps/mobile/e2e/lanceur/parcours-demarches.yaml (parent → « Mes apps » → Démarches → formulaire → contrôle de saisie). Le test n'envoie pas la démarche : il ne crée aucun dossier.

Droits requis

Les Démarches n'apparaissent dans « Mes apps » que si le rôle WorkflowHub - Lecture est accordé au profil de l'utilisateur (Dashboard → gestion des accès). Sur l'instance de recette, ce rôle n'était posé que pour les parents et les élèves — d'où une application invisible pour les enseignants et les personnels, alors que le module était bien déployé.