Désactiver temporairement et conditionnellement l'accès à une application model driven app

Étiquetté : , ,

  • Désactiver temporairement et conditionnellement l'accès à une application model driven app

    Posté par Alexandre sur 11 décembre 2022 à 16h09

    Bonjour à tous

    Je cherche à désactiver d’une manière ou d’une autre l’accès à une model driven app de manière conditionnelle. Voici le scénario :

    J’ai une population de super utilisateurs qui doit pouvoir ouvrir et fermer des campagnes de mises à jour de données. Ces données sont mises à jour par une autre catégorie de personne. Il s’agit donc que les “super utilisateurs”, depuis la driven app, puissent activer quelque chose pour que les autres utilisateurs puissent faire les mises à jour, puis qu’ils puissent désactiver le même quelque chose pour que les autres utilisateurs ne puissent plus faire les mises à jour.

    Je ne sais pas vraiment quelle est la technique pour réaliser le “quelque chose” depuis la driven app.

    Pour apporter des compléments, les “supers utilisateurs” n’ont pas d’accès admin à l’environnement qui leur permettrait par exemple de désactiver la datadriven app (à moins que ce paramètre soit configurable par ailleurs pour les utilisateurs)

    Merci de vos idées 🙂

    PostID=rM6eE3H8GPxVTBr

    Alexandre a répondu Il y a 10 mois, 1 semaine 1 Membre · 9 Réponses
  • 9 Réponses
  • R3dKap

    Membre
    12 décembre 2022 à 11h12

    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

    Membre
    12 décembre 2022 à 13h00

    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

    Membre
    12 décembre 2022 à 14h22

    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

    Membre
    12 décembre 2022 à 14h28

    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

      Membre
      12 décembre 2022 à 15h32

      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

    Membre
    12 décembre 2022 à 15h31

    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

    Membre
    12 décembre 2022 à 15h42

    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

    Membre
    12 décembre 2022 à 21h05

    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

    Membre
    24 janvier 2023 à 22h55

    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

Connectez-vous pour répondre.