Envole » Envole-Mutualisé » eole-dispatcher

La plupart des problèmes viennent des ajouts lors des révisions ultérieures :

https://dev-eole.ac-dijon.fr/projects/eole-dispatcher/repository/changes/src/edispatcher-1.0/ng/Controllers/AppController.php?rev=master

52ca480a
e24f8df8
fcec679e

Que je n'avais pas testées en 2eme synchro...

Ces révisions sont censées permettre de détecter si une url trouvée peut être associée à une app automatiquement lors de la synchro ARENA

Mais c'est très problématique car il suffit qu'on ait modifié manuellement des choses (url sortie volontairement d'une app, création d'une nouvelle app non arena, etc...) pour que cet automatisme "casse" le travail manuel qui a été fait

Lors de la 1ere synchro, bien sur, aucun pb

Mais après modifs manuelles, et si on fait une 2eme synchro derrière, on constate que :

- une app créée manuellement se retrouve avec un ID arena alors qu'elle ne devrait pas en avoir

- une app peut se retrouver potentiellement avec des urls qui n'ont rien à y faire

- une app arena "vidée" mais conservée justement pour historique et éviter un nouveau chargement de la même app se retrouve re-remplie avec des urls qu'on avait soigneusement classées dans d'autres apps...

Bref la deuxième synchro ruine tout le travail manuel qui a pu être fait
Je propose de supprimer toutes ces détections automatiques pour conserver un principe simple : si un élément (app ou url) est déjà présent dans la base ON NE TOUCHE A RIEN, aucun modif, cela veut dire qu'elle a déjà été traitée (ou au moins importée et en attente de traitement manuel éventuel)
La synchro ne sert qu'à importer les urls/applis/catégories ARENA nouvellement créées

A la limite, pour le traitement des urls orphelines, on pourrait envisager un autre traitement (indépendant de la synchro ARENA) mais en général si on a des orphelines c'est qu'elles ont été volontairement retirées de l'app donc ce n'est pas pour les remettre automatiquement dans cette app

Dans AppController :
Tout le code situé après la ligne 750 (après le $bUpdateUrl = true; ) est problématique :
- il se situe après la fermeture du else donc il s'exécute pour toutes les urls (pas seulement les nouvelles)
- il réassigne la variable $app (qui est déjà assignée au sous domaine ARENA en cours de traitement) ce qui est dangereux car lors du prochain passage de la boucle cette variable ne sera plus assignée à ce sous domaine mais à cette nouvelle app
- Je suppose que le but était de profiter de la synchro ARENA pour réaliser des traitement automatisés sur les applis existantes dans la base, en leur affectant un arenaid si elles n'en avaient pas, en leur rattanchant automatiquement des urls orphelines (ce qui évitait d'avoir à les traiter à la main). Mais il s'avère que le remède est pire que le mal.
Dans les faits :
- La première synchro ARENA permet d'alimenter la base
- Ensuite un gros travail manuel est réalisé pour classer les urls dans des applications, ce qui implique :
- la création de nouvelles applis (qui ne sont donc pas ARENA)
- le rangement d'urls dans des applis différentes de leurs applis initiales
- le vidage intégral de certaines applis arena "fourre-tout" non satisfaisantes (notamment "Applications locales de...), mais leur conservation pour éviter de les réimporter la fois suivante. Ces applis ont 0 url et c'est normal

Le code incriminé, en comparant les urls importées d'arena aux applis exitantes et en leur appliquant un traitement automatisé en les réorganisant sur la base arena, détruisait une bonne partie de ce travail manuel

Je poste donc un correctif :
- qui supprime totalement la modif d'une app existante
- qui applique les réorgs automatiques uniquement aux nouvelles urls