6.0.0-git
2019-03-24

[#9767] Login tasks don't work
Summary Login tasks don't work
Queue Horde Base
Queue Version Git master
Type Bug
State Resolved
Priority 3. High
Owners jan (at) horde (dot) org, slusarz (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 2011-04-01 (2914 days ago)
Due
Updated 2011-11-02 (2699 days ago)
Assigned 2011-05-24 (2861 days ago)
Resolved 2011-11-01 (2700 days ago)
Milestone
Patch No

History
2011-11-02 08:56:40 rsalmon (at) mbpgroup (dot) com Comment #44 Reply to this comment
using git, it worked like a charm this morning.

Thanks.

2011-11-02 00:09:56 Michael Slusarz Comment #43 Reply to this comment
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.
2011-11-02 00:09:22 Git Commit Comment #42 Reply to this comment
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
2011-11-02 00:09:18 Git Commit Comment #41 Reply to this comment
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
2011-11-01 23:37:51 Jan Schneider Comment #40
Assigned to Michael Slusarz
Taken from Horde DevelopersHorde Developers
State ⇒ Resolved
Reply to this comment

[Show Quoted Text - 14 lines]
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!

[Show Quoted Text - 10 lines]
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.
2011-11-01 23:21:33 Michael Slusarz Comment #39 Reply to this comment

[Show Quoted Text - 12 lines]
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.
2011-11-01 23:21:33 Git Commit Comment #38 Reply to this comment
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
2011-11-01 22:52:52 Jan Schneider Comment #37 Reply to this comment
Fun note: the test task is then run on each and every ajax request. :)
2011-11-01 22:50:13 Jan Schneider Comment #36 Reply to this comment
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.
2011-11-01 22:12:48 Jan Schneider Comment #35 Reply to this comment
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.
2011-11-01 22:07:15 Jan Schneider Comment #34 Reply to this comment
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.
2011-11-01 18:40:15 Michael Slusarz Comment #33 Reply to this comment
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:

<?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');
     }
}
2011-11-01 09:26:29 Jan Schneider Comment #32 Reply to this comment
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.
2011-10-11 04:41:02 Michael Slusarz Comment #31 Reply to this comment
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).
2011-10-11 04:30:34 Michael Slusarz Comment #30 Reply to this comment
- 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.
2011-10-10 10:24:38 Jan Schneider Comment #29 Reply to this comment
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().

2011-10-10 07:55:29 rsalmon (at) mbpgroup (dot) com Comment #28
New Attachment: horde_debug_runtask.txt Download
Reply to this comment
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',

2011-10-10 04:38:48 Michael Slusarz Comment #27 Reply to this comment
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.
2011-10-10 04:34:32 Michael Slusarz Comment #26 Reply to this comment
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.
2011-10-07 14:07:44 Jan Schneider Comment #25 Reply to this comment

[Show Quoted Text - 28 lines]
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.
2011-10-07 12:21:01 rsalmon (at) mbpgroup (dot) com Comment #24
New Attachment: horde_debug.txt Download
Reply to this comment
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 ?


2011-10-06 17:24:40 Michael Slusarz Comment #23 Reply to this comment
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.
2011-10-06 17:22:16 Michael Slusarz Comment #22 Reply to this comment
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.
2011-10-06 10:25:19 rsalmon (at) mbpgroup (dot) com Comment #21 Reply to this comment
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;




2011-10-06 10:24:47 rsalmon (at) mbpgroup (dot) com Comment #20 Reply to this comment
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.
2011-10-06 08:47:18 rsalmon (at) mbpgroup (dot) com Comment #19 Reply to this comment

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 ?
2011-10-06 08:42:13 rsalmon (at) mbpgroup (dot) com Comment #18 Reply to this comment
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 ?






2011-10-05 19:53:48 Michael Slusarz Comment #17 Reply to this comment
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.
2011-10-04 08:37:41 Jan Schneider Comment #16 Reply to this comment
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"]
2011-10-04 08:29:34 rsalmon (at) mbpgroup (dot) com Comment #15 Reply to this comment
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 ?

2011-10-03 09:32:33 rsalmon (at) mbpgroup (dot) com Comment #13 Reply to this comment
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;}

2011-06-07 05:32:19 Michael Slusarz Comment #12
Assigned to Jan Schneider
Taken from Michael Slusarz
Reply to this comment
This works perfectly for me, so I can't debug anymore.
2011-05-25 12:00:23 Jan Schneider Comment #11 Reply to this comment
Didn't make any difference for me.
2011-05-25 07:25:13 Michael Slusarz Comment #10 Reply to this comment
I think I correctly fixed this.
2011-05-25 07:24:47 Git Commit Comment #9 Reply to this comment
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
2011-05-24 16:51:01 Jan Schneider Comment #8 Reply to this comment
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.
2011-05-24 16:06:38 Michael Slusarz Comment #7 Reply to this comment
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.
2011-05-24 16:03:28 Michael Slusarz Comment #6
Assigned to Horde DevelopersHorde Developers
Reply to this comment
Can't reproduce.  IMP tasks run fine.
2011-05-24 09:49:28 Jan Schneider Comment #5 Reply to this comment
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.
2011-05-24 05:15:49 Git Commit Comment #4 Reply to this comment
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
2011-05-24 05:15:44 Michael Slusarz Comment #3
State ⇒ Feedback
Version ⇒ Git master
Reply to this comment
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.
2011-05-20 07:53:26 Jan Schneider Version ⇒
Queue ⇒ Horde Base
 
2011-05-20 07:53:09 Jan Schneider Comment #2
Summary ⇒ Login tasks don't work
Priority ⇒ 3. High
Milestone ⇒
Reply to this comment
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.
2011-04-01 09:03:43 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 2. Medium
Summary ⇒ rename_sentmail login task doesn't do anything
Queue ⇒ IMP
Assigned to Michael Slusarz
Milestone ⇒ 5
Patch ⇒ No
Reply to this comment
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.

Saved Queries