1. Mettez la plate-forme en mode debug pour faire apparaitre les messages
(Administration -> Serveur -> Deboggage)
2. Donnez les droits d'écriture à TOUT le dossier Moodledata
Apparemment vous êtes un certain nombre du même coin à avoir des demandes 1.8. C'est lié ? ce serait sympa de savoir quel est votre projet et votre situation...
Valery Fremaux
Posts made by Valery Fremaux
Ce syndrome est probablement du à l'impossibilité d'écrire les fichiers de session.
Vérifiez la valeur de $CFG->dataroot dans le fichier de configuration de Moodle et vérifiez vos droits d'écriture sur le répertoire désigné.
C'est votre utilisateur "apache" qui doit pouvoir écrire dedans. Il inscrit les fichiers de session dans {$CFG->dataroot}/sessions
Vérifiez la valeur de $CFG->dataroot dans le fichier de configuration de Moodle et vérifiez vos droits d'écriture sur le répertoire désigné.
C'est votre utilisateur "apache" qui doit pouvoir écrire dedans. Il inscrit les fichiers de session dans {$CFG->dataroot}/sessions
aleykoum salam,
pour celà, il faut utiliser des "assignations cachées". C'est la petite option (oeil) dans "l'assignation des rôles" qui permet de donner un rôle à quelqu'un sans que les étudoants le voient.
Pour la première question, une solution consiste à mettre une catégorie par enseignant, et de ne donner le droit de Responsable de cours que sur cette catégorie.
Voir la discussion ici, car cette méthode n'est pas super... (flûte, retrouve pas la discussion...), ajhhh oui : là
pour celà, il faut utiliser des "assignations cachées". C'est la petite option (oeil) dans "l'assignation des rôles" qui permet de donner un rôle à quelqu'un sans que les étudoants le voient.
Pour la première question, une solution consiste à mettre une catégorie par enseignant, et de ne donner le droit de Responsable de cours que sur cette catégorie.
Voir la discussion ici, car cette méthode n'est pas super... (flûte, retrouve pas la discussion...), ajhhh oui : là
Consequent review of Moodle Tracker module :
Our experience on real project was showing us that once a solution has been pushed to production codebase, it may be not a definitive solution as side effects can appear.
We wanted to distinguish the "WORKING" state that signals the submitter that work is in progress on the issue, and the "TESTING" state that tells some changes have been performed but need a complete validation to be sure it is a definitive solution. Both TESTING and RESOLVED states can have content in the "solution" field, so the automatic switching to RESOLVED when solution has content has been removed.
Priority feature allows assigning a priority stack to all non-closed tickets. The priority is viewable against a new capability, and can be changed against another capability. Submitters usually will not be allowed to change priority, but might trigger the tracker's admins that they need the issue to be handled more quickly. They can send a RAISEPRIORITY request as many times as the ticket has not reached the top priority level.
- Adding file attachment item for screenshots
- Adding provision for priority handling of tickets
- Adding raiserequest features when using priority
- Adding proper notifications on comment
- Fixing notication on events
- Adding "Testing" state and event (see below)
- Reworking the global semantics and lower the "issue tracker" aspect
- Fixing some bugs from Tracker
Our experience on real project was showing us that once a solution has been pushed to production codebase, it may be not a definitive solution as side effects can appear.
We wanted to distinguish the "WORKING" state that signals the submitter that work is in progress on the issue, and the "TESTING" state that tells some changes have been performed but need a complete validation to be sure it is a definitive solution. Both TESTING and RESOLVED states can have content in the "solution" field, so the automatic switching to RESOLVED when solution has content has been removed.
Priority feature allows assigning a priority stack to all non-closed tickets. The priority is viewable against a new capability, and can be changed against another capability. Submitters usually will not be allowed to change priority, but might trigger the tracker's admins that they need the issue to be handled more quickly. They can send a RAISEPRIORITY request as many times as the ticket has not reached the top priority level.
Ces questions ont déjà eu une réponse ici : http://moodle.org/mod/forum/discuss.php?d=124209
Il n'est pas très recommandé aujourd"hui de développer sous 1.5 version obsolète et plus du tout maintenue par personne. Si vous demandez de l'aide, la plupart de vos questions risquent de tomber dans le vide parce que les situations de programmation que vous soumettez (et les problèmes que vous soulevez) peuvent être résolus depuis longtemps.
Si vous ne maîtrisez pas l'environnement dans lequel on vous demande de travailler, reportez cette information et essayez d'obtenir une version à jour en 1.9.
En effet Daniel, Nicolas devrait le tranférer sous peu dans la rubrique Développement de Moodle.
Il n'est pas très recommandé aujourd"hui de développer sous 1.5 version obsolète et plus du tout maintenue par personne. Si vous demandez de l'aide, la plupart de vos questions risquent de tomber dans le vide parce que les situations de programmation que vous soumettez (et les problèmes que vous soulevez) peuvent être résolus depuis longtemps.
Si vous ne maîtrisez pas l'environnement dans lequel on vous demande de travailler, reportez cette information et essayez d'obtenir une version à jour en 1.9.
En effet Daniel, Nicolas devrait le tranférer sous peu dans la rubrique Développement de Moodle.