Demande de retour d’expérience
Nous avons besoin de mettre en place un mécanisme assez complet de validation de nos données en champ par champ. L’idée étant de permettre à diverses équipes d’avoir une vue spécifique des champs d’un objet Application, et de les valider un par un.
Une simple vue spécifique de l’Application avec workflow ne suffit pas car les Valideurs souhaitent pouvoir cocher Ok/pas OK champ par champ et non pour l’Application entière (ils ont énormément de data à valider et ne peuvent se permettre d’écrire pour chaque ligne, le nom des valeurs qui ne sont pas correctes).
J’ai pour l’instant paramétré :
un objet Equipe
un objet Validation line qui est une NN entre Equipe et Application
Ensuite je voudrais que chaque équipe puisse choisir la liste des champs qu’elle veut pouvoir valider.
Mais je peine à trouver une bonne solution. J’ai besoin d’une sorte de metaObjet qui listerait l’ensemble des champs de mes Applications et de leurs objets liés (des Déploiements, des Flux, etc.)
J’ai créé un objet Champ hérité de m_objfield avec un filtre sur les champs de mon module.
Ensuite je compte faire une NN entre Champ et Validation line, avec mon boolean qui permettra au Valideur de rapidement accepter ou refuser chaque valeur.
Mes questions sont les suivantes :
suis en train de réinventer l’eau chaude, existe-t-il déjà un mécanisme dans le socle permettant de faire de la validation champ par champ ?
si non, existe-t-il une bonne pratique pour mettre en place mon besoin ?
enfin, question technique “bonus” : je me retrouve bêtement avec dans mon objet Champ, les noms logiques de mes ObjetField alors que je souhaite avoir les traductions, comme on le voit en liste ou en formulaire. Y a-t-il une solution simple ou dois-je aller chercher par expression calculée la traduction dans une nouvelle colonne ?
Un grand merci d’avance pour vos conseils
Emmanuelle
Non, les logiques de validation s’implémentent au niveau de l’objet et non au niveau du champ.
Pas vraiment, dans tous les cas on parle d’un mécanisme sur mesure.
pour ce modèle ce serait effectivement l’approche préférable
Les réponses étant données, je vais me permettre de m’exprimer sur le modèle. Personnellement, je serais parti sur une approche plus statique et aurais:
créé un champ booléen avec un nommage prédictible pour chaque champ de l’objet application (quitte à le faire par import XML s’il y a beaucoup de champs; éventuellement en dynamique dans le postLoad avec sauvegarde dans un champ caché mais cela pose la question du placement dans le template)
créé une “page de configuration” (via objet externe par exmple) spécifique permettant de configurer l’association champ-équipe pour sauvegarde dans un paramètre système
géré la modifiabilité de chaque booléen dans le postLoad de “Application”
En effet:
le modèle est bien plus simple à comprendre et à maintenir
d’expérience les héritages de méta-modèle, bien qu’intéressants et esthétiques sur le papier, sont source d’ennuis sur le long terme
en termes d’UX, je soupçonne que les utilisateurs apprécieront d’avoir la case de validation de la donnée aux côtés de la donnée à valider plutôt que dans un panel paginé
Merci beaucoup pour cette réponse détaillée et pour les conseils.
En effet ça serait intéressant d’avoir le booléen à côté du champ à valider, mais il peut arriver que deux équipes doivent valider un même champ (il faut dans ce cas les OK de toutes les équipes avec si nécessaire un échange, je pensais peut-être dans un champ bloc note ou via la fonctionnalité “Social”)
Je vais rediscuter avec mon équipe de cette solution !
Le champ bloc note possède en V5 un rendering sous forme d’activité avec “checkbox + tchat”, un peu comme dans Trello. Très utile pour gérer du flux d’action non modélisée / de l’information informelle (persistée dans un JSON en base).
De mon point de vue, il faut voir la validation de l’information (d’un record) comme une étape dans un diagramme d’état ou un simple ENUM : En cours de saisie > A valider > Validé | Rejeté + champ motif (via onglet ad hoc avec qui quand quoi…) / des statuts facilement classables / des rejets affectés à un groupe/entité pour corriger/completer.
Le faire “champ par champ” semble un peu lourd à mettre en place surtout si N personnes peuvent faire N retours à N dates… Sinon il me parait plus malin de grouper les données “par entité qui valide” et gérer un statut par block de données si ça ne peut pas être global par record.
Bref la validation doit rester simple au niveau de l’objet (bloc note, enum pour trier les ok/ko…) quitte à avoir une table des actions à faire (une NN des “groupes/entités” assignées à des lignes en rejet = attribut de type “Objet” pour pointer sur n’importe quelle ligne du modèle)
J’aime bien l’idée d’un enum pour trier les champs, je vais y réfléchir.
Pour expliquer le contexte, il y a chez nous des campagnes d’audit deux fois par an qui nécessitent pour plusieurs équipes de valider plus d’un millier de lignes qui comportent une vingtaine de champs.
Jusqu’ici c’était fait sur Excel avec les problèmes qu’on peut imaginer, mais un des intérêts était que la personne en charge de validation pouvait simplement surligner les champs KO et renvoyer le fichier aux personnes concernées.
L’idée de devoir écrire pour chacune de ces lignes la liste des champs KO ne lui paraît pas faisable.
Je cherche donc une solution plus ergonomique.
J’ai déjà créé une ligne de validation par équipe concernée avec son propre statut ; l’application sera validée quand toutes les équipes auront validé leur ligne.
Maintenant il me reste à régler la question de répartir les champs à valider et proposer un workflow pas trop lourd.
