using git, it worked like a charm this morning.

Thanks.

Added to the base upgrade file.

Changes have been made in Git for this ticket:

Bug #9767: Note about upgrade tasks for git checkouts

  1 files changed, 4 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/b38e2197fcd39f69494590bcd9e195e016ccbaab

Changes have been made in Git for this ticket:

Bug #9767: Fix advancing tasks pointer if system tasks also exist for 
an application

  1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/99d2e2d65314ce6b66c047890e5ee6b32faf9c7b

Awesome. I think I have maintenance tasks running correctly for the 
first time since using Horde in production. :-D I only wonder why I 
was the only one experiencing (or noticing) this.
Thanks for the patience!

This seems to work just fine now too.
Okay, so we "only" need to make sure the upgrade tasks can be run 
several times without damaging anything. This need to be documented 
anywhere. Probably in each individual task file, so you notice this 
when copy-and-pasting from existing tasks.

This should be fixed.
The only thing on my system that is weird is that I have a 
'last_logintasks' cached prefs entry for *imp*, even though imp 
doesn't have a last_logintasks pref.  So not sure if this is part of 
the issue.
It will trigger on every login if running git (since 5.0.15-git is 
determined to be less than 5.0.15).  Don't know how else to handle 
this - the problem would be if we add another upgrade task prior to 
releasing the version, git people would never run this task.

Changes have been made in Git for this ticket:

Bug #9767: Fix setting pointer if system tasks are also run

  1 files changed, 5 insertions(+), 5 deletions(-)
http://git.horde.org/horde-git/-/commit/4348780c76de42a285a70963c95a1275bf193a81

Fun note: the test task is then run on each and every ajax request. :)

Here's another few things I found.

If using Horde authentication, and executing IMP for the first time, 
the login tasks code is triggered. But the logic in 
Horde_LoginTasks_Tasklist#ready() (called from 
Horde_LoginTasks#runTasks()) is not correct. When it is executed, 
there is one system task and four login tasks in my case. Because of 
the system task $tmp's count is 1. While iterating over the standard 
tasks, the loop exits immediately because the first task (purge trash) 
return $v->needsDisplay() true. $advance is also true, so the first 
task (purge trash) is removed from the task list (line 111). Only the 
system task is returned.

At the bottom of runTasks() $this->_tasklist->needDisplay() is 
executed. It returns false (or array() really) because the next task 
in the list doesn't need a confirmation (it's the Test login task from 
your earlier comment). Thus runTasks() simply returns and so does 
pushApp(). I'm not redirected to the confirmation screen again.

Side note: the system task is always executed because it's triggered 
on 5.0.15, so it's running on every login while the current version is 
5.0.15. Not sure if this is intended.

Yeah, it's not being run by either Horde or IMP doing authentication.

Neither. But for some reason this system task seemed to have triggered 
the regular login tasks too. This was just a one time thing.
I already have one login task configured to run on every login, but 
I'll try this one nonetheless.

That's a system task, not a regular task, so I'm not sure what this 
means in the overall scheme of things (are things getting better?   
worse?)

Here's a quick test script you can drop into 
imp/lib/LoginTasks/Task/Test.php that will output a notification if it 
is accessed on any given login:

<?php
class IMP_LoginTasks_Task_Test extends Horde_LoginTasks_Task
{
     public $display = Horde_LoginTasks::DISPLAY_NONE;
     public $interval = Horde_LoginTasks::EVERY;

     public function execute()
     {
         $GLOBALS['notification']->push('Test task executed', 'horde.message');
     }
}

FWIW, the first time I've seen maintenance tasks running in H4 in ages 
(I didn't even know they are displayed in the login form now), was 
when the upgrade tasks for the mailbox prefs were triggered.

This debug log looks fine.  (I am assuming you are concerned about 
IMP, since you gave me IMP configuration options).

The first time IMP is accessed via an API/Registry call and 
check_perms is true, the 1 IMP system task is run.  The remaining 4 
login tasks are queued, as expected.  According to your debug log - 
you NEVER explicitly accessed IMP.  IMP login tasks will not be run 
until you explicitly access the application.  This is expected (this 
is what differentiates SystemTasks from regular Tasks).

This doesn't seem correct.  If an application is not yet authenticated 
to, this should not be run.
At a minimum, this should still run the system tasks though.  Can you 
verify this is happening?

And at *some point*, logintasks need to be run (meaning the code at 
the bottom of pushApp()).  Since an appInit() will always call 
pushApp() without setting check_perms as false.

These are the scenarios where I see pushApp() being called during the 
login/portal loading process (Horde tasks are run fine btw, only IMP 
tasks don't run):
- During the instantiation of the Notification system when calling 
back setupNotification(). This passes 'noperms' => true to the 
callAppMethod(), 'check_perms' => false to pushApp(), $checkPerms => 
false in pushApp().
- During portal block loading of the portal. This passes 'logintasks' 
=> false to pushApp().

more debug attached with the following patch :

--- Registry.org.php        2011-10-07 13:46:34.000000000 +0200
+++ Registry.php        2011-10-10 09:26:13.000000000 +0200
@@ -1367,12 +1367,16 @@
              } catch (Exception $e) {}
          }

