La synchronisation par DataLink ne considère pas les attributs d’objet configurés en lecture seule. Dans ma configuration, j’ai un master en 5.3.41 et un slave en 6.0.14. Je ne pense pas que ça puisse participer au problème mais je le précise au cas où ça aurait de l’importance.
Steps to reproduce
This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:
Master en v5.3 avec objet métier avec des attributs obligatoires (dont ceux de la clé fonctionnelle) et en lecture seule (valeur calculée).
Slave en v6.0.14 avec le même objet.
DataLink du slave vers le master configuré sur le slave.
Activer manuellement la synchronisation (date de référence 2001-01-01).
→ Dans les logs du slave qui fait tourner la tâche pullData on retrouve des erreurs de create précisant que les composantes de la clé fonctionnelle ne sont pas valorisés alors que sur le master les valeurs sont correctes.
Sur le slave, reconfigurer les attributs concernés en “Modifiable partout”.
Réactiver la synchronisation.
→ Les records sont bien créés sur le slave sans erreur.
Le sujet des droits de mise à jour par API ou UI est assez sensible, le droit de lecture est actuellement géré comme dans un appel d’API (/api ou /ui) : un champ en lecture n’est pas modifiable par définition
par http (mais par code, champ calculé en back…).
L’action de synchro (qui reste techniquement un PUT avec un paramètre _sync pour changer le comportement à la marge i.e. garder les mêmes row_id/timestamp) pourrait être plus permissive sur les données à créer/mettre à jour sur ce genre d’action de synchro “interne entre bases” mais ce serait une faille de sécurité.
Il faut donc utiliser/créer un user et/ou groupe de synchro avec des droits globaux de mise à jour sur les objets à synchroniser.
Simplicité ne doit pas donner “en dur” tous les droits à n’importe quel user sur un simple PUT avec un paramètre “_sync” (ou n’importe quelle autre mécanisme à distance, https n’étant qu’un tuyau).
Bonsoir François,
Oui je comprends et je me doutais qu’il y avait une contrainte/limitation de cet ordre. Le fait que des attributs soient “fermés” par défaut (en lecture seule dans le modèle) puis ouverts en modification selon les cas est-il en mauvais pattern ? Si j’avais opté pour l’inverse (modifiables par défaut puis forcés en lecture seule selon les cas - quasiment tous sauf la synchro datalink en fait), ça fonctionnerait.
Il faut considérer la synchro comme une interface ou un usage particulier.
L’usage UI ou via API est métier : ton pattern fermé par défaut est parfait
La synchro est d’un ordre technique : il faut un autre pattern “tout ouvert”
L’utilisateur (d’un groupe particulier) à utiliser pour la synchro doit donc avoir les objets entièrement modifiables (CRUD + attributs R/W).
La V6 apporte des permissions qui peuvent surcharger les attributs d’objets (obligatoire, modifiable…) par groupe, c’est propre mais ca va être fastidieux si tu en as bcp.
Sinon pour factoriser le code, si tes objets héritent tous d’un objet Java, mettre dans le postLoad global un code générique, du style :
// technical synchro = all rights
if (getGrant().hasResponsibility("MY_GROUP_SYNCHRO"))
for (ObjectField f : getFields())
f.setUpdatable(ObjectField.UPD_ALWAYS);
ou ajouter directement la règle dans tes codes métier qui changent les accès ouvert/fermé…