You are not logged in.
I've been having a really hard time duplicating this and gathering enough info, but what I believe is happening is that when the cron is triggered from common.function.php:callCronForce(), there is a race condition, where if the cron call finishes after the main page loads, the cron's $_SESSION gets saved on top of the main page $_SESSION, so any calls to addMessageAfterRedirect by cron jobs get added to the user's $_SESSION['MESSAGE_AFTER_REDIRECT'] variable.
Since the user is not the one performing these tasks, they should not see messages of such.
Below is the bug fix for the issue. An alternative would be to disable sessions altogether for the cron.php script, but as cron functions may access session variables, this might not be a good idea.
A third, and 'best solution' alternative would be to create custom session handlers that can load the session, but not save it. However this wouldnt be very flexible, and wouldnt work if the user added a plugin or something with their own custom session handler.
--- cron.class.php.orig 2010-01-15 03:33:32.000000000 +0000
+++ cron.class.php 2010-01-20 15:54:06.000000000 +0000
@@ -226,7 +226,9 @@
// la fonction a été inclus ou la fonction existe
// l'appeler
logInFile("cron","Launch $tache\n");
+ $msgsbkup = $_SESSION['MESSAGE_AFTER_REDIRECT'];
$code_de_retour = $fonction($last);
+ $_SESSION['MESSAGE_AFTER_REDIRECT'] = $msgsbkup;
// si la tache a eu un effet : log
if ($code_de_retour) {
GLPI 0.72.3
Last edited by feystorm (2010-01-20 18:01:31)
Offline
Will be corrected in 0.80 version.
Thanks for the return.
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline