Restriction de droit sur un atelier

Bonjour,

J’ai de temps en temps des demandes d’enseignants qui souhaitent faire travailler leurs étudiants sur Scenari mais de manière séparée pour réduire la triche. Si on inscrit un utilisateur dans un atelier avec le droit « Aucun droit » il ne peut pas y entrer donc inutile d’envisager de lui créer un espace avec le droit « auteur », il ne l’atteindra jamais. Pas possible non plus de lui donner le droit lecteur sur l’atelier puis de restreindre son droit à aucun sur les espaces qu’il n’est pas censé voir. Donc la solution est de créer autant d’ateliers que d’étudiant mais ça devient vite lourd et peu lisible et pour le peu que l’idée est de bosser avec des modèles différents ça ne fait que démultiplier le nombre d’ateliers. Ne serait pas envisageable de pouvoir enrichir la gestion des droits pour permettre ce genre de pratique, c’est à dire avoir permettre l’accès à l’atelier tout en bloquant certains espaces ?
Amicalement
Franck

Bonjour Franck,

Un atelier est à voir comme une unité de production. Hormis les accès en lecture, les habilitations peuvent y être définies finement par espace.
Un atelier est le niveau le plus fin pour définir les accès en lecture pour notamment faire fonctionner les mécaniques de génération. Si cela n’était pas le cas, comment faire remonter à l’utilisateur le fait que la génération d’un module est partielle ou en échec, car certains grains/ressources ne sont pas accessibles ?

Concernant ton besoin :

  • [approche 1] Environnement de production partagé (un unique atelier)
    • partage des production en lecture entre les étudiants ;
    • possibilité d’avoir des espaces de production en écriture affectés à chaque étudiant ;
  • [approche 2] Environnement de production clos préconfiguré (un atelier par étudiant)
    • chaque étudiant dispose de son propre atelier, et ne peut accéder aux ateliers des autres étudiants ;
      Note : La nouvelle interface « web » permet des traitements par lot sur un nombre important d’ateliers, et facilite donc la mise en œuvre de cette approche.
  • [approche 3] Environnement de production libre pour chaque étudiant (une instance saas par étudiant)
    • chaque étudiant pourrait créer ses ateliers et définir ses habilitations (pour travailler avec d’autres par exemple)
    • chacune de ces instances SAAS sont parfaitement disjointes ;
      Notes :
      • cette architecture type SAAS est ce qui est utilisée sur les services myScenari, Canoprof, …
      • il n’existe pas pour le moment de packaging communautaire de celà car la mise en place et les actions d’administration sont beaucoup plus complexes que pour les SCENARIserver classiques.

Bonne journée
Antoine
Kelis

Bonjour,

Si, comme le rappelle Antoine, tu peux inscrire à l’atelier « sans droit », et donner les droits sur un espace de cet atelier… l’utilisateur à alors bien accès en lecture (ce qui n’est pas intuitif à priori, même si je comprend bien pourquoi) sur l’ensemble de l’atelier, et en écriture sur l’espace qu’on lui a attribué.
Je trouve cependant dommage que l’on ne puisse pas faire l’inverse : donner des droits plus élevés sur l’atelier, puis les restreindre ensuite sur un espace donné. J’ai quelques fois ce besoin, pour restreindre l’accès en écriture sur des espaces « techniques » (de diffusion par exemple, qui ne concernent pas directement l’utilisateur). J’aimerai aussi pouvoir rendre certains espaces « invisibles » (ou rôle « aucun ») pour certains utilisateurs !

Bonne journée,
Fabien

1 « J'aime »

Salut Fabien,
Pour l’inscription sans droit, j’ai testé et l’utilisateur ne voit pas l’atelier donc comment il peut atteindre l’espace. Sans quoi je suis d’accord avec toi, j’ai essayé également de donner un droit en lecture sur l’atelier et voulu supprimer le droit sur un espace donné mais ce n’est pas possible. L’option n’existe pas.
A bientôt
Franck

Sans droit sur l’atelier, et sans droit sur aucun espace de cet atelier… oui, l’utilisateur ne voit pas l’atelier.
Mais, sans droit sur l’atelier, et avec droit sur un espace de cet atelier… l’utilisateur a alors accès à l’atelier !

à+,
Fabien.

Je soutiens cette approche « inversée »… afin de permettre à @spi ou autre expert de la TeamK de nous rappeler pourquoi c’est impossible - je crois me souvenir qu’ils me l’avaient déjà expliqué… mais c’est over mes capacités de retranscription. :roll_eyes:
:pray:

Hum, je viens de refaire le test : Atelier avec ajout d’un utilisateur de test et droit « Aucun » sélectionné au niveau atelier (si on ne coche rien l’utilisateur n’est pas ajouté). Puis création d’un espace est droit « Auteur » sur cet espace. Si je me logue en mode navigation privée avec ce compte de test, je ne vois pas l’atelier.
A+
Franck

Bonjour à tous,

Je réponds en global :).

approche « inversée »

Il est parfaitement possible de définir le rôle « auteur » sur un atelier, puis uniquement « lecteur » sur un ensemble d’espaces.

