[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         | Jan Schneider <jan at horde.org>
  Summary            | Login tasks don't work
  Queue              | Horde Base
  Version            | Git master
  Type               | Bug
-State              | Feedback
+State              | Resolved
  Priority           | 3. High
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Jan Schneider, Michael Slusarz
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2011-11-02 00:37) 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.

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.