[Tickets #10903] Re: IMP don't use correcty the selected address books list after logout and new login

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10903
------------------------------------------------------------------------------
  Ticket             | 10903
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | IMP don't use correcty the selected address books list
                     | after logout and new login
  Queue              | IMP
  Version            | 5.0.17
  Type               | Bug
-State              | Assigned
+State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Jan Schneider, Michael Rubinsky, Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2012-01-29 22:27) wrote:

> I can't reproduce this locally, but on demo.horde.org. And there is  
> something really, really strange going on.
> The values in the database are indeed correct. But  
> $GLOBALS['prefs']->getValue('search_sources') in  
> IMP::getAddressbookSearchParams() returns a JSON string with all  
> address books. It's not the default value either (isDefault()  
> returns false and getDefault() does not return all address books).  
> This got to be some side-effect like variable pollution or something.

My guess is that the Turba upgrade task is overwriting the value on  
every login, since it directly writes to IMP's preference.  Which  
would only happen if you are not using a sticky preferences backend.

Really not sure I like the idea of allowing applications to overwrite  
preference data for other applications, even for upgrade purposes.   
Looking at git blame, I'm the one that originally committed the code,  
but it looks like that was just because I merged several upgrade tasks  
objects, not because I reviewed the code myself.

Looks like Michael R. did the original upgrade task (see git commit  
0d7c106e48d0bea9b63eb0d892d1d0b8e16b933c).  Guess I will open this up  
for comments.  My personal belief would be either to nix the Turba 2.2  
upgrade tasks completely, or at least purge the imp/kronolith upgrade  
tasks. I have no problem requiring users to manually upgrade these  
preferences in this unique situation.