[R3dKap]

Mmmm… Question très intéressante Alexandre Perret.

Les cadors Dataverse, une idée ? Theophile CHIN-NIN, Tanguy Touzard, DavidZed, Pierre Bourdial, David Vachala ?

CommentID=EsMPG94kWght7Kz, PostID=rM6eE3H8GPxVTBr

[Sebastien]

Salut Alexandre Perret
Je ne pense pas que se soit possible de jouer avec les permissions des utilisateurs simplement. A ta place, j’essayerai de voir le problème d’une autre façon.

Exemple I – Restriction par vue

Est-ce que l’accès à la model-driven le seul moyen d’empêcher que les utilisateurs ne mettent à jour la donnée ? Ce que tu peux faire, même si ce n’est probablement pas vraiment dans les règles de l’art, se serait ajouter un booléen (ou autre champ) à tes campagnes qui s’appellerait ‘Campagne modifiable’ et modifier toutes les vues de l’app model driven pour qu’elles n’affichent que les campagnes modifiables. S’il n’y en a pas, tes utilisateurs auront toujours l’accès, mais ils ne verront rien à l’intérieur.

Exemple II – Restriction par équipe

Si tu mets tous tes utilisateurs dans une équipe et le rôle qui leur donne accès à la donnée n’est lié qu’à cette équipe, il s’agit ensuite d’une simple manipulation de 30 secondes pour activer/désactiver ce rôle. Cela demandera par contre quelqu’un avec des accès.

Exemple III – Restriction par phase

Tu coupes le courant de leur bureau quand ils ne doivent pas modifier la donnée. . . Bien sûr, je plaisante, mais je voulais juste illustrer qu’un problème peut avoir des solutions bien différentes en fonction des questions que l’on se pose.

Aujourd’hui, tu poses la question “Comment restreindre l’accès à l’app model-driven ?” et c’est effectivement une bonne question à se poser, mais ce n’est pas la problématique la plus fondamentale de ton scénario. Pour moi, d’après ce que je comprend de ton post, ce serait plutôt “Comment, sans droits d’administrateurs, peut on périodiquement donner accès à de la donnée spécifique à un groupe d’utilisateurs ?”. Dans ce cas, c’est assez simple d’imaginer une canvas qui ne donne les droits d’édition que quand un champs booléen ‘Permission édition campagne’ dataverse de l’utilisateur actif est égal à ‘true’, et on restreint toutes les modifications de la table en dehors de canvas, on donne les droits de modifier ‘Permission édition campagne’ aux ‘Super users’, et on à finit.

J’espère que tout ça te sera utile, même si je suis bien conscient de ne pas avoir répondu à ta question 😅

CommentID=NQA8sxcH3qH2akp, PostID=rM6eE3H8GPxVTBr

[David Vachala]

Hello Alexandre Perret ,

C’est un sacré used cases ! il faudrait “jouer” avec l’attribution de rôles et permissions Dataverse.
A tester : créer un Power Automate qui change les permissions affecter aux users (lecture / modification)

Le Power Automate pourrait être lancé depuis la modèle driven par les users autorisés.
Le changement d’une valeur dans une table pourrait conditionner l’affectation ou non d’un rôle.

Voici une petite vidéo de Kent Weare ( qui l’a fait à partir d’un Excel mais c’est adaptable) 👍 010 Automating Common Data Service (CDS) Role Permissions using Power Automate Tutorial – YouTube.

Bon je n’ai pas eu le temps de le tester mais cela me semble une bonne piste !

CommentID=JSf97vm0hKJjiNp, PostID=rM6eE3H8GPxVTBr

[R3dKap]

Du coup, avec le recul, voici mon avis : le faire via des rôles/permissions ça va vite ressembler à une usine à gaz pas forcément très stable.

Je verrais plutôt une colonne “Statut” (Ouvert/Fermé) sur les données qui sont conditionnées par “l’autorisation” accordée par les supers-users. Reste à voir ensuite comment exploiter cette info.
Comme le dit Sebastien Brandeis à part faire du canvas je vois pas. Par contre, vu que ton app est déjà dans Model-Driven et que tu voudrais peut-être qu’ils y restent tous (super-users ET users classiques), ça serait une bonne piste il me semble de développer une custom page pour les users classiques où ils ne pourront accéder et modifier que les enregistrements qui ont le “Statut” Ouvert. Tu me suis ?