Je vois le besoin pour le cas particulier d’espaces « techniques » pré-identifiés.

Je ne conseil néanmoins pas cette approche dans le cas général : l’erreur d’oublier de mettre un espace en « lecteur » si l’atelier est « auteur », est beaucoup plus lourde de conséquences que d’oublier de mettre un espace en « auteur » si l’atelier est « lecteur » !
Méthodologiquement, je préfère appliquer les principes de moindre privilège, et de définition par défaut des rôles au spectre le plus limitant : logique d’ajout d’habilitations sur les différents niveaux plutôt que logique de suppression d’habilitations.

Remarque : cette capacité a été ajoutée le 16 juin 2021 dans SCENARIchain-server (et SCENARIsuite-starter). Seules versions 5.0.1.00+ en bénéficient donc.

rendre certains espaces « invisibles »

Celà n’est en l’état pas possible : les espaces d’un atelier sont au minimum accessibles en lecture (pour les raisons données dans mon premier post)

Atelier {role:aucun} / Espace {role:auteur}

Dans cette configuration, l’atelier ne sera pas accessible via l’environnement d’édition riche.
Néanmoins, les publications dynamiques de relecture/corrections des items de cet espace seront, elles, accessibles avec un droit d’écriture. Si cette publication de relecture référence des items en dehors de cet espace, leur contenu sera néanmoins affiché (mais non modifiable).

1 « J'aime »

Imaginez l’atelier au sens 1er du terme : un lieu clos où on y travaille qui est accessible par une porte d’entrée sécurisée.

  • Si votre user est par défaut « Lecteur » ou « Auteur » (dans les propriétés du user), il a un passe qui lui permet de rentrer par défaut dans tous les ateliers (sauf si cela lui a a été explicitement interdit sur cet atelier précisément)
  • Si votre user n’a aucun role, il doit explicitement être autorisé en Lecteur ou Auteur au niveau de chaque atelier pour pouvoir y rentrer.

Ensuite, une fois entré dans cet atelier, imaginez les espaces comme des armoires, étagères … dans cet atelier. Vous pouvez aisément pour chacune de ces armoires, étagères donner le droit ou pas d’écrire, ie de modifier le contenu de l’armoire, l’étagère… mais pas de les rendre invisibles dans l’atelier.

Pourquoi n’autorise-t-on pas la possibilité de rendre invisibles certains espaces (armoire, étagère…) dans l’atelier ? Dans un atelier tous les items peuvent être liés entre eux. Donc si Marcel et Franck génèrent un même site web ou pdf à partir du même item racine, ils pourraient obtenir des résultats différents (car certains items liés pourraient être inaccessibles pour l’un ou l’autre). On estime que ce serait incompréhensible qu’une même action produise des résultats différents.

Une autre approche (que nous n’avons pas retenue à date) serait d’autoriser cette restriction en lecture par espace et faire totalement échouer la génération si l’utilisateur n’a pas l’accès en lecture à n’importe quel item exploité par cette génération. Cela impliquerait :

  • des développements supplémentaires pour une remontée explicites des raisons de l’échec de la publication (en static). Mais aussi de gérer correctement un affichage compréhensible pour tout ce qui est prévisualisations dynamique qui peut aussi parcourir le réseau d’items (qu’il faudrait donc bloquer).
  • un cout de traitement supplémentaire lors de ces générations statiques et prévisualisations dynamiques pour évaluer les permissions de chaque item exploité/traversé par l’utilisateur qui a déclenché la génération.

Evolution a priori imaginable, qui serait activable dans Builder uniquement dans les contextes où ce besoin existe. Le rendre configurable dans chaque atelier par l’administrateur serait aussi probablement imaginable (sans configuration explicite dans Builder donc), mais ajoute une difficulté supplémentaire qu’il faudrait étudier de plus près…

1 « J'aime »

@spi j’ai du mal à comprendre les problèmes que tu exposes, d’après ce que j’ai compris de la demande, ce qui est souhaité c’est juste de rendre non consultables les contenus, pas qu’ils soient rendus inexistants dans l’atelier.
C-a-d que si moi je n’ai accès en lecture qu’à un espace donné et dans cet espace il y a des items qui référencent des items qui sont dans d’autres espaces auxquels je n’ai pas accès, pas de souci, tout se passe normalement, je vois qu’il y a un item référencé, mais si j’essaie de l’ouvrir ça me met un message du genre « vous n’avez pas accès en lecture à cet item ».
Pour reprendre ta métaphore, une fois entré dans la salle atelier, il y a plein de tiroirs et ma clé en ouvre certains et pas d’autres.

Ceci étant dit, l’espace de travail étant l’atelier, pour moi ça peut avoir du sens de donner un droit en lecture inamovible à toutes les personnes qui ont accès à cet atelier. Si on veux quelque chose de compartimenté, il faut faire plusieurs ateliers.

Après je vois bien que quand on est prof par exemple, et qu’on veut faire bosser ses élèves sur le serveur scenari, c’est pas hyper pratique d’avoir 30 ateliers. Par ailleurs le switch d’un atelier à l’autre, qui sont tous sur le même modèle, est plus fastidieux et plus lent que d’ouvrir et fermer des espaces.

