GNOME Bugzilla – Bug 207481
Apply store configuration changes without requiring a restart
Last modified: 2013-09-05 11:47:42 UTC
Package: Evolution Priority: Normal Version: 0.12.99 Synopsis: "Apply filters to new messages in INBOX on this server" does not take effect until restart. Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: Checked Apply filters to new msgs, but the setting did not take effect until I restarted Evolution. The same thing happens when unchecking this option. Using Cyrus IMAP4 v1.5.19 server over an stunnel connection, Aug 16 2001 snapshot
Hrm. I could swear that this is a duplicate, but I guess not. This is definitely a 1.0 bug- otherwise, many people are going to get the impression filters don't work.
One of the problems of using the store uri to pass such parameters. Maybe we need a generic store 'set parameter' call that can be used to post-apply parameters?
*** bug 212160 has been marked as a duplicate of this bug. ***
saying its store configuration, which is really what it is, the uri is just the mechanism. Not sure we can do this by 1.0 although *basically* its probably not that hard by the mechanism above.
If we can't do this by 1.0 should we move it to 1.1 now?
Maybe we can hack *just* the filter thing for 1.0, but there's no way we can make changing the IMAP namespace work, for instance. The 1.0 fix may be to just let the user know "Changes will take effect on restart". Um, without breaking the string freeze. We can just show an animated gif that mimes that.
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
marking with keyword "feature" because it kinda is. Maybe it's not really, I dunno.
Actually there are a lot of follow on effects of changing the store uri like this: - filters might include the uri which includes such parameters - shortcuts likewise - already opened folders, etc. There needs to be a separation of 'target store', i.e. server, port, user, password, auth, and other uri options, like indexing, namespaces, filtering, etc?
Yeah, agreed, putting the params into the URI was just wrong.
*** bug 212952 has been marked as a duplicate of this bug. ***
so the plan is to overload the new getv/setv CamelObject methods (which I've implemented for all the base classes now). If something changes that requires a reconnect, at the CamelService implementation of setv, it will disconnect and then connect again. one problem is that CamelSession will have to somehow be notified about the URL changes so that it can update it's service cache. danw suggested having: camel_session_service_setv (CamelSession *session, CamelService *service, CamelException *ex, CamelArgv *args); as a wrapper around camel_object_setv() so that the session could, after issuing a setv, update itself.
I've just implemented getv/setv for IMAP and it doesn't look like POP really needs it, since it is created/destroyed each time. Same goes for SMTP. Not to mention these don't really have anything specific to themselves that can change anyway. Minor problem with IMAP: since changing the namespace and/or whether or not to override the namespace (afaik) require a reconnect, I need to find some way of chaining this up to the camel-service implementation of setv. I *could* just create a special CAMEL_SERVICE_RECONNECT tag or something and reset any imap tags that require a restart with this new tag. Kinda kludgy perhaps, but overall not too bad?
this is gonna have to wait till 1.4
This has to wait at least until 1.6
Futuring for now unless there are advances on this. Please retarget if needed.
*** bug 251904 has been marked as a duplicate of this bug. ***
I also just encountered this bug. It's really annoying and takes a long time to figure out why changing the setting does not work. Because the bug has been around since 2001 (and not yet solved), I suggest adding a 'warning dialog' box saying you have to restart evolution to prevent other people from hitting the same rock until the matter has been resolved.
this is actually "fixed" in 1.5 - the store gets ripped out of the folder tree and re-added with the new settings. still not resolved the way we'd like tho, which is that we want to simply apply changes without needing to rip the tree out (tho that might not always be possible anyway? namespace change/etc?)
Hi, I filed recently http://bugzilla.gnome.org/show_bug.cgi?id=267253 which was closed as dupe. IMHO it is a dupe of this one. As I described in #67253 I think this is really a serios security problem: People configure their mail account from "SSL: Never" to "SSL: Always" but the connection still doesn't use SSL and the password is transfered unencrypted although the user expects a secure connection. This problem should be taken more seriosly and at least a message box after applying the settings could tell the user that he has to restart until the changes take effect. Nevertheless I am a little bit upset how bug reports from users are handled here. :-(
*** Bug 258836 has been marked as a duplicate of this bug. ***
still in 2.6
*** Bug 335785 has been marked as a duplicate of this bug. ***
*** Bug 615240 has been marked as a duplicate of this bug. ***
*** Bug 667036 has been marked as a duplicate of this bug. ***
*** Bug 383213 has been marked as a duplicate of this bug. ***
*** Bug 521898 has been marked as a duplicate of this bug. ***
*** Bug 605484 has been marked as a duplicate of this bug. ***
*** Bug 675226 has been marked as a duplicate of this bug. ***
Hi, is the solution for these issues going to pushed out as an update or a new release? Regards Enrico
Enrico: This was already answered in bug 675226, anyway: The next stable version to likely include it will be version 3.6.0. Definitely not 3.4.x stuff.
*** Bug 537440 has been marked as a duplicate of this bug. ***
*** Bug 681574 has been marked as a duplicate of this bug. ***
mbarnes / mcrha: Could this get a status update on plans, please?
Only read comment #0, but I believe I fixed most all the places in Camel where we read a setting once at startup and then stash it for the rest of the session. The CamelSettings API largely fixed this. We now re-read the CamelSettings property every single time in every place where a setting is applicable. Closing as OBSOLETE.