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