Project

General

Profile

Anomalie #3926

l import AAF plante dans certains cas

Added by jean-francois bados over 7 years ago. Updated about 7 years ago.

Status:
Fermé
Priority:
Haut
Assigned To:
Category:
-
Start date:
08/23/2012
Due date:
% Done:

100%

Spent time:
Distribution:
EOLE 2.3

Description

Certains fichiers extraits de l AAF pour les personnels sont mal formés et plantent l importation .
ex dans un cas on a trouvé par deux fois pour deux profs la ligne suivante
<attr name="ENTPersonFonctions"><value>4931$-$SANS OBJET$-$SANS OBJET</value><value>4931$ENS$ENSEIGNEMENT$L1700$EDUCATION MUSICALE</value></attr>
si j enlève <value>4931$-$SANS OBJET$-$SANS OBJET</value> alors l importation AAF passe sans problème ...


Related issues

Duplicated by scribe-backend - Anomalie #4813: Importation AAF : pb création de groupes vides Fermé
Precedes scribe-backend - Anomalie #4698: Backport du correctif d'import AAF "SANS OBJET" en 2.2 Fermé 01/15/2013

Associated revisions

Revision 52a09283 (diff)
Added by Joël Cuissinat over 7 years ago

  • parsing/aaf.py : fonction "SANS OBJET" ignorée

Fixes #3926 @20m

History

#1 Updated by Joël Cuissinat over 7 years ago

  • Assigned To set to Joël Cuissinat
  • Target version set to Mises à jour 2.3.7 RC

#2 Updated by jean-francois bados over 7 years ago

J ai eu cette réponse de toulouse sur le présence de cette balise sans objet dans l extration :

Ces cas avec fonction et discipline "SANS OBJET" correspondent aux RAD.
Je rappelle une forte demande des académies pour avoir les RAD pour les PEN remplaçants. Demande validée en CSO fin 2011 et diffusée dans la version AAF-V1207. Voici un copier/coller de la doc de diffusion :
-----------------
Correction du problème de récupération des RAD
Scénario AAF_EPP
Signalements 0048921 de Strasbourg, 0052074 de Lyon, 0040048 de Nantes
La modalité RAD a été créée pour désigner l'établissement de gestion des TZR nommés sur zone. L'annuaire fédérateur doit récupérer une telle affectation RAD dans ce cas précis, à savoir : agent ayant une affectation RAD, une affectation SUP/REP et une affectation AFA/PRO sur ZR ou ZA. Mais de telles affectations RAD partaient en table d'erreurs car elles ne vérifient pas la clé primaire de la table FrEduRne, elles sont sans discipline.
Ce problème est corrigé : un traitement spécifique (999_INS_TMP_FONCTION_RAD_2) les récupère et les insère dans la table FrEduRne avec un code fonction spécial (ligne « tfc$-|tfc|-|SANS OBJET|SANS OBJET|SANS OBJET| » rajoutée dans les nomenclatures) et un code discipline spécial (ligne « tdi$-|tdi|-|SANS OBJET|SANS OBJET|SANS OBJET| » rajoutée dans les nomenclatures). Dans les exports vers les ENT (exports ENT et ENTTS), elles sont bien avec les autres affectations dans la balise ENTPersonFonction.
-------------------------------------
Les affectations RAD dans le cas de remplacements sont donc maintenant récupérées et exportées, et comme elles sont sans fonction ni discipline dans les bases de gestion, c'est idem dans AAF et idem dans l'export.

A priori cette présence serait donc normal( si j ai tout compris) il faudrait donc que le traitement de l import AAF ignore cette balise ...

Cordialement

#3 Updated by Joël Cuissinat over 7 years ago

  • Project changed from Scribe to scribe-backend

#4 Updated by Joël Cuissinat over 7 years ago

  • Status changed from Nouveau to Résolu
  • % Done changed from 0 to 100

#5 Updated by Bruno Boiget about 7 years ago

  • Status changed from Résolu to Fermé

modif présente sur 2.3.7 RC (à vérifier avec des fichiers réels)

Also available in: Atom PDF