Prefs overwrites modified Horde prefs in some cases

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

Tue, 25 Oct 2005 14:38:03 +0000

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

NO. This is the exact same bug report as Bug #2829 which wa

Tue, 25 Oct 2005 15:53:11 +0000

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

> NO. This is the exact same bug report as Bug #2829 which

Mon, 07 Nov 2005 13:46:57 +0000

> NO. This is the exact same bug report as Bug #2829 which was both > marked bogus and provided the solution to your problem. 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 <> is also a horde framework pref and not an Imp as implied by the response.

Bug 3390 has a better description of what goes on here, thou

Sun, 09 Apr 2006 00:16:10 +0000

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

Merging in some comments for clarity: "I use ldap backend

Wed, 22 Nov 2006 20:11:34 +0000

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

actually I guess this wasn't necessarily limited to LDAP

Wed, 22 Nov 2006 20:15:42 +0000

actually I guess this wasn't necessarily limited to LDAP

Marking as resolved per my testing and this commit: http:

Thu, 23 Nov 2006 04:49:05 +0000

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.