Compte avec ESCOUAI de rattachement hors périmètre

[plegay]

Bonjour,

J'ai un compte qui appartient à 16 établissements, dont celui d'uai = 0370888P (dans GRR),
son ESCOUUAICourant et de rattachement vaut 0371305T
qui n'est pas dans le périmètre grr.

isMemberOf contient entre autre:
esco:Applications:GRR:D ARSONVAL_0370888P

ce compte n'est mise a jour sur aucun établissement du périmètre GRR.
notamment pas sur 0370888P:
`
select * from grr_etablissement where code = '0370888P';
+----+----------+--------------------------------+----------------------------------------+------------+---------------------+----------------------+
| id | code | shortname | name | codepostal | adresse | ville |
+----+----------+--------------------------------+----------------------------------------+------------+---------------------+----------------------+
| 96 | 0370888P | LP LYC METIER-D ARSONVAL-ac-OR | LP LYC METIER-D ARSONVAL-ac-ORL._TOURS | 37305 | 6 PLACE DE LA MARNE | JOUE LES TOURS CEDEX |
+----+----------+--------------------------------+----------------------------------------+------------+---------------------+----------------------+
select * from grr_j_user_etablissement where login = 'F18405ud';
Empty set (0,00 sec)

J'ai lancé la synchro que pour ce compte avec:
filter.ldap.people=(&(uid=F18405ud)(|(isMemberOf=:GRR:)(isMemberOf=:admin:GRR:central)(isMemberOf=:admin:GRR:local:*)))
`
voici la patie du log concernée:

`

2019-05-15 14:53:10,996 [INFO ] f.r.g.b.l.ExecutionListenerStep - -------------------------------------
2019-05-15 14:53:10,997 [INFO ] f.r.g.b.l.ExecutionListenerStep - Execution de l'etape misAjourPersonnes
2019-05-15 14:53:11,002 [INFO ] f.r.g.b.p.ProcessorMisAJourPersonne - Debut Process pour l'utilisateur : F18405ud
2019-05-15 14:53:11,021 [INFO ] f.r.g.b.p.ProcessorMisAJourPersonne - Création de l'utilisateur
2019-05-15 14:53:11,043 [ERROR] f.r.g.b.config.BatchSyncroException - Le code etablissement detecté pour l'utilisateur F18405ud est introuvable en base - Code : 0371305T
2019-05-15 14:53:11,047 [INFO ] f.r.g.b.w.WriterMisAjourPersonne - Debut du Writer MisAjourPersonne
2019-05-15 14:53:11,059 [INFO ] f.r.g.b.l.ExecutionListenerStep - Nombre de lecture : 1
2019-05-15 14:53:11,060 [INFO ] f.r.g.b.l.ExecutionListenerStep - Nombre d'ecriture : 0
2019-05-15 14:53:11,060 [INFO ] f.r.g.b.l.ExecutionListenerStep - Nombre de skip : 1
2019-05-15 14:53:11,060 [INFO ] f.r.g.b.l.ExecutionListenerStep - Status de l'etape : COMPLETED
2019-05-15 14:53:11,101 [INFO ] f.r.g.b.l.ExecutionListenerStep - -------------------------------------
`
L'appartenance a un établissement pour GRR doit être déduit des groupes (isMemberOf) concernant GRR. Ce compte devrait donc apparaitre dans une dizaine d'établissement.

[GFI-ORLEANS]

Bonjour,
L'utilisateur est skip pour cause de son "default_etablissement" qui est introuvable en base :
Le code etablissement detecté pour l'utilisateur F18405ud est introuvable en base - Code : 0371305T
La colonne "default_etablissement" etant NOTNULL en base cette donnée est obligatoire.

Le traitement de cet établissement ne peut donc continuer.

RG-4 Etablissement principal de l’utilisateur
La valeur de la colonne default_etablissement correspond à la valeur de la colonne « id » de l’enregistrement de la table « etablissement » dont la colonne code est égale à :
• Le groupe (les caractères entre le dernier symbole « : » et la fin de chaîne) de l’expression régulière ^coll:Applications:GRR:([^:]+)$ si l’attribut isMemberOf vérifie cette expression régulière
• l’attribut ESCOUAIRattachemnent de l’entrée LDAP de l’utilisateur si la condition précédente n’est pas remplie

[plegay]

La meilleure solution pour nous serait de changer cette règle (RG-4).
Et définir 'default_etablissement' de la façon suivante :

Prendre ESCOUAIRattachement s'il existe et le code existe dans grr_etablissement.
Sinon prendre ESCOUAICourant s'il existe et le code existe dans grr_etablissement.
Sinon se baser sur le groupe 1 de la regex suivante:
"^[^:]+:Applications:GRR:(?:[^:_]+_)?([^:_]+)$"

La moins bonne solution pour nous serait de seulement changer la regex de la règle par celle citée ci-dessus. Dans ce cas la définition de l'établissement par défaut devient un peu aléatoire.

[plegay]

Je redonne la regex car elle est mal passée dans l'éditeur.
^[^:]+:Applications:GRR:(?:[^:_]+_)?([^:_]+)$

[GFI-ORLEANS]

Bonjour,
Si je récapitule :

1. Le groupe (les caractères entre le dernier symbole « : » et la fin de chaîne) de l’expression régulière ^coll:Applications:GRR:([^:]+)$ si l’attribut isMemberOf vérifie cette expression régulière
2. l’attribut ESCOUAIRattachemnent de l’entrée LDAP de l’utilisateur si la condition précédente n’est pas remplie
3. prendre ESCOUAICourant s'il existe et le code existe dans grr_etablissement
4. se baser sur le groupe 1 de la regex suivante: ^[^:]+:Applications:GRR:(?:[^:]+)?([^:_]+)$

Validez vous ce fonctionnement ?

[plegay]

En fait j'avais pensé que le règle 1 n'était plus utile; la regex de la 4 donne le même resutat pour les groupes coll:... .
Si ça vous pose une difficulté de supprimer la règle 1, on peut la garder mais dans ce cas il faut externaliser la regex 4 pour que l'on puisse la modifier facilement.

Attention l'éditeur de github efface certain _ dans la regex.

[GFI-ORLEANS]

C’était surtout pour l'ordre de fonctionnement que je voulais la laisser.
J'ai fait la modification en gardant la règle 1. Je peux toujours la supprimer s’il faut.
Par contre, la nouvelle regex sera exécutée seulement si les autres règles sont non remplies.

[GFI-ORLEANS]

[plegay]

Ok c'est bien comme cela.
De toute manière on peut faire en sorte que la regex 1 échoue toujours si on veux changer le fonctionnement.

Merci