l’opération échoue suite à un doublon de clef sur l’object copié lié : om.simplicite.util.exceptions.ValidateException: ERR_USERKEY: STUDY-dev-998 0.00
alors que la copie via l’UI se déroule correctement. Y a t’il un moyen d’éviter ce doublon de clef engendré par une copie brutte de tous les champs sans repositionner de nouvelle clef sur la copie de l’objet liée ?
Frédéric
La dernière version est la 5.2.13 du 01/09/2022 et je vous invite à mettre à jour votre instance sur cette dernière version.
Je ne reproduis pas le problème. Quelle est la clé fonctionnelle de l’objet lié ? est ce que la clé technique vers l’objet parent est clé fonctionnelle ?
Est ce que les attributs sont copiables ?
Est ce qu’il y a une surcharge (un traitement) sur la clé fonctionnelle de l’objet lié ?
A quoi correspond STUDY-dev-998 0.00 ?
Oui les attributs sont copiables, il y a effectivement une surcharge sur la clé fonctionnelle de l’objet père, qui est composé de deux items : le nom d’un étude : STUDY-env-XXXXX et un numéro de version. Lors d’une copie nous créons un nouveau numéro d’étude par incrément d’un compteur interne et une version dite courante. L’objet lié correspond aux utilisateurs ayant accès à l’étude et aux droits qu’ils ont sur cette étude.
Je ne reproduis pas votre cas
Test effectué :
dans le preValidate : initialisation de la clé fonctionnelle à une valeur temporaire
dans le preCreate : setValue de la clé fonctionnelle
dans le code d’une action de liste
Bonjour
merci pour votre aide, je viens de trouver la solution grâce à vous, j’avais un bout de code dans le try qui faisait un erase de la clef fonctionnelle, j’ai déplacé cette init dans le prevalidate et je confirme les copies en cascade fonctionnent correctement.
Merci encore pour votre aide
Frédéric