[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
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 | 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
situation.
The more I think about this, the more I think we need to rip it out
immediately.
More information about the bugs
mailing list