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

bugs at horde.org bugs at horde.org
Tue Jan 31 03:38:23 UTC 2012


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              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Jan Schneider, Michael Rubinsky, Michael Slusarz

Michael Slusarz <slusarz at horde.org> (2012-01-30 20:38) wrote:

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

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  

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

More information about the bugs mailing list