Login tasks don't work

I get the confirmation screen when accessing IMP (using LDAP

Fri, 01 Apr 2011 09:03:43 +0000

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.

Now I don't see any login task action at all anymore. I just

Fri, 20 May 2011 07:53:09 +0000

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 don't see this. Picking an example task (e.g. IMP's delet

Tue, 24 May 2011 05:15:44 +0000

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.

Changes have been made in Git for this ticket: Fix running

Tue, 24 May 2011 05:15:49 +0000

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 see the Horde login tasks running now (test.php notificati

Tue, 24 May 2011 09:49:28 +0000

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.

Can't reproduce. IMP tasks run fine.

Tue, 24 May 2011 16:03:28 +0000

Can't reproduce. IMP tasks run fine.

> Can't reproduce. IMP tasks run fine. Additionally, peo

Tue, 24 May 2011 16:06:38 +0000

> Can't reproduce. IMP tasks run fine. 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.

The first time IMP is pushApp()'ed for me is on the portal p

Tue, 24 May 2011 16:51:01 +0000

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.

Changes have been made in Git for this ticket: Bug #9767: E

Wed, 25 May 2011 07:24:47 +0000

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

I think I correctly fixed this.

Wed, 25 May 2011 07:25:13 +0000

I think I correctly fixed this.

Didn't make any difference for me.

Wed, 25 May 2011 12:00:23 +0000

Didn't make any difference for me.

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

Tue, 07 Jun 2011 05:32:19 +0000

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

using git (30 September 2011) on my test server this mornin

Mon, 03 Oct 2011 09:32:33 +0000

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;}

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

Tue, 04 Oct 2011 06:27:09 +0000

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

> Possibly fixed by: > http://git.horde.org/horde-git/-/com

Tue, 04 Oct 2011 08:29:34 +0000

> Possibly fixed by: > http://git.horde.org/horde-git/-/commit/e842ca9374d9c5c98fa3e8e2c21373303c00f76e 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 ?

Not for me either. But now I get this fatal error after logg

Tue, 04 Oct 2011 08:37:41 +0000

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"]

> PHP ERROR: Use of undefined constant HORDE_TEMPLATES - ass

Wed, 05 Oct 2011 19:53:48 +0000

> 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"] > 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"] 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.

I've added the following prefs to imp/config/prefs.local.php

Thu, 06 Oct 2011 08:42:13 +0000

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 ?

imp/lib/LoginTasks/Task/RenameSentmailMonthly.php : protec

Thu, 06 Oct 2011 08:47:18 +0000

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 ?

> Fatal error: require() [function.require]: Failed opening

Thu, 06 Oct 2011 10:24:47 +0000

> 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 I don't see this over here.

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

Thu, 06 Oct 2011 10:25:19 +0000

> Someone will have to figure out where this chain is broken. 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;

> imp/lib/LoginTasks/Task/RenameSentmailMonthly.php : protec

Thu, 06 Oct 2011 17:22:16 +0000

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

Thu, 06 Oct 2011 17:24:40 +0000

> with the following patch, I get logintasks running and pref > last_logintasks looks better : 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.

>> with the following patch, I get logintasks running and pr

Fri, 07 Oct 2011 12:21:01 +0000

>> with the following patch, I get logintasks running and pref >> last_logintasks looks better : > > 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. 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 ?

>> PHP ERROR: Use of undefined constant HORDE_TEMPLATES - as

Fri, 07 Oct 2011 14:07:44 +0000

>> 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"] > >> 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"] > > 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. 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.

> And it turns out that the code to run the tasks at the bot

Mon, 10 Oct 2011 04:34:32 +0000

> 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. 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 having updated now from git, I have added > horde:

Mon, 10 Oct 2011 04:38:48 +0000

> 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. 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.

more debug attached with the following patch : --- Regist

Mon, 10 Oct 2011 07:55:29 +0000

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',

These are the scenarios where I see pushApp() being called d

Mon, 10 Oct 2011 10:24:38 +0000

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().

> - During the instantiation of the Notification system when

Tue, 11 Oct 2011 04:30:34 +0000

> - 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(). This doesn't seem correct. If an application is not yet authenticated to, this should not be run. > - During portal block loading of the portal. This passes 'logintasks' > => false to pushApp(). 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.

This debug log looks fine. (I am assuming you are concerned

Tue, 11 Oct 2011 04:41:02 +0000

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).

FWIW, the first time I've seen maintenance tasks running in

Tue, 01 Nov 2011 09:26:29 +0000

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.

> FWIW, the first time I've seen maintenance tasks running i

Tue, 01 Nov 2011 18:40:15 +0000

> 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. 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: push('Test task executed', 'horde.message'); } }

>> FWIW, the first time I've seen maintenance tasks running

Tue, 01 Nov 2011 22:07:15 +0000

>> 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. > > 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?) Neither. But for some reason this system task seemed to have triggered the regular login tasks too. This was just a one time thing. > 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: I already have one login task configured to run on every login, but I'll try this one nonetheless.

>> Here's a quick test script you can drop into >> imp/lib/

Tue, 01 Nov 2011 22:12:48 +0000

>> 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: > > I already have one login task configured to run on every login, but > I'll try this one nonetheless. Yeah, it's not being run by either Horde or IMP doing authentication.

Here's another few things I found. If using Horde authent

Tue, 01 Nov 2011 22:50:13 +0000

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.

Fun note: the test task is then run on each and every ajax r

Tue, 01 Nov 2011 22:52:52 +0000

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

Changes have been made in Git for this ticket: Bug #9767: F

Tue, 01 Nov 2011 23:21:33 +0000

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

> Here's another few things I found. > > If using Horde au

Tue, 01 Nov 2011 23:21:33 +0000

> 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. This should be fixed. > 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. 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. > 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. 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.

>> Here's another few things I found. >> >> If using Horde

Tue, 01 Nov 2011 23:37:51 +0000

>> 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. > > This should be fixed. 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! >> 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. > > 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. This seems to work just fine now too. >> 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. > > 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. 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.

Changes have been made in Git for this ticket: Bug #9767: F

Wed, 02 Nov 2011 00:09:18 +0000

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

Changes have been made in Git for this ticket: Bug #9767: N

Wed, 02 Nov 2011 00:09:22 +0000

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

> Okay, so we "only" need to make sure the upgrade tasks can

Wed, 02 Nov 2011 00:09:56 +0000

> 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. Added to the base upgrade file.

using git, it worked like a charm this morning. Thanks.

Wed, 02 Nov 2011 08:56:40 +0000

using git, it worked like a charm this morning. Thanks.