Problème de connexion d'un demandeur

[fabgoetz]

Bonjour Manuel,

Nous continuons la mise en service d'Oasis en test et pré-prod.

Nous avons essayons de nous connecter avec un étudiant "test" issu d'Apogée. L'authentification CAS fonctionne, et une nouvelle ligne est créée dans la table des utilisateurs avec le ROLE_USER, mais l'application affiche le message : "Vous ne possédez par de rôle valide pour vous connecter".

Si je me connecte en tant qu'administrateur et que j'ajoute l'étudiant dans la liste des bénéficiaires, il reçoit le ROLE_BENEFICIAIRE. Après, l'étudiant peut se connecter, mais il accède directement au planning, sans passer par le formulaire "Demandeur".

Si nous avons bien lu la documentation, l'étudiant devrait pouvoir se connecter sans l'intervention d'un gestionnaire/administrateur et accéder au formulaire. Est-ce qu'on a loupé quelque-chose dans le paramétrage de l'application ?

Merci pour votre aide et bonne journée !

Fabien

[mrossard]

Bonjour,

Il faudrait pour accéder à la partie "demandes" qu'il ait le role ROLE_DEMANDEUR. Pour cela il faut qu'il ait:

• un numéro étudiant
• soit une demande en cours, soit une inscription en cours.

[fabgoetz]

Notre étudiant de test est inscrit pour l'année en cours, mais son cod_etu n'est pas récupéré. Quand je le rajoute manuellement dans la bdd, j'arrive bien sur le formulaire de demande.

Je me demande si le soucis ne vient pas de notre LDAP. Le champ supannetuid a été modifié récemment. Il ne renvoi plus le cod_ind, mais le cod_etu.

Peut-être faudrait-il que je modifie le fichier backend/src/Service/LdapService.php ?

Qu'en pensez-vous ?

[mrossard]

Le champ attendu est bien supannetuid par défaut, vous pouvez le configurer via la variable d'environnement LDAP_CHAMP_ETU_ID.

[fabgoetz]

