DominoArea.org [Archive]

Bjr ! et oui je reviens de temps en temps . dites moi j'ai une question a deux euros , Pour que des personnes puissent voir et lire des document dans une vue ,je passais par la LCA du masque associé a la vue et attribuait aux personnes le role 'lecteur' . 1 ) Mais je me demande si le fait de simplement créer un chap de type 'lecteur' dans le masque avec le nom de ces personnes ne suffirait pas ? 2 ) ainsi arrive un autre question ,si je met carrement le nom d'un groupe dans ce champ lecteur et que ce groupe évolue ensuite ( oui car c'est le but du groupe) ,cela marchera t il? Les droits de visu se repercuteront (il sur l'historique des document?Je pense que c'est oui pour tt ca ,mais j'aimerai une confirmation des boss de notes SvpMerci bcp !!

en théorie la gestion des droits des champs lecteurs sur les groupes fonctionnent, mais sur un ancien projet nous avons rencontré pas mal de probleme.Je conseille donc de bien tester ce type de droits.sinon, ce qui marche très bien, c donner un role [lecture_perso] à goupe et stockés ce role ds un champ de type lecteur, c largement plus fiable.

Merci du conseil..je tente le coup qd meme..je pourrais avoir un peu plus d'info sur ces rôles ? Merci !

c des roles classiques de la LCA, qu'est ce que tu veux savoir exactement ??

Ben j'ai jamais utilisé le principe des roles et je voulais simplemnt savoir a quoi cela sert e tcomment on les utilise je ne sai spas quoi preciser de plus .Cependant j'ai tenté la technique de mettre des noms de groupe en dur dans le CA et cela semblme fonctionnerQuels type de probleme avais tu rencontré spécialement?merci !

Le pb était que certaines personnes appartenant à un groupe donné, n'avait pas les droits correspondant aux documents qui contenaient le nom du groupe. Je n'ai plus d'exemple en tête..Il s'utilise de la manière que tu le souhaite avec la fonction @UserRoles qui te retourne la liste des roles, cela te permet d'afficher ou non certaines données par exemple, le fait de stocker le nom d'un role ds un champ lecteur ou Auteur permet de donner accès à un ensemble de personnes directement ou faire des redirections les possibilités sont nombreuses.

Les rôles permettent de définir un ensemble d'utilisateurs. Avec ces rôles tu pourras limiter l'accès à certains éléments de la base. 1. Tu dois créer les rôles dans la LCA (2ème onglet)2. Tu affectes ensuite les utilisateurs (ou un groupe) à chaque rôle (1er onglet)Quelques exemples d'utilisation des rôles : - Dans un champ Lecteur d'un masque : cela te permet de limiter l'accès des docs aux seuls utilisateurs ayant le rôle.- Tu peux même laisser la possibilité à la personne qui crée un doc avec un masque de choisir qui pourra lire le doc : il suffit utiliser un champ de type case à cocher où l'utilisateur choisit le rôle. Le champ lecteur sera calculé avec pour valeur le nom du champ de type case à cocher.- Pour masquer des éléments d'un masque ou d'une page, par exemple un champ ou un bouton : tu peux utiliser la formule suivante au niveau de la boite de propriété ans la zone "Masquer le ou les paragraphes si la formule est vérifiée :"!@IsMember("[NomDuRole]";@UserRoles)- Pour autoriser les utilisateurs d'un rôle à créer des docs à partir d'un masque : dans la boite de propriété du masque, dernier onglet, dans la zone "Autorisation de créer des documents avec ce masque à :", il suffit de cocher le ou les rôle(s) en question- Idem pour l'accès à une vue (dernier onglet dans les propriétés)Etc...

Utilises des roles dans champ lecteur, c clair que c + fiable. Moi c ce que j'utilise d'ailleur dans toute mes appli et je ne conçoit pas maintenant une appli sans rôles....

Le gros inconvénient avec les groupes et que s'il faut le renommer ou qu'il faut donner les droits supplémentaires à d'autre groupe ou personnes, il faudra créer une moulinette qui fasse la MAJ de tous les documents.Si tu n'es pas convaincu fait le test avec des groupes imbriqués ds ton groupe, tu devrais rencontré pas mal de bug.

Oui en effet...Si je peux apporter " un peu d'eau au moulin "les rôles permettent en plus de la LCA d'étendre ou de restreindre les droits et les actions des utilisateurs sur la base en fonction de leur accès.Le champs Lecteur lui par contre permet de définir la portée, le périmétre de document qui sera accessible aux utilisateurs et ce quelque soit le droit positionné dans la LCA ; en effet un champ de type Lecteur mal renseigné et les documents ne sont plus visibles ni accessibles via l'interface. La seule méthode de récuperer les document est de modifier par macro la valeur du champ Lecteur et encore ce n'est pas gagné.Il est impérative d'ajouter automatiquement dans un champ de type lecteur soit un rôle du genre [Administration] ou un nom de groupe "Administrateurs" fonctionnels de l'application. Afin que l'utilisateur ne voit cette manipulation on créer en fait deux champs :- un champs de type Lecteur et celui-ci est caché - un champ de type nom (visible) si l'utilisateur à la possibilité de définir lui même les autorisation de lecture de son documentau moment de l'enregistrement du document une formule mettra à jour le champ de type lecteur en concaténant à cette liste les noms des groupes, rôles administration etc...Une formule du genre : @Unique(dispLecteur):"[Administration]":"AdminFonctionnels":"AdminNotes";J'ai utilisé ce procédé dans des applications de type workflow à périmétre restreint ça fonctionne parfaitement.Attention : il faut utiliser des champs de type Nom dans le champ utilisateur ; si celui-ci est de type texte... ça risque de ne pas fonctionner et de manière générale quand on définit des champs de ce genre je recommande toujours de prendre des types Nom ça rend toujours de nombreux services si on souhaite étendre les fonctionnalités de l'application.

ok merci pour toutes vos precisions je vais relire tt vos poste au calme et voir si je peux l'adapter a mon applicependant ,j'ai l'impression que l'ajout de role aux groupe fait un peu doublon ,A ce que je comprend votre systeme permet de gerer donc tt les roles par la lca alors que moi je met les noms de groupe en dur dans l'application. Cependant elle rest etres maleable ,j' ai integrer a mon application ,ma premiere idée et les droits se repercutent bien aux membres du groupe (si les groupes sont ds le CA principal).tout mes noms de groupes sont predeterminés (dont un admini j'y avais pensé)et cela me permet en effet de rajouter via la CA tt les noms necessaires.bref je vais qqd meme me pencher sur la question des roles afin de voir vraiment ce que cela m'apportera car vous avez tous l'air convaincu merci pour vos reponseset si vous avez d'autres suggestions... a+