+        horde::debug($checkPerms);
+        horde::debug($options);
          /* Do login tasks. */
          if ($checkPerms &&
              ($tasks = 
$GLOBALS['injector']->getInstance('Horde_Core_Factory_LoginTasks')->create($app)) 
&&
              !empty($options['logintasks'])) {
+            horde::debug($tasks);
              $tasks->runTasks();
          }
+        horde::debug($tasks);

          return true;
      }


looks like whenever $options['logintasks'] is true, there are pretty 
much no task to be ran.

IMP prefs :
$_prefs['delete_attachments_monthly']['value'] = 0;
$_prefs['rename_sentmail_monthly']['value'] = 1;
$_prefs['delete_sentmail_monthly']['value'] = 1;
$_prefs['delete_sentmail_monthly_keep']['value'] = 12;


Horde config:
$conf['auth']['params']['app'] = 'imp';
$conf['auth']['driver'] = 'application';
$conf['auth']['alternate_login'] = false;
$conf['auth']['redirect_on_logout'] = false;
$conf['prefs']['params']['driverconfig'] = 'horde';
$conf['prefs']['driver'] = 'Sql';
$conf['sql']['phptype'] = 'mysql';

$_prefs['initial_application']['value'] = 'horde',

Looks like you put the debug statement in the wrong location.  From 
your debug log:

6. Horde::debug() 
/var/www/html/hordetest/libs/Horde/LoginTasks/Tasklist.php:102

You put the debug statement on line 102, in the ready() method (not 
the needDisplay() method on line 130).

FWIW, your debug log looks exactly as expected.

I definitely don't see this, and this is troubling because this means 
that the system tasks will never be run either.  So determining why 
this isn't happening on your system is a critical issue.

After updating this morning, I don't see those errors anymore. But I 
tried to further track down why the login tasks are never run for me. 
And it turns out that the code to run the tasks at the bottom of 
pushApp() is never reached, because neither horde or imp are ever 
pushed with $checkPerms being true. My current authentication is setup 
is LDAP auth in Horde and hordeauth in IMP.

Then, I don't understand.

After having updated now from git, I have added 
horde::debug($this->_tasks) to libs/Horde/LoginTasks/Tasklist.php:130 
just before the "while" loop.

attached is the log file.
from what I can see, the first element of $this->_tasks always has 
display = DISPLAY_NONE, so a task like RenameSentmailMonthly never 
gets displayed.


Maybe you'll see something wrong from the debug log file ?

This isn't correct.  needDisplay() returns the list of tasks to 
display on this page.  Your change will cause all tasks to be 
performed at one time, which is not correct.  E.g. the TOS task might 
be the first task in the chain, and no other tasks can or should be 
run until that task is complete.

Looks like this was never updated for H4.  Going to move this to a new 
ticket because it doesn't have anything to do with this report.

with the following patch, I get logintasks running and pref 
last_logintasks looks better :

a:3:{s:5:"_once";a:7:{i:0;s:45:"turba_LoginTasks_SystemTask_UpgradeFromTurba2";i:1;s:40:"turba_LoginTasks_SystemTask_UpgradePrefs";i:2;s:40:"turba_LoginTasks_SystemTask_UpgradeLists";i:3;s:45:"horde_LoginTasks_SystemTask_UpgradeFromHorde3";i:4;s:41:"imp_LoginTasks_SystemTask_UpgradeFromImp4";i:5;s:45:"imp_LoginTasks_SystemTask_UpgradeFromImp4Auth";i:6;s:43:"ingo_LoginTasks_SystemTask_UpgradeFromIngo1";}s:5:"horde";i:1317895501;s:3:"imp";i:1317895608;}


