Distribution EOLE

Une première étude du code qui date d'il y a 5 ans met en valeur deux situations problématiques :

• Changement d'établissement depuis ou vers l'établissement racine (celui défini par la variable "numéro établissement")

Il n'y a pas de création spécifique pour l'établissement "racine" puisqu'il utilise les branches LDAP déjà existantes. Cependant, il n'a pas de groupe/partage LDAP associé contrairement aux autres établissements créés via l'EAD. L'ajout ou la création d'utilisateur au sein de cet établissement ne pose pas de problème particulier.
C'est lorsque que l'on souhaite y déplacer un élève déjà présents dans un autre établissement (ex : passage de 3e en 2de => ERROR Groupe 0240021t inconnu) ou qu'un élève quitte l'établissement (?) que ça pose problème.

• interdire l'utilisation de l'établissement "racine" : quid des serveurs déjà en production ?
• création "manuelle" du groupe établissement manquant : semble résoudre les problèmes d'après nos premiers tests
• Importation d'un établissement en ré-utilisant le préfixe des classes d'un autres établissement

L'erreur peut arriver très rapidement puisque le préfixe est pré-rempli avec celui de l'importation précédente !
Si un utilisateur est affecté à une classe qui existe déjà avec ce préfixe, le programme va essayer de modifier l'élève en se basant sur l'établissement associé à cette classe pour le retrouver et il ne le trouve pas (ERROR {'matched': 'ou=local,ou=eleves,ou=utilisateurs,ou=clgxxx,ou=ac-bordeaux,ou=education,o=gouv,c=fr', 'desc': 'No such object'}.

• une nouvelle importation avec le "bon" préfixe semble rétablir la situation
• faire évoluer le code... Idéalement en enregistrant le préfixe associé à l'établissement dans l'annuaire... Une première mise en garde serait de ne plus pré-remplir et rendre obligatoire le champ afin d'attirer l'attention.

Réponse "officielle" postée sur la liste : https://pcll.ac-dijon.fr/listes/arc/scribe/2017-10/msg00028.html