Pour mettre en place une mécanique de validation, j’ai besoin d’avoir dans la même vue des informations concaténées à partir de plusieurs objets.
J’ai paramétré un objet SELECT qui répond à mon besoin.
Cependant, j’ai besoin d’avoir pour chaque ligne des champs modifiables (notamment le statut de validation, et un commentaire de validation)
J’ai l’impression qu’aucune de ces deux solutions n’est faisable :
ajouter à mon objet SELECT des champs persistants
créer un objet persistant qui référencerait mon objet SELECT
Si cela n’est effectivement pas possible, auriez vous une autre piste pour répondre à mon besoin ?
Un objet “select” est fondamentalement une vue = un objet en read only
Pour mettre en place de la mise à jour, il faudrait à priori implémenter les mises à jour ad hoc sur les objets dans le pre/postSave de l’objet select. Mais ça semble quand même un peu étrange comme approche
PS: on peut référencer un objet select à partir du moment où on lui configure un attribut row ID custom pérenne.
Si je peux référencer l’objet SELECT ça répondra à mon besoin, j’ai essayé sans succès en utilisant le champ Id field logical name.
Il faut plutôt que je crée un attribut d’objet “row_id” ?
Oui ce que j’appelle “row ID custom” c’est le “Id field Logical name” défini au niveau de l’objet.
Il faut que cet attribut mappe sur une colonne (= la première du select) qui garantit, de manière pérenne dans le temps, l’unicité de chaque record récupéré lors de l’execution select (ça pourrait être, par exemple, un des row_id des tables en question si celui-ci garantit effectivement cette unicité du record select)
Pour info, en l’absence de cet attribut explicite un objet “select” génère à la volée de “faux” row ID (donc non pérennes) c’est pour cela que sans ce row ID custom pérenne il n’est pas possible de référencer un objet select.
Bon alors j’ai dû mal faire quelque chose car j’obtenais une tentative de jointure sur une table “select” de type “left outer join select on” avec une erreur. Je retente !
Vérification faite j’ai déjà lié des objets select à un objet normal (= l’objet select en onglet) mais effectivement je ne crois pas l’avoir fait dans l’autre sens (= un objet select référencé depuis un objet standard)
Il faudrait voir de près quelle est la requête générée…
Désolée, je n’arrive pas à paramétrer ce row id
Dès que je renseigne le champ Id field logical name, toutes mes colonnes sont décalées et j’ai un row_id généré à la volée et non celui que j’ai renseigné.
Oui j’étais en train de faire des tests de d’objet select + row ID custom sur la démo et ça ne semble pas faire ce que j’avais en tête. Je vais creuser ce point.
Je reste malgré tout assez dubitatif sur l’approche. Je veux dire l’usage d’un objet select (ou son usage de cette manière) n’est peut être la seule manière de répondre au besoin (ex: pour avoir “des informations concaténées à partir de plusieurs objets” des attributs calculés - non persistants - au niveau de l’objet parent répondraient peut-être au besoin)
D’accord merci j’attends ton retour pour le SELECT.
Pour l’approche j’ai bien conscience que ce n’est pas optimal, c’est un arrangement pour répondre à des besoins de différentes équipes dans un contexte assez complexe !
Le sujet des row ID custom sur les objets select est en haut de la pile mais n’a pas encore été dépilé.
En attendant, il faudrait sans doute explorer d’autres approches
Par contre, pour le moment, je n’arrive pas à référencer un objet select depuis un objet table (la syntaxe de la requête générée ne va pas). Je n’ai pas encore essayé dans l’autre sens.
Je reste de toute façon très dubitatif sur une approche utilisant des objets select qui fondamentalement ne sont pas fait pour “naviguer” entre objets mais plutôt pour produire des “rapports” et des “cubes” de données.
Je n’ai peu être pas compris le besoin mais je pense que des calculs dynamiques d’agrégats (à l’enregistrement ou à l’affichage) à tous les niveaux des objets métier concernés seraient peut être une meilleure approche.
Bref c’est peut être plus dans ce sens là qu’il faut mettre les choses en place (d’autant que ça fonctionne sans attendre l’évolution sur le row ID custom)
Merci beaucoup David pour ta rapidité car je sais que vous avez beaucoup à faire !
En effet je parviens déjà à référencer un objet TABLE depuis l’objet SELECT, mais pas l’inverse car comme tu l’as écrit la jointure se fait sur “select” et non les tables du select.
Pour le contexte, j’essaie de répondre par cette configuration aux exigences de deux équipes. J’ai mis en place une vue SELECT qui fait un UNION entre deux objets, et dont les utilisateurs ont besoin de valider les lignes. J’ai donc fait un objet TABLE validation (en écriture) avec un statut, qui référencerait les lignes de cette vue (en lecture seule).
J’ai retourné le problème dans tous les sens et je ne vois pas de solution idéale…
Ca pourrait permettre de mettre à jour le statut en effet, je n’y avais pas pensé. Peut-être avec un popup permettant au valideur de saisir son commentaire en cas de REJECT.
En revanche, j’aurais aimé ajouter la possibilité de valider champ par champ avec un champ yes/no à côté de chaque colonne. Les valideurs ont des milliers de lignes à traiter donc écrire à chaque fois le nom des champs qui ne sont pas ok sera un peu fastidieux. Aujourd’hui, ils font ce travail sur Excel en mettant en couleur les champs pas OK.
Oui je pense qu’on va abandonner la validation champ par champ pour l’instant, au profit d’une action “Business process” qui permettra de saisir un champ commentaire et mettre à jour le statut.
Merci pour cette piste !
Ce commentaire peut être simplement un attribut d’action (cf. la démo sur l’action d’incrément de stock sur le produit => un attribut demande la valeur du nb à incrémenter)
ou si je dois chercher autre chose !