J'ai mis supannetuid dans la variable d'environnement LDAP_CHAMP_ETU_ID (le champ supanneEtuId renvoyant le numéro d'étudiant).

Et dans la requête apogee_get_inscriptions.sql, j'ai comme condition :
where i.cod_etu = :codEtu

Mais visiblement, il y a un soucis avec les données qui sont pas récupérées (soit du LDAP, soit d'Apogée).

Est-ce qu'il y a un moyen de voir ce qui est récupéré ? En PHP, c'est facile de faire un var_dump, mais dans un container, je ne sais pas comment faire.

Et entre chaque test, il faut une bonne vingtaine de minutes le temps de supprimer et regénérer les images Docker, c'est très long...

Bonne fin de journée !

[mrossard]

Pour éviter de re-générer les images docker à chaque fois pour une simple modification de code, en local vous pouvez simplement démarrer l'image en montant votre répertoire local sur le /app du conteneur, avec une commande de ce style (c'est ce que je fais au quotidien pour développer) :
docker run -v $PWD:/app --name oasis-backend oasis-backend .
Vous aurez ainsi au pire à relancer le conteneur lors des modifications (dépendant de l'image utilisée - une image de production avec frankenphp en mode worker nécessitera un redémarrage, mais pas une version de "développement" sans mode worker ou avec un watcher activé).

Pour le problème à proprement parler, le cheminement dans l'appli est le suivant :

• le front déclenche l'authentification sur le serveur oauth et obtient un accesstoken
• il demande un token au back, en fournissant cet accesstoken
• le back utilise cet accesstoken pour demander qui est connecté au serveur oauth, obtient en retour son uid
• A partir de cet uid :
  • soit il le connait déjà, auquel cas il récupère les données en base. Si en base il avait un numéro étudiant et aucune inscription en cours, il recherche des infos à jour depuis le SI de scolarité
  • soit il ne le connait pas, auquel cas il le crée avec les infos qu'il va récupérer dans le LDAP puis dans le SI de scolarité (s'il a un numéro étudiant)

Une possibilité que je vois pour votre cas serait que l'étudiant existait en base mais sans numéro, auquel cas ça ne re-déclenche pas automatiquement une recherche ldap pour re-vérifier s'il y en a maintenant un. C'est un cas très rare mais qu'on a eu très récemment et qui n'est pas encore adressé, de quelqu'un qui serait connu dans l'appli en tant que personnel, et qui devient étudiant.
Est-ce que ça correspondrait à votre test? Est-ce que vous pouvez tester avec un étudiant non présent dans votre table utilisateur pour vérifier si ça fonctionne alors comme attendu?

[fabgoetz]

Bonjour,

Merci pour ces précisions, je vais essayer. Même si ça aurait été plus simple de tester sans Docker.

Pour ce qui est de notre étudiant de test, c'est un étudiant qui est véritablement inscrit dans Apogée, mais sur une formation non diplômante. Ce qui permet d'avoir un compte dans l'annuaire LDAP et une boîte mail et de pouvoir utiliser ce compte pour nos tests.

Jusque-là, j'ai toujours le même résultat, il est créé dans la table des utilisateurs, mais sans son numéro d'étudiant, qui existe pourtant dans le LDAP. Ce qui fait qu'il n'est pas reconnu.

Je vais continuer de chercher...

Bon après-midi !

[fabgoetz]

Bonjour,

Juste une question : la vue "apogee.extern_niveau_etape" est censée renvoyer quelle information (car elle n'existe pas dans Apogée) ?

Ou est-il possible d'avoir la requête pour la générer ?

Merci et bonne journée !

Fabien GOETZ

[mrossard]

Bonjour,

Comme indiqué rapidement dans la doc c'est une table locale qui dépend fortement de notre organisation, donc non généralisable. Le "niveau" attendu dans la requête est une simple chaîne de caractères (typiquement L1, L2, L3, M1, M2...), mais peut être laissé vide.

[fabgoetz]

Bonjour,

Du coup, j'ai modifié la requête pour rajouter le niveau (L1, L2...).

Mais la requête ne fonctionne pas dans tous les cas. Notre étudiant de test est bien remonté avec sa formation dans Oasis, mais avec un autre étudiant, impossible de récupérer sa formation dans Oasis.

Pourtant, avec Dbeaver, je récupère bien l'inscription de chacun de ces 2 étudiants.

C'est vraiment très bizarre...

Je vous mets la requête que j'ai modifié, au cas où je me serai trompé quelque part :

select iae.cod_anu,
       vet.cod_etp,
       vet.cod_vrs_vet,
       vet.lib_web_vet,
       cmp.cod_cmp,
       cmp.lib_cmp,
       to_char(i.date_nai_ind, 'YYYY-MM-DD') as date_nai_ind,
       i.cod_sex_etu,
       case
           when annuelle.num_tel_port is not null then trim(annuelle.num_tel_port)
           when fixe.num_tel_port is not null then trim(fixe.num_tel_port)
           when annuelle.num_tel is not null then trim(annuelle.num_tel)
           else trim(fixe.num_tel)
           end                               as num_tel,
       iaa.tem_brs_iaa,
       rgi.lib_rgi,
       dip.lib_dip,
       etp.cod_cur||etp.cod_cyc as niveau,
       dsi.lib_dsi
from ins_adm_etp iae
         join diplome dip on dip.cod_dip = iae.cod_dip
         left outer join sec_dis_sis sds on sds.cod_sds = dip.cod_sds
         left outer join discipline_sis dsi on dsi.cod_dsi = sds.cod_dsi
         join individu i on i.cod_ind = iae.cod_ind
         join ins_adm_anu iaa on iaa.cod_ind = i.cod_ind and iaa.cod_anu = iae.cod_anu and iaa.eta_iaa = 'E'
         join regime_ins rgi on rgi.cod_rgi = iaa.cod_rgi
         join composante cmp on cmp.cod_cmp = iae.cod_cmp
         join version_etape vet on vet.cod_etp = iae.cod_etp and vet.cod_vrs_vet = iae.cod_vrs_vet
         left outer join etape etp on etp.cod_etp = vet.cod_etp
         left outer join adresse fixe on fixe.cod_ind = i.cod_ind
         left outer join adresse annuelle on annuelle.cod_ind_ina = i.cod_ind and annuelle.cod_anu_ina = iae.cod_anu
where i.cod_etu in (22505555,21204444)
  and iae.cod_anu between 2025 and 2026
  and iae.tem_iae_prm = 'O'
  and iae.eta_iae = 'E'
order by iae.cod_anu;

Bon après-midi !

Fabien GOETZ

[fabgoetz]

Bonjour Manuel,

J'ai trouvé ce qui n'allait pas !

Dans le fichier .env du backend, j'ai mis comme paramètre LDAP_CHAMP_ETU_ID='supannEtuId'.
Apparemment, ce paramètre doit impérativement être écrit en minuscule (supannetuid).
Maintenant, on arrive à se connecter en tant qu'étudiant ou à créer des bénéficiaires.

En revanche, on ne récupère pas l'adresse mail perso des étudiants. Comment fait-on ?

Bonne journée !

Fabien

[fabgoetz]

Après quelques tests, j'ai constaté que c'est l'étudiant qui doit saisir son mail perso. Le gestionnaire ne peut pas le saisir/modifier.

Il reste juste ce problème de cache sur certains écrans de l'application.

Bonne journée !

Fabien

[mrossard]

Sauf erreur de ma part, le mail perso est également récupéré depuis les demandes s'il est présent.

Je suis toujours en cours d'analyse pour les soucis de cache, j'essaye de trouver le temps d'aller au bout!