Avez-vous vent d'un module qui permet de faire de l'enregistrement de données "public", c'est-à-dire qui permette à des invités "sans compte" d'entrer une fiche de renseignements ? (du type de celle qu'on pourrait constituer par le module "database") ?
et si tu donnes tout simplement les droits sur les capacités nécessaires pour le(s) module(s) de ton choix à l'utilisateur invité, et/ou authentifié, éventuellement seulement pour un cours spécifique ?
Pas mal Séverin, c'est vrai que ne travaillant pas très quotidiennement (sauf pour le dév) sur une 1.8 (même 1.7), j'ai pas encore la bonne pratique des rôles.
Ca sera pour la rentrée prochaine, car je ne passerai en 1.8 en prod qu'à la fin de l'année scolaire !!
...Valéry.
Car même si j'ai bien bossé à traduire la documentation sur les rôles, et si j'en parle à partir de mes bases théoriques, je n'ai que très peu utilisé les rôles jusqu'à présent, mes gros serveurs en exploitation étant en 1.6.x
J'ai juste testé aujourd'hui une migration 1.6.x vers 1.8+ sur une copie d'une instance de production, pour préparer à la migration qui aura lieu pour la rentrée prochaine.
Séverin
Après examen attentif du module data, cela ne suffit pas. J'ai donné les droirs à l'inviter d'ajouter un fiche, mais les scripts ne tiennent pas compte de l'état d'invité.
En premier lieu, il faut modifier le piège d'entrée dela page edit.php §60 :
$context = get_context_instance(CONTEXT_MODULE, $cm->id);
if (!isloggedin() or (isguest() and !has_capability('mod/data:writeentry', $context))) {
redirect('view.php?d='.$data->id);
}
plutôt que
if (!isloggedin() or isguest()) {
redirect('view.php?d='.$data->id);
}
$context = get_context_instance(CONTEXT_MODULE, $cm->id);
Mais ce n'est pas tout. En faisant cela on permet à l'invité d'entrer dans edit et de saisir une nouvelle fiche.
Maintenant il faut modifier la visualisation des listes et des fiches : tout utilisateur propriétaire d'une fiche peut la modifier : tous les "guests" peuvent donc "collectivement" modifier toutes les fiches des "guests", ce qui est idiot pour un simple "sign in". Il faut donc interdire à un guest ces commandes au moment de la consultation de la liste ou des fiches individuelles et modifier view.php et peut-être d'autres scripts. Comme ça, l'invité dépose une donnée (activer de préférence l'approbation) et ne peut que constater qu'elle est là si elle a été approuvée.
Bon je terminerai les patchs après la nouvelle star ()
Une instance de l'activité Feedback peut-être incorporée sur la page d'accueil.
En réglant le type sur "anonyme" et en autorisant plusieurs remises de réponses, on peut constituer un formulaire permettant de récupérer des données suivant les différents types de champs permis, texte, date, numérique ... en plus l'export vers un tableur est possible ainsi que la remise à zéro et le réemploi éventuel de ce questionnaire dans n'importe quel cours.
Que du bonheur quoi ...
Tout tests faits, Jérome à raison, le module Feedback fonctionne en effet en mode "anonyme" à entrée publique, avec la restriction suivante :
Le public ayant posté sa contribution ne peut voir les contributions approuvées, à moins d'un retraitement en aval des réponses et une réédition de celles-ci ailleurs dans le cours.
Je reste donc sur mon hack de la database, mais conserve une vue sur ce module Feedback que je vais probablement "nettoyer" un peu (clefs manquantes, quelques layouts qui sont pas top calés.
Merci à tous.
La dernière étape du hack annoncé ne prend qu'une petite ligne dans "mod/data/lib.php"!
dans la fonction data_print_template vers la ligne §878 (ligne non fiable, doit venir de la librairie originale 1.7) :
La modification permet simplement d'éviter que tout invité puisse avoir les accès de modification, même s'il est connu comme le propriétaire des enregistrements.
Je te réponds à la volée, sans prendre le temps de vérifier, je dois partir.
Sauf erreur de ma part, le module Feedback pourrait permettre cela, je n'en vois pas d'autre.