[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
Mon Jan 30 15:05:08 UTC 2012


Ticket URL: http://bugs.horde.org/ticket/10903
  Ticket             | 10903
  Updated By         | Michael Rubinsky <mrubinsk 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 Rubinsky <mrubinsk at horde.org> (2012-01-30 15:05) wrote:

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

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.

> Really not sure I like the idea of allowing applications to  
> overwrite preference data for other applications, even for upgrade  
> purposes.

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  

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?

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

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.

More information about the bugs mailing list