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 343969 - Canceling namespace setting doesn't work
Canceling namespace setting doesn't work
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
2.8.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-06-06 02:29 UTC by Jeff Cai
Modified: 2017-08-08 20:29 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Jeff Cai 2006-06-06 02:29:51 UTC
Please describe the problem:
If you uncheck "Override server-supplied folder namespace" checkbox, the folder list on the left folder view window doesn't changed after you restart Evolution.

Steps to reproduce:
1.Click menu: Edit->Preference->Mail Accounts 
2.Select an IMAP account and click Edit.
3.Click tab "Receiving Options"
4.Check "Override server-supplied folder namespace" and input a folder name which is contained in you IMAP server.
5.Close and restart Evolution. Now you can only see that folder you just typed. Other folders are invisible.
6.Repeat 1-3
7.Uncheck "Override server-supplied folder namespace"
8.Close and restart Evolution.



Actual results:
Other folders are still invisible after not using the folder namespace.

Expected results:
I expect to see all my folders if i don't specify any folder namespace.

Does this happen every time?
Yes.

Other information:
Comment 1 André Klapper 2006-06-08 11:35:17 UTC
account type is plain "IMAP" and not "IMAP4rev1", i guess?
Comment 2 Sam Morris 2006-10-18 00:16:24 UTC
Surelt this bug and bug #320284 can not both be true simultaneously?
Comment 3 Matthew Barnes 2008-03-11 00:27:03 UTC
Bumping version to a stable release.
Comment 4 André Klapper 2012-06-17 17:20:59 UTC
Jeff: I cannot reproduce this in 3.2.3. Is this still a problem in 3.4.2 or 3.2.3, or can this be closed as RESOLVED OBSOLETE?
Comment 5 André Klapper 2017-08-08 20:29:33 UTC
(In reply to André Klapper from comment #4)
> Jeff: I cannot reproduce this in 3.2.3. Is this still a problem in 3.4.2 or
> 3.2.3, or can this be closed as RESOLVED OBSOLETE?

Closing as obsolete. Please reopen if this still happens in 3.22 or later.