CommentID=IXnLvMbYQv1o7Bz, PostID=rM6eE3H8GPxVTBr

[Sebastien]

Exactement, une vue dataverse bien faite peut être appropriée, ou encore une intégration canvas à la model-driven. Je n’ai personnellement jamais essayé, mais il parait que ça fonctionne assez bien, et dans ce cas, tu peux avoir le meilleur des deux mondes.

SubCommentID=kBV5ZuetkszGvw9, CommentID=IXnLvMbYQv1o7Bz, PostID=rM6eE3H8GPxVTBr

[DavidZed]

Je ne l’ai jamais fait, donc mon point de vue va être très théorique :

• Mettre tous les utilisateurs standard dans une team

• Pour leur rendre une campagne accessible : attribuer la campagne à l’équipe

• Pour verrouiller la campagne : l’attribuer à une autre équipe

• Au niveau des roles de sécurité, permettre aux super-users de modifier tous les enregistrements, pour les utilisateurs standard, leur permettre de ne modifier que les “team owned records”

CommentID=OZ3ypHneBQV6GMl, PostID=rM6eE3H8GPxVTBr

[David Vachala]

Voilà donc plusieurs approches à tester ! tiens nous au courant de l’option que tu prends et partage les résultats à la communauté 😉

CommentID=aT9JZ3QwtI10uJj, PostID=rM6eE3H8GPxVTBr

[Alexandre]

En voilà un paquet de pistes.
Si je m’oriente vers la model driven app c’est qu’elle semble suffire au besoin et qu’il me semble inutile de me lancer dans une canvas. Mais bien évidemment je pourrais user d’une custom page pour les besoins plus spécifiques.

Je vais réaliser mon chiffrage sur la base de vos suggestions et je pense que d’une manière ou d’une autre j’arriverais aux fins attendues.

Merci à tous pour vos suggestions. Je reviendrais d’ici une paire de mois 😉

CommentID=uWu0fXkrCMdMBcc, PostID=rM6eE3H8GPxVTBr

[Alexandre]

Salut à tous et merci pour vos suggestions.
En fait nous partirons sur un mix de toutes vos solutions.

En effet pour ouvrir une campagne, tout va se passer par flow qui consisteront à :

• donner le rôle aux utilisateur (il y a des personnes qui ‘surveillent’ en lecture seule les données de leur périmètre et d’autres personnes qui modifient les données de leur périmètre)

• Créer des équipes à la volée (permet de définir les périmètres de chaques agents: un agent est sur un ou plusieurs périmètres)

• partager les enregistrements à modifier aux équipes

A partir de ce moment là, la campagne de modification sera ouverte puisque les utilisateurs pourront voir les enregistrements qui leurs sont partagés au sein de leur équipe.

A la fin de la campagne, le super admin exécutera des flows qui permettrons de faire le chemin inverse (on retire le partage, on enlève les rôles de sécu aux utilisateurs et on supprime les équipes). De ce fait les simples utilisateurs ne verront plus les données qui les concernaient.

Bonus : uniquement 2 champs sont modifiables par les utilisateurs pendant la campagne, sur la quinzaine de champs que contient la table. Le rôle de sécurité ne suffit pas, j’ai ajouté des field security level que j’affecte sur les équipes et qui rendent les champs qui ne doivent pas être modifiés en lecture seule. Et là encore ces fields level security sont attribués par mes flows.

J’ai employé le futur car à ce stade seuls les pocs de toutes ces actions a été réalisée. J’ai encore quelques craintes sur les temps de traitements et peut être aussi les droits que je pourrais mettre aux super admins pour réaliser via flow toutes les actions.

Le déclenchement des flows pour les ouvertures et fermetures de campagnes, je pense les effectuer via des boutons dans une power page. Ce sera plus simple et plus explicite je pense que de faire des codes JS pour déclencher les flows depuis des boutons de ma driven app.

Voilà, n’hésitez pas à me faire part de vos avis ! En attendant je vous remercie de vos conseils, et je reviendrais sans doute vous dire lorsque les dévs seront terminés.

CommentID=HWeQuDtobMTDjru, PostID=rM6eE3H8GPxVTBr