Charger/Afficher un bouton d'action lorsque j'ouvre le formulaire

Bonjour,

Le cas aujourd’hui, j’ai créé un bouton action, mais il s’affiche dés que j’enregistre mes données. Il me faut donc afficher le bouton d’action dès que j’ouvre le formulaire.

Cordialement.

Si je comprends bien la question…

C’est normal : une action porte sur un record. Tant que ce record n’existe pas il ne peut pas y avoir d’action sur ce record.

En général quand on nous pose cette question c’est qu’une action n’est pas la bonne approche.

Bref quel est le besoin ?

Mon besoin d’ajouter un bouton qui me permette de vérifier le nom et le prénom d’un candidat avant de passer à l’étape de la sauvegarde des données saisies.

Je ne comprends pas trop ce besoin.

Vous ne deviez pas devoir “vérifier” des données saisies vs des données qui existent ailleurs mais plutôt faire un lien vers ces données. Dans un modèle relationnel on ne duplique pas les données à plusieurs endroits.

Pour rappel sur la UI Simplicité un tel lien permet de:

  1. chercher un record existant
  2. créer un record s’il n’existe pas

Ex:
image

Mon besoin est le suivant:

Je souhaite dès que j’ouvrirai mon formulaire, j’aurai le même affichage de la pièce jointe. Un bouton pour vérifier les deux champs “Nom” et “Prénom” avant de sauvegarder les données.

J’espère avoir été clair dans l’explication.

Je continue à penser que votre approche n’est pas bonne.

  1. soit ce record correspond à une saisie effectuée en dehors de Simplicité, dans ce cas un bouton d’action pourrait être éventuellement envisagé (car le record existe déjà) mais il faudrait voir comment exploiter ces données dénormalisées pour (re)construire un lien relationnel normalisé

  2. soit ce record est une saisie effectuée dans Simplicité et dans ce cas cela n’a alors aucun sens de faire saisir ces données en double pour les comparer ensuite à des données existant déjà ailleurs => dans ce cas il faut utiliser un lien relationnel pour référencer des données déjà existantes (ou les créer à cette occasion)

Ma réponse tient compte de ma compréhension du modèle métier de votre application dont on discuté hier. Dans ce modèle les données d’état civil (nom, prénom , …) sont dans l’objet métier Personne et n’ont donc pas de raisons d’être dupliquées ailleurs. J’avoue ne pas comprendre si on parle ici de cet objet métier Personne ou d’un autre objet…

Si on parle de la saisie de cet objet Personne et si on parle de détecter une “probabilité” de doublon, ça ne doit pas se faire via un bouton (sur lequel l’utilisateur risque de ne pas cliquer) mais bien au moment de l’enregistrement => ex: dans le postValidate ou le preCreate je remonte un warning (ou je positionne un flag “Suspicion de doublon”) si je trouve un autre record de Personne avec le même nom, prénom et date de naissance.

Je propose de discuter de ce point avec Laurent car j’ai vraiment l’impression que vous n’abordez pas les choses de la bonne manière, mais c’est peut être moi qui ne comprend pas le problème métier qui se cache derrière votre question.
.

Bonjour David,

Le contexte est le suivant : un agent a reçu d’un jeune un formulaire d’inscription papier et se connecte à la solution pour l’enregistrer.
Le formulaire correspond au Dossier de candidature (que sur le modèle de données j’avais découpé à priori à tord en une relation 1-1 avec l’objet métier Personne). Ce formulaire fait une 30aine de champs.
L’objectif est de donner à l’agent la possibilité de contrôler s’il existe déjà un jeune correspondant à cette candidature dès qu’il a saisi les premiers champs (nom + prénom + date de naissance) :

  • sans attendre d’avoir renseigné les 30 (à l’enregistrement)
  • sans imposer à l’agent d’aller faire une recherche d’existence du jeune avant de commencer sa saisie.
    Idéalement plutôt qu’un bouton il aurait fallut un contrôle automatique à la sortie du champ, car comme tu le dis l’utilisateur peut ne pas cliquer, mais cela nous semblait encore plus complexe à mettre en oeuvre vu notre niveau en Simplicité…

Ok on est donc bien dans le cas 2) que je décris.

Vous devez répondre au besoin de “contrôle” d’existence du jeune en vous appuyant sur les mécanismes standards (popup de recherche/création de personnes) plutôt que d’aller developper un mécanisme spécifique qui fera fonctionnellement la même chose mais forcément en moins bien et en moins maintenable/évolutif. Surtout que votre approche par saisie manuelle est contraire à la nature relationnelle du modèle métier.

De manière plus générale il ne faut jamais implémenter une règle métier en la conditionnant à un parcours utilisateur donné ou à un mécanisme UI (a fortiori s’il n’est pas incontournable). Une règle métier doit impérativement toujours être gérée avant tout dans un traitement serveur. En effet la UI n’est qu’un canal parmi d’autres (API, imports batchs, code spécifique, …) pour interagir avec les objets métier. Tout ce qu’on fait niveau UI qui va au delà du “confort utilisateur” n’a donc aucune valeur.

Bonjour

Sans réponse de votre part je me permet de revenir vers vous car ce sujet m’a inquiété ces derniers jours car il dénote, je pense, une mauvaise approche des principes de base plateforme Simplicité.

Ca risque de vous conduire dans des impasses ou en tout cas dans des complexités auxquelles vous ne devriez pas être confrontés et qui seront forcément au final contre-productives.

Avez vous essayé de répondre à votre besoin en utilisant les mécanismes standards que je vous ai décrits ?

Si oui et si ça ne répond vraiment pas à votre besoin, il y a d’autres approches standards (ex; screenflows) qui pourraient être envisagées avant de partir dans des mécanismes spécifiques.