GNOME Bugzilla – Bug 624701
Evolution should allow to fetch local mail even in "offline" mode
Last modified: 2021-05-19 11:12:18 UTC
When fetchmail is being used to fetch mail, and evolution is configured to fetch its mail from local spool, the fetching mail button/menu option shouldn't be disabled by NM putting Evo to offline mode. This used to work OK, but changed recently. Now, in offline mode, there's no way to fetch local mail from the spool anymore (but adding a fake NM network configuration to put if virtually online) I suggest to never grey out the send/restore button/menu and only do online checks later in the execution of the fetching, where explicit remote servers only would be disabled according to online/offline mode. Thanks in advance.
FYI, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549451 in Debian discusses such annoyance (including the fact that one may wish to override the offline/online switching in Evolution to bypass NM's decisions). Hope this helps.
Any news on ðis front?
*** Bug 624738 has been marked as a duplicate of this bug. ***
Since this Bus seems not to be really worked on, i should suggest a workaround: To provide Evolution always with an "ONLINE" status. Does anyone know, from whe Evolutiion gets the Network Status ? Which files ? We could provide Evolution with "faked" ONLINE info and this type of problen never will arise again .... We also would not have to find out if it is a malfunctioning auto-esotheric network-tool, or evolution itsself. Since this type of problem is arising and vanishing (due to updated network tools) from time to time, i for myself have decided, that i do not need this auto-esotherich online check, and seeking for a means to disable it externally (i.e. indepenently from evolution) by pre-filtering the informatin evolution is drawing from the system. Has anyone suggestions how to do that ?
I've added a --force-online command-line option to 2.91 which overrides the network availability status reported by NetworkManager. That doesn't fully address the bug but provides an interim workaround.
P.S.: I already have done some research concerning the cause. Since replacing evolution by an older version did not help, i suppose, that the real reason has something to do with the network-manager...
I just solved the problem by removing network-manager. For me this is o.k , since this machine is a SUN w2100Z with a fixed ip. But perhaps this also could be a hint towards the real problem ...
A year later, and this is still open. It is now striking me on Debian testing. With the upgrade to Gnome 3.0, gnome-core pulls in network-manager. I have a static interface that network manager has been told is unmanaged. Perhaps the actual problem is that network manager is telling evolution that there's no available interface when that's actually untrue?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.