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

* Your Email Address
* Spam protection	Enter the letters below: .__..__ .__..__ __ \| \|[__)\| \|[__)/ ` \|__\|[__)\|__\\| \__.
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. >> >> 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.
Attachment
Watch this ticket

Saved Queries