Changes have been made in Git (develop):

commit 39fbacfc7df53a6dd2dcfe0feddf1bc8a411fb3f
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Feb 7 20:29:52 2012 -0700

     Bug #10903: Remove Turba 2.2 upgrade tasks.

  turba/docs/UPGRADING                        |    4 +
  turba/lib/LoginTasks/SystemTask/Upgrade.php |  252 
---------------------------
  2 files changed, 4 insertions(+), 252 deletions(-)

http://git.horde.org/horde-git/-/commit/39fbacfc7df53a6dd2dcfe0feddf1bc8a411fb3f

Removed Turba 2.2 upgrade tasks.  Added note to UPGRADING indicating 
those upgrading from Turba 2.x must be running at least Turba 2.2.

Changes have been made in Git (master):

commit 39fbacfc7df53a6dd2dcfe0feddf1bc8a411fb3f
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Feb 7 20:29:52 2012 -0700

     Bug #10903: Remove Turba 2.2 upgrade tasks.

  turba/docs/UPGRADING                        |    4 +
  turba/lib/LoginTasks/SystemTask/Upgrade.php |  252 
---------------------------
  2 files changed, 4 insertions(+), 252 deletions(-)

http://git.horde.org/horde-git/-/commit/39fbacfc7df53a6dd2dcfe0feddf1bc8a411fb3f

Agreed, and the upgrade task in question wasn't really meant to be run 
for a H3->h4 upgrade anyway. As stated previously, the user should be 
fully upgraded to the latest H3 before attempting an in-place upgrade 
to H4. I agree this can be removed.
I agree. Though I think we need to think about how this might be 
handled in the future if there is a similar format change in one 
application that affects other applications that might store it's 
data. Turba/IMP is the only example I can think of at the moment. In 
H4, this would be handled by migrations, but would still require 
*some* knowledge of the other application. Thinking about this some 
more, this type of change should probably be considered a BC break 
anyway and not be implemented within the same major version number, so 
I guess this point is really moot anyway.

Here's how:

1. User authenticates to IMP.  IMP is upgraded to 5.0.  For ease of 
discussion, we will assume that the default value of the pref is 
present, so IMP doesn't actually do anything at all.  The current 
value of the search_sources pref is therefore a json encoded array.
2. Turba is authenticated to.  Turba is upgraded to 2.2.  Turba only 
checks to see if the search_sources entry exists in IMP.  It doesn't 
check whether it is a JSON encoded array, or even if it is the default 
value (in which case it should never be converted - the default value 
is always assumed to be correct).  Thus garbage is added to the 
search_sources parameter, which is then saved.

FWIW, the SystemTask upgrade system was never designed to upgrade 
anything other than a full H3 -> H4 upgrade.  It was not designed to 
upgrade between H3 versions.

Not to mention that this upgrade task is not tenable.  It is possible 
that the format of search_sources may change format in 5.1.  And then 
again in 5.1.1.  And then again in 5.1.2.  The point being that since 
this code, which directly alters the preference, can not be reliably 
tracked since it isn't within the application causing the changes.  As 
seen - I just became aware that there was something altering 
search_sources outside of scope a few days ago.  This is a bad 
situation.

The more I think about this, the more I think we need to rip it out 
immediately.

Yes, we do.

As I understood our demo setup, the Prefs backend *is* sticky, at 
least until the EC2 instance is re-spawned. Gunnar could answer this 
part better though.
I have mixed feelings on this. My feelings are that in this case, it 
was better to err on the side of useability than on the side of 
application data isolation. IIRC, leaving the IMP data alone would 
cause prefs in IMP to show as populated, but yet none of the values 
would be honored, since Turba would report the address books as being 
invalid.

I'm also not sure why this would actually cause the problem that we 
are seeing. Yes, the pref is overwritten, but the values that do not 
need updating are preserved...am I misunderstanding what you are saying?
If someone is upgrading to Turba 3.x from pre-Turba 2.2 code, I don't 
have a problem requiring them to either upgrade to 2.2+ first. I 
believe we already do this with some of the apps anyway.

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.

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.

The domain of my email address is wrong. The correct domain is
    @ch-moulins-yzeure.fr

Regards,
--
Christophe

By default, IMP uses all address books.

If you remove an address book from the list of address books selected 
in the preferences of IMP, the table horde_prefs is updated correctly. 
IMP uses the correct address books.

After logout and new login, if you return see the preferences of IMP, 
all address books are in "selected address books" list.

I can reproduce this bug with the site demo.horde.org.

Regards