After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624701 - Evolution should allow to fetch local mail even in "offline" mode
Evolution should allow to fetch local mail even in "offline" mode
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
2.30.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 624738 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-07-19 06:39 UTC by Olivier Berger
Modified: 2021-05-19 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Olivier Berger 2010-07-19 06:39:33 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.
Comment 1 Olivier Berger 2010-07-19 06:47:11 UTC
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.
Comment 2 Leandro Guimarães Faria Corcete DUTRA 2010-10-12 18:56:04 UTC
Any news on ðis front?
Comment 3 Matthew Barnes 2010-10-12 19:07:00 UTC
*** Bug 624738 has been marked as a duplicate of this bug. ***
Comment 4 Tilo Hacke 2010-10-21 17:50:18 UTC
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 ?
Comment 5 Matthew Barnes 2010-10-21 17:54:42 UTC
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.
Comment 6 Tilo Hacke 2010-10-21 17:57:35 UTC
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...
Comment 7 Tilo Hacke 2010-10-21 18:34:53 UTC
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 ...
Comment 8 jlquinn 2011-10-29 05:51:17 UTC
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?
Comment 9 André Klapper 2021-05-19 11:12:18 UTC
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.