Marking as resolved per my testing and this commit:



http://lists.horde.org/archives/cvs/Week-of-Mon-20061120/063224.html



However there was a lot of code changed, so please feel free to 
re-open this. I'm just closing it so it doesn't get lost sitting in 
feedback.

actually I guess this wasn't necessarily limited to LDAP

Merging in some comments for clarity:



"I use ldap backend for preferences.

In horde+imp last_login works.

In horde+imp+ingo last_login does not work anymore.



When imp loads preferences, it load horde preferences as well.

In that step it set last_login with the ldap value,

"display" last_login value

and set last_login to current time.



When ingo loads preferences, it load horde preferences as well.

In that step it set last_login with the ldap value and the

last_login value from imp is lost."



"I think this is actually a general flaw in the Prefs code, in that it 
will load Horde preferences regardless of whether they're already 
loaded. This is a waste and also, as you diagnosed, can result in 
overwriting unwritten values.



I'm still puzzling out the best fix; your way does work, but I think 
we'll arrive at something a bit different eventually. Needs to be 
fixed for at least the SQL driver as well, possibly more."

Bug 3390 has a better description of what goes on here, though - and 
calling store() explicitly is not the correct solution.

In BUG #2829 The reply was given as "

last_login is not an IMP preference. You probably upgraded from an IMP 
3 version and didn't follow the upgrade instructions."



This was a **NEW** and fresh installation ! Therefore the allocated 
state "bogus" is incorrect. Also the Solution is definitely not 
applicable. Would request the team to look at this problem again .



The full details are explained in bug # 2829, we would like to point 
out that the <<last_login>> is also a horde framework pref and not an 
Imp as implied by the response.

NO.  This is the exact same bug report as Bug #2829 which was both 
marked bogus and provided the solution to your problem.

Background:

I'm using the Horde-Framwork with imp and ingo.

In the Horde configuration I have choosen (Authentication):

   Let a Horde application handle authentication: imp



The preferencies backend is LDAP.







When I'm including ingo in imp then the last_login preference from 
Horde is not stored in the preferencies-backend!



Reason:

- When imp comes up the preferencies are retrieved  (Horde and IMP prefs)

   The old value for last_login is retrieved

- horde/lib/Horde/Auth.php sets the new value for last_login

- Then Ingo retrieves the preferencies (ingo is used in imp)

   The preferencies from HORDE and INGO are retrieved

- At this time the HORDE-Prefs are retrieved a second time and the 
previous set last_login attribute is overwritten!

- After this the HORDE-preferencies are stored back to LDAP the first 
time in this session.



Resolution:

Store the new "dirty-value" for last_login after setting it:



Code snippet from horde/lib/Horde/Auth.php:

(Last line added)



      // Set the user's last_login information.

      $last_login = array('time' => time(),

                                    'host' => 
@gethostbyaddr($_SERVER['REMOTE_ADDR']));

      $GLOBALS['prefs']->setValue('last_login', serialize($last_login));

      //NEW: ************************Store it ! *********************

      $GLOBALS['prefs']->store();

      //END NEW ************************