j'ai constaté sur moodle 1.9 qu'on peut entrer dans un cours en étant vu comme un invité bien qu'on soit identifié pour preuve son nom en haut de l'écran. Dans certains cas, cela peut être pratique. Mais j'en suis plutôt victime car je voudrais forcer l'entrée dans un cours avec le statut étudiant. Dans les paramètres du cours on peut le préciser mais sans effet. Il en résulte que les personnes n'ont pas les droits pour participer aux activités. Elles ne comprennent par pourquoi. Si on regarde dans le bloc admin, on voit qu'elles peuvent s'inscrire au cours. Cela m'a valu une floppée de mails des participants de moodlemoot quand je leur ai demandé de préciser les ateliers qu'ils suivront. Comment résoudre ce problème ?
merci d'avance
"on peut le préciser mais sans effet"
Les paramètres sont:
Rôle par défaut: étudiant
Accès invité: ne pas autoriser
Je ne comprends pas est-ce un bug ou non ?
Mais il peut également accéder à tous les cours ouverts aux invités.
Dans ces derniers cours, il n'a QUE le statut d'invité (puisqu'il n'est pas inscrit) mais son nom de connexion apparaît toujours bien dans le header, et non pas comme "connecté en tant que : invité".
L'utilisateur peut croire alors (mais à tort) qu'il est reconnu dans ce cours comme étudiant et qu'il peut effectuer les activités de ce cours. Devant les echecs de ses essais, il se retourne alors (sans réfléchir) soit vers l'enseignant responsable, soit vers l'administrateur qui se retrouvent noyés sous les mails.
Jérôme.
Pour l'inscription indicative aux ateliers de moodlemoot, j'ai utilisé le méta-cours que nous avions préparé avec l'ensemble des inscrits. Mais cette solution n'est pas adapté dans tous les contextes.
Si ce fonctionnement que je qualifie d'anormal persiste dans Moodle, les utilisateurs vont déchanter. Ce serait dommage.
Merci à tous pour vos aides.
Christian
Avec les paramètres :
Rôle par défaut: étudiant
Accès invité: ne pas autoriser ou autoriser
Je n'arrive pas à reproduire cette erreur (version 1.7)?
J'ai constaté des trucs un peu étrange lors de l'inscription/désinscription mais rien de grave.
A noter qu'il est possible d'assigner des utilisateurs dans le rôle "invité" mais est-ce que ce rôle correspond exactement à invité? Ce rôle particulier ne devrait pas s'afficher dans la page assigner les rôles (il me semble) ni dans la liste" rôle par défaut".
Question est-ce que des utilisateurs ont ce rôle invité ? ça pourrait empêcher le rôle étudiant d'être assigné.
Bonjour,
J'ai enfin compris le problème, en reproduisant le scénario sur mon installation de test. Un étudiant Jeannot Lapin est inscrit sur une plateforme Moodle, il est accessoirement inscrit dans un ou plusieurs cours (cours A, Cours B). Il se connecte sur la plateforme, avec son nom d'utilisateur et son mot de passe. Il a accès à la liste de tous les cours, et il décide d'aller "visiter" le cours Cours C (qui a été "ouvert aux invités" par l'enseignant). La copie d'écran montre ce que voit Jeannot Lapin sur la page d'accueil du cours Cours C.
Jérôme dit "L'utilisateur peut croire alors (mais à tort) qu'il est reconnu dans ce cours comme étudiant "... euh, non, Jeannot Lapin voit bien qu'il n'est pas inscrit, puisque le bloc Administration lui propose de s'inscrire dans le cours. En ce qui concerne les activités accessibles ou non au "visiteur", ça dépend des droits qui ont été attribués par chaque activité elle-même (par le biais des Rôles et Capacités).
Je ne vois là aucun bug de Moodle, mais peut-être, pour que les choses soient bien claires, notre Jeannot Lapin qui est "en visite" dans le cours Cours C devrait-il en être informé plus clairement, par exemple, avec une combinaison de : Connecté sous le nom "Jeannot Lapin" plus Vous êtes connecté en tant qu'invité, ce qui donnerait: Vous êtes connecté sous le nom "Jeannot Lapin" en tant qu'invité... On pourrait même y rajouter une icône d'aide permettant de préciser ce qu'implique le statut d'invité dans un cours...
En revanche, il me semble que chaque activité qui a été paramétrée pour ne pas être accessible aux invités le dit clairement, par exemple les Tests (Quiz):
Désolé, les invités n'ont pas accès aux tests
Voulez-vous vous connecter avec un compte utilisateur ?
Sondage:
Désolé, les invités ne peuvent pas participer aux sondages.
Voulez-vous vous connecter avec un compte utilisateur ?
etc.
Joseph
Mais quand tu dis ... Jeannot Lapin voit bien qu'il n'est pas inscrit ... encore faut-il que le bloc "Admin" soit positionné dans le cours et visible pour les invités, ce qui n'est pas une obligation.
Pour les activités, ce que reproche Christian n'est pas le fait que ces pseudos invités/étudiants ne puissent pas y prendre part (en fonction des réglages bien sur) mais plutôt le fait que devant le message d'erreur affiché (les invités ne peuvent ...) les utilisateurs ne comprennent pas immédiatement pourquoi, puisqu'ils se considérent comme reconnus, et font de suite appel à un responsable en pestant contre cet outil qui ne marche jamais. D'où la floppée de mails.
En cela ta proposition de rajouter le rôle de l'utilisateur dans le contexte courant est une bonne chose (et en plus c'est pas trop compliqué). En fonction de la localisation de l'utilisateur, on aurait alors
- Connecté sous le nom "Jeannot lapin " invité lors qu'il n'est pas inscrit au cours,
- Connecté sous le nom "Jeannot lapin " étudiant lors qu'il est inscrit au cours,
- Connecté sous le nom "Jeannot lapin " enseignant ...
- ...
Jérôme.
- Les rôles ne sont pas liés uniquement aux cours
Dans ce cas précis si l'utilisateur rentre en cliquant sur "invité" et qu'il oublie ce qu'il a fait 2 minutes avant que faire...
si l'on possède plusieurs rôles, il pourrait être affiché le plus "haut", en tenant compte de l'héritage (catégorie de cours)
Comme l'indique la documentation sur l'accès invité (dont la lecture est fortement recommandée) :
"Les utilisateurs authentifiés peuvent accéder à n'importe quel cours autorisant l'accès aux invités sans avoir besoin de s'y inscrire." (et donc, sans cliquer sur le bouton "invité")
Cordialement
L'affichage du contexte utilisateur et de ses droits n'est pas une chose aisée.
Dans la vie courante nous avons appris les codes et les usages de son pays, mais sur le Web ses codes et usages sont moins claires ils sont encore à être trouvés.
"Les utilisateurs authentifiés peuvent accéder à n'importe quel cours autorisant l'accès aux invités sans avoir besoin de s'y inscrire."
Il faut quel paramétrage car avec la version 1.7 (1.8 ?, 1.9 ?) l'utilisateur authentifié a le message suivant:
"Vous êtes sur le point de vous inscrire comme participant à ce cours.
Voulez-vous vraiment vous y inscrire ?" [oui] [non]
[non] = ne rentre pas dans le cours
Joseph
Même si le visiteur peut avoir été invité, il reste un visiteur
Par contre, le jour ou l'on fait le changement, il faudra modifier la documentation correspondante, et signaler à tout le monde de mettre à jour le paquetage de langue, afin d'être cohérent
Séverin
La réponse est tout en bas de cette discussion dans mon message du 23 mai 14:08.
Le réglage (pour la 1.9) se trouve dans "Admin -> Utilisateurs -> Permissions -> Règles", pour la 1.7, il faut chercher l'équivalent.
Jérôme.
en effet j'ai invité pour "defaultuserroleid"
Les messages :
"Désolé, les invités n'ont pas accès aux sondages
Voulez-vous vous connecter avec un compte utilisateur ?"
Ne me semblent pas si clair que cela : un utilisateur qui s'est connecté avec son login et mot de passe peut ne pas comprendre qu'on lui propose de le refaire et si il essaie cela ne changera rien... Il n'est pas évident de faire la différence entre connecté à la plateforme et inscrit à un cours quand on est en train de naviguer dans ce cours...
Je suis d'accord qu'il n'y a pas de bug ou de mauvaise conception des choses mais un manque d'information et d'ergonomie.
Le message devrait être quelque chose comme, en anticipant la proposition de Nicolas et en utilisant le singulier parce qu'il est possible avec les rôles et capacités qu'un autre test du même cours soit accessible..." :
"Désolé, les visiteurs n'ont pas accès à ce sondage."
En dire plus est difficile car on ne connait pas les conditions d'accès au sondage : il peut être accessible aux utilisateurs authentifiés, aux utilisateurs inscrits au cour... Et donc la procédure à conseillée à l'utilisateur peut varier selon les cas : s'inscrire ( dans le cas où cela est possible) au cours, ouvrir un compte,...
En allant plus loin, comme on ignore si le refus d'accès est du uniquement au statut de visiteur de l'utilisateur, le message devrait-être : "le responsable de ce cours ne vous a pas accordé l'accès à cette activité" ... Le problème est que cela entraine presque automatiquement que l'utilisateur se tourne vers le responsable de cours et donc avalanche de mail.
La seule solution que je verrais et c'est peut-être une idée à soumettre, c'est de donner la possibilité à la personne qui crée le cours de saisir un message qui apparaisse dans le cas d'un refus d'accès. Avec l'existence d'un message par défaut...
Si l'on veut qu'un utilisateur régulièrement connecté ne puissent accéder à un cours n'acceptant pas les invités (ou avec clef), il faut définir le paramètre "defaultuserroleid" (le rôle d'un utilisateur connecté) de la page "Admin -> Utilisateurs -> Permissions -> Règles" sur invité (guest) ce qui n'est plus possible depuis quelques versions.
Pour contourner l'interdiction, une seule solution, modifer dans la table "mdl_config" cette valeur et lui attribuer celle des invités (le chiffre "6" je crois).
Après cela, même un utilisateur connecté ne pourra plus accéder à un cours sans passer par l'étape d'inscription (si les invités n'y sont pas autorisés ou avec une clef).
Cela ne répond pas entièrement à ton problème, mais les participants à ton cours, étant inscrits volontairement, pourront participer aux différentes activités. Le revers de la médaille, il faut interdire l'accès aux invités.
Jérôme.