Commande pour afficher/masquer une zone d'attribut

Tags: #<Tag:0x00007fe296a6f308>

Bonjour,

Pourriez-vous svp me dire s’il y a un moyen d’afficher/masquer d’une seule commande toute une zone d’attribut en fonction d’un champ, sans passer par une contrainte au niveau de chacun des champs de la zone d’attribut concernée ?

Merci d’avance.

Abed.

Bonjour,

obj.getFieldArea(“NOM_AREA”).setVisible(false);

Cdt

Merci @nathalie,
Au niveau de quel Hook je dois mettre ce contrôle pour que les zones d’attributs s’affichent ou non à l’ouverture du formulaire ?

Merci d’avance.
Abed.

J’ai trouvé, je l’ai mis dans le postSelect et ça a l’air de marcher.
Merci encore.
Abed.

Les mettre plutôt dans les hooks init.
https://www.simplicite.io/resources/documentation/01-core/businessobject-code-hooks.md
initCreate : hook avant affichage du formulaire de création
intUpdate : hook avant affichage du formulaire de mise à jour

D’accord.
Dans ce cas, il me faudrait encore un hook pour l’ouverture d’un formulaire en lecture seule (ni create ni update).

Quel est le besoin ? L’utilisateur n’a qu’un droit de lecture sur donnée ?

Justement, suivant son profile, il aura accès (ou pas) au formulaire en lecture ou en modification.
J’aurai besoin de masquer la zone d’attributs dans le cas de lecture aussi.

C’est possible par contrainte front en sélectionnant la zone en type d’impact.

Merci @francois.
Après avoir effectué qq tests, je trouve que le postSelect convient parfaitement à mon besoin de masquer des données confidentielles suivant le profile. Pourriez-vous me dire quels sont ses inconvénients ? Est-ce que c’est plus sécurisant de passer par une contrainte front ? D’autres avantages ?

Bonjour @françois,

Je me permets de déterrer ce sujet car j’ai besoin de généraliser ce traitement (afficher ou masquer une zone d’attribut) en fonction du profil de l’utilisateur (hasResponsibility).

En effet, nous souhaitons avoir des écrans « light » pour nos utilisateurs de base, avec seulement qq attributs affichés, et conserver les écrans actuels pour les utilisateurs avancés.

Je pense que l’idéal pour faire cela est de regrouper les champs des utilisateurs « avancés » dans des zones d’attributs que je masquerais pour les utilisateurs de base.

Exemple : Si l’utilisateur est un locataire

if (rent.getGrant().hasResponsibility(“IMMO_LOCATAIRE”))

, il ne verra pas la zone d’attribut contenant des champs confidentiels tel que le prix d’achat du bien, les indicateurs…

Question 1 : Est-ce que cette approche est bonne ? il y a-t-il des inconvénients à faire cela ?

Pour rendre cette solution dynamique et évolutive, j’aurai une table de paramétrage avec comme colonnes : les groupes de sécurités, les objets, les zone d’attributs de ces objets et un flag à afficher(O/N).

Afin de ne pas avoir à créer/modifier des dizaines (voir plus) de contraintes front à chaque fois qu’on veut ajouter ou retirer une ZA à un profil, je propose que dans le postSelect de chaque objet, et en fonction du profil de l’utilisateur connecté, je parcoure cette table de paramétrage pour afficher ou non tel ou tel ZA

this.getFieldArea(“ImmoLocataire-2”).setVisible(true/false);

Question 2 : Pareil, est-ce que cette approche est bonne ? il y a-t-il des inconvénients à faire cela ?

Je préfère vous poser la question avant de commencer à mettre en place cette solution pour des dizaines d’objets métiers.

Merci d’avance pour votre retour.
Abed.

Bonjour,

  • La bonne approche pour masquer totalement un champ :

    • est de le passer en Forbidden (Interdit) = il n’est pas envoyé à la UI, sinon il peut toujours le voir au debugger dans le formulaire
    • ou alors de le retirer carrément de l’objet et de la zone au postLoad
  • Si la donnée peut être uniquement masquée à l’écran (non sensible) et si les changements de design sont à la marge (quelques attributs), vous pouvez faire des contraintes ou du code via setVisible dans le initList et initUpdate. Le preSelect serait appliqué sur chaque ligne alors que vous souhaitez un traitement global (et pas en fonction de chaque ligne) donc il faut utiliser le initList.

  • Sinon si plus de 50% de l’objet qui n’a plus rien à voir, il est préférable de créer un objet qui hérite (ou des nouveaux objets) sur la même table. Nouveau template, nouvelles zones… du paramétrage bien isolées qui ne se mélangent pas pour certains profils dans des objets dédiés avec le même mapping des colonnes physiques que l’objet “complet” d’administration. On gagne énormément en performance de ne pas avoir faire un tetris à chaque accès. Mieux vaut exposer un objet bien préparé une seule fois (objet dédié ou par postLoad), que de refaire du design à chaque init par code ou contrainte.

  • Enfin si vos champs “avancés” sont identifiables dans une zone avec une regle de nommage stricte (termine par e3mAdmin par exemple) on peut imaginer que tout objet hérite d’une regle de visiblité au postLoad (ou de retrait de l’objet ce qui encore mieux si les champs ne sont pas du tout nécessaire).

Bonjour @françois,

Merci pour ce retour très clair et détaillé.

Il faut donc passer par la création d’un objet qui hérite ou par le retrait des champs dans le postLoad de chaque objet.

Etant donnée que nous aurons à gérer plusieurs objets métiers et surtout plusieurs profils différents (locataire, investisseur, prestataire…) avec souvent un design différent, je ne pense pas que créer des objets hérités soit le plus simple à manipuler, surtout si on décide de modifier le design d’un objet plus tard pour afficher plus ou moins de champ pour un profil.

Je pense donc que le mieux est de passer par postLoad.

D’où mes dernières questions s’il vous plaît :

  • Peut-on ajouter/retirer une zone d’attributs d’un coup dans ce hook ou bien il faut procéder champ par champ ?
  • Toujours dans l’idée de rendre cette solution paramétrable, peut-on accéder dans ce hook à un objet métier qui contient le paramétrage de ce qu’il faut afficher ou non par objet selon le profil ? Ceci nous permettra de modifier le design en dynamique (après un clear cache), avec un simple paramétrage, sans avoir à modifier le code ou les objets traités.
  • Quel serait la commande pour retirer un champ (ou mieux encore une zone d’attribut) dans le postLoad ?

Merci encore pour votre aide précieuse.

Abed.

Vous pouvez créer un objet/table qui contient vos regles de visibilité spécifiques.
Ecrire une méthode commune qui va chercher les règles en fonction des droits et de l’objet.
Et dans chaque postLoad (ou le postLoad d’un objet commun hérité), utiliser les accesseurs pour retirer certains champs :

obj.removeField("myfield");

qui retirera le champ de l’objet et des zones où il apparaît dans la session de l’utilisateur.

Quelque part vous allez réinventer les contraintes de visibilité. Donc une autre logique serait de partir d’une description de vos règles administrables par le métier (csv/excel avec le nom du champ en ligne et les groupes en colonne… par exemple) et d’écrire un parser qui le transforme en XML d’import de contraintes/impacts/habilitation.