A quoi ca sert de masquer des items dans l’atelier, si il suffit de générer un contenu racine auquel tu as accès pour finalement pouvoir lire les contenus des items liés pour lesquels tu n’es pas sensé avoir un accès en lecture ? Ce serait considéré, à raison, comme un trou de sécurité béant et risible !

Cela impose donc de controler au sein même de chaque génération (statique comme dynamique) chaque accès aux informations de chaque item interrogé. Au delà du coût, si on fait ça, le problème fonctionnel est que si Marcel et Paul génèrent un même site web ou PDF à partir du même item racine : ils n’obtiennent pas le même résultat. A mon avis, cela poserait trop de problèmes dans la « vraie vie », car trop souvent on génère sans tout relire, tout contrôler. Donc comme je l’ai expliqué, je pense que la seule approche non dangereuse à l’usage serait de totalement bloquer la génération si le moindre item parcouru est bloqué en lecture.

Retour d’usage : nous utilisons cette propriété (en gras) pour mettre à disposition d’auteurs des « formulaires à compléter » (en version prévisualisation) avec des blocs d’instruction liés NON modifiables car hébergés dans un atelier où le rédacteur concerné n’a qu’un droit de lecture.

Pour répondre à ta question @spi : on pourrait faire ce que tu décris, c-a-d générer un contenu racine qui référencerait des items non visibles, seulement si cet item existe. Je dirais donc que c’est de la responsabilité de la personne qui maîtrise les accès aux différents espace de gérer les items et espaces pour que ça n’arrive pas, de la même manière que cette personne ne doit pas se planter au moment de donner les accès aux ateliers/espaces. Quelqu’un qui n’aurait pas accès aux items cachés ne pourrait pas les référencer dans un item de publication pour « tricher ».

Plus généralement, ma réflexion va dans ce sens : si on veut développer l’usage de Scenari comme outil directement utilisé par les élèves/étudiant⋅e⋅s dans le cadre de leur apprentissage, j’ai le sentiment qu’il est nécessaire de permettre aux encadrant⋅e⋅s de créer des environnements d’édition compartimentés pour chaque élève ou groupe d’élève, et de pouvoir passer de l’un à l’autre rapidement et facilement (quand il⋅elle corrige par exemple).

Exemple qu’on avait imaginé avec un @patrice et @TMB : compte-rendu de travaux dirigés où les élèves doivent remplir un item Optim. On ne veut pas que les élèves puissent voir et copier ce que d’autres ont rédigé.

Actuellement on peut faire ça en faisant un atelier Optim par élèves. Du coup une 30aine d’atelier Optim pour une classe, une 30aine d’autres ateliers Optim pour une autre classe, et ainsi de suite. Peut-être pas hyper pratique pour l’enseignant⋅e. Alors que un atelier par classe avec 30 espaces visibles/invisibles dedans, et qu’on peut consulter casi-simultanément (c-a-d avoir plusieurs espace et items ouverts), c’est plus gérable. Je laisse les profs confirmer ou infirmer.

Après, la solution ne serait peut-être forcément pas d’intervenir sur les accès aux ateliers et espaces, mais plutôt sur la « navigabilité » des ateliers (groupes d’ateliers, ouvrir plusieurs ateliers différents, …). Je sais pas.

Tu fusionnes là deux roles/métiers bien différents :

  • le gestionnaire responsable des affectations des droits. En effet, lui ne doit pas faire d’erreur dans sa gestion, sinon les conséquences peuvent être graves en matière de droit d’accès et de sécurité, mais c’est bien son role et sa responsabilité.
  • Marcel, qui est un Auteur (et pas un gestionnaire) qui produit ses contenus avec tout ce qu’on lui a mis à disposition et qui n’est peut-être même pas au courant que d’autres personnes n’ont pas accès à tel ou tel espace auquel lui a accès. On ne peut pas demander à Marcel qu’il s’interdise de créer un item racine de publication qui pointerait des items dans les différents espaces parce que potentiellement d’autres n’y auraient pas droit : ce n’est pas de son rôle ni de sa responsabilité d’être vigilant à cela.

Je comprends cet usage particulier de mise à disposition d’un environnement d’écriture au près d’élèves. Je pense que l’interface actuelle de l’atelier ne répond pas bien à ce contexte d’usage. Par rapport aux 3 approches proposées par @anp dans le 2ème message, on pourrait en envisager une 4ème : nous avons conçu la brique SCENARIdistrib pour justement répondre à ces situations de relations de type prof/élève. Nous avons déjà dans SCENARIdistrib la fonction de dépôt de devoirs/productions par les apprenants que les enseignants peuvent passer en revue, noter, etc. La possibilité pour les apprenants de produire un contenu à rendre (devoir) dans un environnement d’écriture Scenari (ie guidé par un modèle documentaire), est un prolongement naturel de cette fonctionnalité… Maintenant que nous avons l’interface Web unifié avec SC5.0, nous pourrions plus raisonnablement commencer à l’envisager :wink:

1 « J'aime »