Code source wiki de 03 - Règles de gestion

Modifié par Cédric Champmartin le 23/07/2024 - 15:15
Afficher les derniers auteurs
1
2
3 {{toc/}}
4
5 = Authentification et droits utilisateurs =
6
7 L'authentification se fait via le CAS de l'établissement.
8
9 Les droits proviennent d'Apogée. L'utilisateur doit disposer du droit d'édition dans Apogée pour les composantes qu'il gère dans l'application. Sans ce droit, aucune action n'est possible.
10
11 {{info}}
12 La récupération des droits se fait par une requête SQL.
13
14 A partir du type Apogée de l'utilisateur connecté, on recherche s'il dispose du traitement //TRAREF10// (Edition d'attestations de réussite) pour le domaine //RE// (Collecte et diffusion des résultats) et ce pour quelles composantes.
15
16 Tables utilisées : //UTILISATEUR//, //TYP_UTILISATEUR//, //TUT_AVOIR_DROIT_FCT//, //UTI_COLLECTER_CTN //et //COMPOSANTE//
17 {{/info}}
18
19 = Constitution d'une campagne de dématérialisation =
20
21 Pour générer des attestations de réussite au diplôme, il convient de sélectionner une année (parmi les années ouvertes dans Apogée), une composante (selon ses droits) et une version de diplôme (VDI).
22
23 Les version de diplômes proposées sont celles associées à la composante et identifiées comme terminales dans Apogée ou sans diplôme intermédiaire (comme par exemple les licences pro). Leur nature doit également être différente de "Absence de diplôme" (code 9, paramétrable dans l'application).
24
25 Les étudiants candidats à génération d'une attestation sont regroupés par versions d'étape (VET). Il s'agit des VET diplômantes de la VDI sélectionnée.
26
27 {{info}}
28 La récupération des VDI se fait via une requête SQL sur les tables (% style="color: rgb(0,0,0);" %)//VERSION_DIPLOME //et(%%) (% style="color: rgb(0,0,0);" %)//CMP_HABILITER_VDI//. Seules les VDI dont l'année de fin d'habilitation est supérieure ou égale à l'année demandée dans l'application sont considérées. Le libellé récupéré est //lib_web_vdi//.
29
30 (% style="color: rgb(0,0,0);" %)La récupération des VET se fait via le ws Apogée (% style="color: rgb(0, 0, 0); color: rgb(0, 0, 0)" %)//OffreFormation//, méthode //r//(% style="color: rgb(0,0,0);" %)//ecupererSE_v3()//. Ce ws est appelé avec les paramètres suivants :
31
32 * (% style="color: rgb(0,0,0);" %)code de l'année demandée
33 * (% style="color: rgb(0,0,0);" %)code et version du diplôme demandé
34
35 * (% style="color: rgb(0,0,0);" %)code et version d'étape ; tous
36 * (% style="color: rgb(0,0,0);" %)code élément pédagogique : aucun
37 * (% style="color: rgb(0,0,0);" %)témoin ouvert recrutement : null
38
39 (% style="color: rgb(0,0,0);" %)Parmi les VET résultats, seules les diplômantes sont prises en compte (requête SQL complémentaire sur la table //version_etape//, témoin //tem_dip_vet// à 'O')
40
41 (% style="color: rgb(0,0,0);" %)**Note** :
42
43 * (% style="color: rgb(0,0,0);" %)Nous travaillons au niveau VET car le ws Apogée //EtudiantMetier//, méthode //recupererListeEtudiants(), //permettant de récupérer les étudiants, l'impose. Il est appelé avec les paramètres suivants : code de l'année, code et version de diplôme, code et version d'étape
44 * (% style="color: rgb(0,0,0);letter-spacing: 0.0px;" %)Il est possible si nécessaire de relancer la génération des attestations. Cette relance ne prendra en compte que les étudiants pour lesquels l'envoi du mail ou le dépôt digiposte (selon la configuration de l'application) n'a pas été réalisé
45 {{/info}}
46
47 = Données administratives =
48
49 (% style="color: rgb(0,0,0);" %)Les ws Apogée ne permettent pas d'obtenir le libelle officiel d'un diplôme pour une VDI. Pour cela, nous utilisons les tables //PERIODE_PARAM_EDITION//, //PREFIXE_INT//, //VERSION_DIPLOME// et //PARCOURS_TYPE// (cf la requête SQL des reports Oracle) pour générer les attestations de réussite. Les 5 colonnes de libellés et le parcours type sont mis bout à bout, en terminant par le parcours type. Les virgules et la capitalisation sont conservées telles qu'elles sont dans Apogée.
50
51 (% style="color: rgb(0,0,0);" %)Les données des étudiants (prénom1, prénom2, nom, date de naissance, email...) sont récupérées via le ws Apogée //EtudiantMetier//, méthode //recupererIdentifiantsEtudiant()//.
52
53
54 (% style="color: rgb(0,0,0);" %)Les adresses mail des étudiant•es sont sujettes à expiration / modification. On admet qu'elles sont valides car elles sont maintenues à jour dans Apogée par synchronisation avec le LDAP.  Cela se fait via le package PKB_ANNU dans lequel chaque établissement peut indiquer la façon de récupérer cette info. Il est possible lors de la phase de test de vérifier les adresses qui seront destinataires en réel. Elles sont loggées en INFO lorsque l'application est en mode test.
55
56 = Résultats d'admission, mention et ECTS =
57
58 3 cas sont possibles pour le résultat d'admission :
59
60 * L'étudiant•e est reçu•e
61 * L'étudiant•e n' est pas reçu•e
62 * Pas de verdict (les résultats ne sont pas dans Apogée)
63
64 Pour le déterminer, nous récupérons la liste des contrats pédagogiques pour cet•te étudiant•e et l'année considérée. Nous filtrons cette liste par diplôme et VDI pour obtenir le contrat pédagogique qui nous intéresse. Nous avons alors autant de résultats qu'il y a de sessions (0 : session unique, session 1, session 2 : rattrapage). Ces résultats étant triés dans l'ordre des sessions, nous conservons la dernière. Si le résultat d'admission est positif et que la délivrance du diplôme est autorisée, nous récupérons la mention et les crédits ECTS au niveau de la VDI.
65
66 {{info}}
67 Les cas d'admission et de non-admission sont très variés (admis, ajourné, défaillant, démission etc.). Pour ne pas avoir à tous les gérer, nous utilisons le témoin //codNegTre// qui permet de savoir facilement si les résultats d'admissions sont favorables ou non:
68
69 * Si codNegTre == 1: étudiant•e reçu•e
70 * Si codNegTre == 0: étudiant•e non reçu•e
71 * Si null: pas de résultats
72
73 Il est récupéré via le ws Apogée //PedagogiqueMetier,// méthode //recupererContratPedagogiqueResultatVdiVet_v2() //appelé avec les paramètres suivants// : //code de l'étudiant, code de l'année, source "Apogée", état "délibération terminée", session à null, type de résultat à null, état de l'inscription à "En cours"
74
75 Les résultats sont alors filtrés sur //cod_adm// à 1 (Admission).
76
77 Pour être considéré comme admis, l'étudiant doit également avoir le témoin //tem_dlv_aut_vdi// à //O// pour au moins une session d'admission (table //RESULTAT_VDI //pour// cod_ind, cod_dip, cod_vrs_vdi, cod_anu et cod_adm//).
78 {{/info}}
79
80 = Blocages =
81
82 Il existe différents types de blocages :
83
84 * Blocage sur examens
85 * Blocage sur inscription administrative et/ou pédagogique
86 * Blocage sur inscription administrative à distance
87 * Blocage sur délivrance auto. diplôme
88
89 En cas de blocage, l'attestation n'est ni générée ni envoyée.
90
91 {{info}}
92 Les blocages sont récupérés via le ws Apogée //EtudiantMetier//, méthode //recupererInfosAdmEtuV2()//. Voir table apogée TYP_BLOCAGE
93 {{/info}}
94
95 = Signataire =
96
97 Le signataire apposé aux attestations est le Président de l'Université. Sa signature numérique est récupérée de la base Apogée.
98
99 {{info}}
100 La récupération du signataire se fait par une requête SQL.
101
102 Tables utilisées : //SIGNATAIRE// et //SIGN_TAMP_DIGITALISE//
103
104 **Note** : il n'y a pas de méthode pour trouver le code signataire du Président dans Apogée. Il faut donc le préciser dans le fichier //application.yaml// de l'application avec la clé pour déchiffrer le blob de la signature.
105 {{/info}}
106
107 = Mails =
108
109 Les mails suivant sont envoyés par l'application :
110
111 * Notification des créations de campagne lorsque le gestionnaire demande la génération d'attestations pour un diplôme
112 * Notification de fin de campagne pour le gestionnaire l'ayant lancé
113 * **Si l'envoi sur Digiposte est activé**, notification de l'étudiant lorsque son coffre est créé chez Digiposte
114 * **Si l'envoi par mail est activé**, envoi de l'attestation PDF à l'étudiant
115
116 = Process =
117
118 [[image:attach:hypercerts_schema.png||width="223"]]
119
120 = Digiposte =
121
122 Succession des étapes :
123
124 * Lors du processus de génération (cron), après le contrôle des blocages, l'application **envoi les demandes d'adhésions à Digiposte pour les étudiants** (sous forme d'un fichier zip déposé en sftp)
125 ** Les encours concernés sont alors **en attente d'ouverture des coffres**
126 * **A l'exécution suivante** du cron, **les coffres seront synchronisés** dans Hypercerts
127 ** Pour les étudiants synchronisés, l'application enverra **un mail pour les avertir de la création de leur coffre** Digiposte
128 ** L'application **génère les attestations** pdf et les dépose chez Digiposte (sous forme d'un fichier zip déposé en sftp)
129 * Après prise en compte du dépôt de l'attestation, **Digiposte enverra pour chaque étudiant une notification par mail et les étudiants pourront accéder à leur coffre**
130
131 Résiliation :
132
133 * Les étudiants peuvent demander la résiliation du service Digiposte après l'envoi du mail Hypercerts
134 ** Qui contient l'url de résiliation suivante : [[https:~~/~~/secure.digiposte.fr/acces_direct/UL/refus>>url:https://secure.digiposte.fr/acces_direct/UL/refus||shape="rect"]]
135 * Si un document est présent dans le coffre Digiposte, l'étudiant devra télécharger le document (et le supprimer) de son coffre pour engager la résiliation
136 * La synchronisation des coffres se chargera d'acquitter les demandes de résiliation pour que la suppression soit effective
137 * Une fois résilié, plus aucune création de coffre ne sera effectuée pour l'étudiant par Hypercerts
138
139 Délais :
140
141 * En prod, Digiposte conseille de limiter les envois d'adhésions et de routage à 1 par jour
142 ** Un étudiant avec admission aura donc son attestation sur un délai de 2 à 3 jours
143 * En test, le passage du cron peut être réduit, par exemple toutes les 10 minutes
144 ** Un étudiant avec admission devrait avoir son attestation sur un délai de 20/30 minutes
145
146 \\
147
148 \\