--- 
../../../../git/horde/framework/LoginTasks/lib/Horde/LoginTasks/Tasklist.php        2011-09-12 08:51:58.000000000 
+0200
+++ Tasklist.php        2011-10-06 12:09:49.000000000 +0200
@@ -131,7 +131,7 @@
          while (list(, $v) = each($this->_tasks)) {
              if (!$v->needsDisplay() ||
                  (!is_null($previous) && !$v->joinDisplayWith($previous))) {
-                break;
+                continue;
              }
              $tmp[] = $v;
              $previous = $v;

I don't see this over here.

imp/lib/LoginTasks/Task/RenameSentmailMonthly.php : protected function 
_renameSentmailMonthly
     protected function _renameSentmailMonthly($folder)
     {
         // @TODO
         $last_maint = $GLOBALS['prefs']->getValue('last_maintenance');



What is pref "last_maintenance" for ?

I've added the following prefs to imp/config/prefs.local.php
$_prefs['rename_sentmail_monthly']['value'] = 1;
$_prefs['rename_sentmail_monthly']['locked'] = true;

Now, rename_sentmail_monthly task is running every time I login and 
pref last_logintasks is always like this :

a:3:{s:5:"_once";a:7:{i:0;s:45:"turba_LoginTasks_SystemTask_UpgradeFromTurba2";i:1;s:40:"turba_LoginTasks_SystemTask_UpgradePrefs";i:2;s:40:"turba_LoginTasks_SystemTask_UpgradeLists";i:3;s:45:"horde_LoginTasks_SystemTask_UpgradeFromHorde3";i:4;s:41:"imp_LoginTasks_SystemTask_UpgradeFromImp4";i:5;s:45:"imp_LoginTasks_SystemTask_UpgradeFromImp4Auth";i:6;s:43:"ingo_LoginTasks_SystemTask_UpgradeFromIngo1";}s:5:"horde";i:1317887081;s:3:"imp";i:1300633069;}

What should be the value of last_logintasks after login ?
How IMP's logintasks know about tasks that ran previously ?

Don't see this.

And I am (again) out of ideas.  Because this works fine for me.   
Here's the code flow:

1. User login
2. Load initial application (for me it is imp)
3. On first application pushApp(), logintasks are called.
4. Horde_Core_LoginTasks::runTasks() checks to see if Horde logintasks 
have been performed yet.
5. In this case, horde logintasks have NOT been performed, so 
Horde_Core_LoginTasks::runTasks() are run for Horde.
6. (Assuming here that there are no user interactive Horde 
logintasks), #5 is completed and the remainder of #4 is performed - 
namely, performing IMP logintasks.
7. (Assuming here that there are no user interactive IMP logintasks), 
logintasks are complete and control is passed back to pushApp() to 
continue initializing imp.

Someone will have to figure out where this chain is broken.

Not for me either. But now I get this fatal error after logging in 
(with login tasks set to run on each login):

Fatal error: require() [function.require]: Failed opening required 
'HORDE_TEMPLATES/common-header.inc' 
(include_path='/var/www/headhorde/libs:/home/jan/horde-git/horde/lib:.:/usr/share/php:/usr/share/pear') in /home/jan/horde-git/horde/services/portal/index.php on line 
44

Actually the original error is:

PHP ERROR: Use of undefined constant HORDE_TEMPLATES - assumed 
'HORDE_TEMPLATES' [pid 5489 on line 44 of 
"/home/jan/horde-git/horde/services/portal/index.php"]

Nope, I've update this morning and IMP task are still not running after login.

last_logintasks after login :

a:3:{s:5:"_once";a:7:{i:0;s:45:"turba_LoginTasks_SystemTask_UpgradeFromTurba2";i:1;s:40:"turba_LoginTasks_SystemTask_UpgradePrefs";i:2;s:40:"turba_LoginTasks_SystemTask_UpgradeLists";i:3;s:45:"horde_LoginTasks_SystemTask_UpgradeFromHorde3";i:4;s:41:"imp_LoginTasks_SystemTask_UpgradeFromImp4";i:5;s:45:"imp_LoginTasks_SystemTask_UpgradeFromImp4Auth";i:6;s:43:"ingo_LoginTasks_SystemTask_UpgradeFromIngo1";}s:5:"horde";i:1317715832;s:3:"imp";i:1300633069;}


Is there an other pref (or pref backend setting)  for IMP ?

Possibly fixed by:
http://git.horde.org/horde-git/-/commit/e842ca9374d9c5c98fa3e8e2c21373303c00f76e

using git (30 September 2011) on my  test server this morning , login 
tasks did not run.
using IMP 5.0.11 and horde 4.0.9 on my production server, login tasks 
did run, but task renameSentmailMonthly  renamed 'Sent' to 
'Sent-01-1970'.

So, I can I track this using git ?
Here what I tried :

mysql> delete from horde_prefs where pref_name='last_logintasks';
Login and go to IMP : pref last_logintasks = 
a:3:{s:5:"_once";a:7:{i:0;s:45:"turba_LoginTasks_SystemTask_UpgradeFromTurba2";i:1;s:40:"turba_LoginTasks_SystemTask_UpgradePrefs";i:2;s:40:"turba_LoginTasks_SystemTask_UpgradeLists";i:3;s:45:"horde_LoginTasks_SystemTask_UpgradeFromHorde3";i:4;s:41:"imp_LoginTasks_SystemTask_UpgradeFromImp4";i:5;s:45:"imp_LoginTasks_SystemTask_UpgradeFromImp4Auth";i:6;s:43:"ingo_LoginTasks_SystemTask_UpgradeFromIngo1";}s:5:"horde";i:1317633346;s:3:"imp";i:1317633358;}

logout, change horde/imp unixtime to 1300633069

Login and go to IMP : pref last_logintasks = 
a:3:{s:5:"_once";a:7:{i:0;s:45:"turba_LoginTasks_SystemTask_UpgradeFromTurba2";i:1;s:40:"turba_LoginTasks_SystemTask_UpgradePrefs";i:2;s:40:"turba_LoginTasks_SystemTask_UpgradeLists";i:3;s:45:"horde_LoginTasks_SystemTask_UpgradeFromHorde3";i:4;s:41:"imp_LoginTasks_SystemTask_UpgradeFromImp4";i:5;s:45:"imp_LoginTasks_SystemTask_UpgradeFromImp4Auth";i:6;s:43:"ingo_LoginTasks_SystemTask_UpgradeFromIngo1";}s:5:"horde";i:1317633635;s:3:"imp";i:1300633069;}

This works perfectly for me, so I can't debug anymore.

Didn't make any difference for me.

I think I correctly fixed this.

Changes have been made in Git for this ticket:

Bug #9767: Ensure that Horde login tasks are always run first

  5 files changed, 65 insertions(+), 50 deletions(-)
http://git.horde.org/horde-git/-/commit/c0e01ac0f7012ceba6fc20b4afc4ab656febffc9

The first time IMP is pushApp()'ed for me is on the portal page. 
Horde_Block_Collection calls Horde_Registry::getAppDrivers() which 
calls pushApp() without passing any $options parameter. Thus 
$options['logintasks'] is empty too and the login tasks section in 
pushApp() is skipped.

Additionally, people on the list have reported that IMP tasks run fine 
- at least one person reported that the new autocreate login task is 
working for them.

Can't reproduce.  IMP tasks run fine.

I see the Horde login tasks running now (test.php notification), but 
IMP's tasks still don't run.
I use LDAP authentication and hordeauth. initial_application is Horde, 
I got to IMP directly from the portal.

Changes have been made in Git for this ticket:

Fix running Horde login tasks (Bug #9767).

  2 files changed, 7 insertions(+), 5 deletions(-)
http://git.horde.org/horde-git/-/commit/87a2647928d8de5869f9a62aafb3b07b9f9a3db8

I don't see this.  Picking an example task (e.g. IMP's delete 
attachments monthly), and setting the interval to "EVERY", I always 
get the confirmation page and I can verify that execute() is called in 
that class if the task is confirmed.

Hmmm... I think I found the issue.  It seems that *Horde* logintasks 
would be lost if the first application authenticated to did not have 
logintasks run.  This is because the Horde logintasks are always 
associated with the first application to load.

Solution (I think): Don't initiate a LoginTasks object until we are 
sure we are going to call runTasks() on it.  Seems to fix things for 
me (I now see things like last login/test.php warning notifications).

This probably would have broke when we added something like 
setupNotification() - this would have potentially caused other 
applications to be initialized before the login app is.

Now I don't see any login task action at all anymore. I just figured 
that I haven't seen the login tasks confirmation screen for weeks.

I get the confirmation screen when accessing IMP (using LDAP auth and 
hordeauth in IMP), but the tasks don't run when confirming them. I 
just get to DIMP.