[Tickets #9767] Re: Login tasks don't work

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/9767
------------------------------------------------------------------------------
  Ticket             | 9767
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Login tasks don't work
  Queue              | Horde Base
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 3. High
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Horde Developers, Jan Schneider
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-11-01 17:21) wrote:

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