Attribut en double après changement d'ordre et Import/Export XML

4.0
Tags: #<Tag:0x00007f7d706e23b0>
Attribut en double après changement d'ordre et Import/Export XML
0

#1

Bonjour,

J’ai modifié l’ordre d’un attribut dans un objet et j’ai exporté le module en XML pour l’importer dans une autre instance sans impacter les datas à l’arrivée (et donc sans cloner).

L’attribut en question a été inséré à l’arrivée au lieu d’être modifié (ordre). Donc je le trouve donc maintenant en double.

Est-ce que c’est normal ? Est-ce que j’’aurai eu le même souci si j’étais passé par un pull/push un Git ?

Merci d’avance pour votre aide.
Abed.


(David AZOULAY) #2

Cela ne peut pas arriver si vous passez par les fonctions d’imports de module car en passant par là ça fera bien un diff/delta.

Si vous faites juste un simple import XML du paramétrage de votre module c’est du simple upsert et vous aurez des doublons (typiquement dans ce cas là)

Ma recommandation est bien entendu de vous servir de l’import/export de vos modules exclusivement via Git. Mais si, pour des raisons qui vous sont propres, vous voulez continuer à fonctionner à l’ancienne avec des exports/imports manuels XML ou ZIP, ça reste possible mais dans ces cas passez systématiquement par le module pour ces opérations


#3

J’en déduis de votre réponse que si j’utilise l’export/import Git, je n’aurai plus ce pb.

En attendant que j’ai les outils (GItHub privé) et les connaissances pour l’utiliser, je souhaite continuer à fonctionner avec un un Export/Import XML.

Ce que je faisais jusqu’à maintenant était toujours de faire un export du module avec “Exporter en XML” pour ensuite faire un simple “Import XML”.

Je viens de le refaire avec un import de module comme préconisé :

Mais je me retrouve toujours avec un doublon à l’arrivée. (même résultat qu’un simple “Import XML”.


(David AZOULAY) #4

Je ne vois pas ce que GitHub vient faire ici… Simplicité sait exposer ses modules sous forme de repo Git pas besoin d’un repo intermédiaire chez GitHub ou ailleurs. On peut très bien fonctionner via Git entre instances Simplicité sans aucun outil externe. Il n’y a vraiment aucune bonne raison de continuer à fonctionner avec des imports/exports manuels.

Pour le reste un import de module (quel que soit la manière dont on le fait) nécessite de regarder les logs, par exemple s’il y a une erreur, le mode diff/delta est - légitimement - inhibé.


#5

D’accord, je vais essayer d’utiliser le Git.
J’ai fait un commit. Pourriez-vous me dire svp comment procéder pour faire un pull dans cette instance et un push dans une autre instance ? je n’ai pas ces boutons sur l’écran Repository Git.

Quant à l’import XML, je n’ai pas d’erreur dans la log, c’est comme s’il considère que l’ordre de l’attribut fait partie de la clé, et donc, il insère un nouvel attribut d’objet.


(David AZOULAY) #6

Pour cloner le repo Git de votre module depuis une autre instance vous devez y créer le module en mettant les settings Git d’origine qui vont bien:

{
  "type": "git",
  "origin": {
    "uri": "http(s)://<instance host name>[/<instance app context root>]/git/<module name>",
    "username": "<I/O user's login>",
    "password": "<I/O user's password>"
  }
}

Cf. https://www.simplicite.io/resources/documentation/02-integration/git-repositories.md

Pour faciliter les pull suivants enregistrez les settings Git ci-dessus directement au niveau de votre répo d’origine.

En ce qui concerne votre pb d’attribut “en double”, s’il n’y a pas d’erreur à l’import du module cela ne peut pas arriver car l’import fait un delta et supprime donc ce qui n’est pas dans ce qui est importé.

Donc soit votre doublon existe à la source, soit il est dans votre cible dans un autre module, soit il y a des erreurs d’import que vous n’avez pas vu passer etc.


#7

J’ai paramétré le module source et cible avec :

{
	"type": "git",
	"origin": {
		"uri": "https://immo_dev_abed.e3m.simplicite.io/git/Immo",
		"username": "user",
		"password": "Le_mot_de_passe_de_user"
	}
}

J’ai fait un commit et un push à la source et pull à l’arrivée.
Le doublon est toujours là.

Voici l’objet à la source :
L’ordre était 15, je l’ai mis à 17.

J’ai sauvegardé et fait un push du module.

Voici l’objet cible Avant Pull :

Voici l’objet cible après pull :

On voit le doublon.

Effectivement, il y a des erreurs dans la log, mais elles ne concernent pas du tout l’objet en question (erreurs sur les logins):

ERROR [] Validation error: [ERR_REQUIRED:Utilisateur#ERROR#rsp_login_id]


(David AZOULAY) #8

Le fait de passer par Git ne résoudra pas tout seul votre problème d’import de module.

Vous devez analyser et surtout résoudre toutes les erreurs que vous rencontrez lors de l’import du module.

En effet comme je l’ai déjà expliqué précédemment, s’il y a une erreur (et peu importe sur quoi elle porte), l’import de module inhibera légitimement le mode diff/delta (et donc dans votre cas particulier, l’object field surabondant ne sera donc pas supprimé).


#9

Après résolution des erreurs, je confirme que le pb de doublon a été réglé. Merci encore.

Les erreurs venaient du chargement de l’objet Responsability :
Comment faire svp pour éviter d’avoir des erreurs concernant des users absents (on n’aura pas forcément les mêmes utilisateurs dans les instances source et cible) ?


(David AZOULAY) #10

Les “vrais” users et leur responsibilities n’ont rien à faire dans un module de paramétrage (destiné à être exporté/importé entre instances). Il faut les mettre dans un autre module réservé à cet usage (local à chaque instance)

Les seuls users/resps qui ont éventuellement du sens dans un module de paramétrage ce sont les resps des users de base (designer et/ou public) et les users “techniques” spécifiques (ex: utilisés pour de l’intégration etc.).