Tickets :: [#5117] Unable to store preferences with ingo

6.0.0-alpha12

6/6/25

Summary	Unable to store preferences with ingo
Queue	Kolab
Type	Bug
State	Resolved
Priority	1. Low
Owners	wrobel (at) horde (dot) org
Requester	wrobel (at) pardus (dot) de
Created	03/14/2007 (6659 days ago)
Due
Updated	07/01/2011 (5089 days ago)
Assigned	04/13/2007 (6629 days ago)
Resolved	07/01/2011 (5089 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

07/01/2011 08:43:28 AM	Gunnar Wrobel	Comment #5 State ⇒ Resolved	Reply to this comment
This has been resolved in Ingo from Horde 4 as the preferences driver is pulled from the injector.

07/06/2008 04:13:59 PM	Jan Schneider	Deleted Original Message

05/12/2007 08:51:16 PM	Chuck Hagenbuch	Version ⇒ Queue ⇒ Kolab

04/13/2007 03:48:32 PM	Chuck Hagenbuch	State ⇒ Assigned

04/13/2007 03:28:32 PM	Gunnar Wrobel	Comment #4 Assigned to Gunnar Wrobel	Reply to this comment
I thought it would be best to provide a specific kolab driver in that case. This should avoid the ugly fix and I think I should be able to handle shares also.

04/13/2007 03:18:17 PM	Chuck Hagenbuch	Comment #3	Reply to this comment
Ping?

03/15/2007 04:16:33 AM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
The fix would seem to be to provide the password in ingo/lib/Driver/prefs.php when calling Prefs::singleton(), but that won't work for shares. I don't know enough about Ingo and shares, but it seems like shares + prefs storage simply can't work if the prefs backend requires a password.

03/14/2007 11:34:05 PM	wrobel (at) pardus (dot) de	Comment #1 Priority ⇒ 1. Low State ⇒ Unconfirmed New Attachment: framework-Prefs-Prefs-kolab.php_auth-fix_20070314.patch Queue ⇒ Horde Framework Packages Summary ⇒ Unable to store preferences with ingo Type ⇒ Bug	Reply to this comment
While the preferences system when running Horde on a Kolab server works fine most of the time, it fails when using it together with ingo. The issues has been around for a while. The problem is that the preferences driver does not receive a password in all cases. Ingo for example does not provide a password when calling the Prefs::singleton method. Using the Prefs/kolab.php driver fails in that case because the users password is necessary to store values in the LDAP tree. The attached patch fixes the problem but I admit that I am not certain at all if it is a valid fix. I failed to understand the reason why ingo does not provide a password when creating the preferences instance while other code segments do that. I assumed there might be a specific reason for that.