Closed Bug 20879 Opened 25 years ago Closed 24 years ago

Support "dual_use_folders" = false

Categories

(MailNews Core :: Networking: IMAP, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: BenB, Assigned: jefft)

References

Details

(Whiteboard: [nsbeta2+][5/16])

Attachments

(1 file)

UW-IMAP server and others can't store msgs and subfolders in the same folder
(e.g. due to the mbox format), that's what the dual_use_folders in 4.x is for.

1.
The setting is at least not migrated (need to do more investigation on that).

2.
Another related problem: Subfolders w/o parent folders are not displayed.
for this mailboxes:

home (dir)
+-folder1 (file: mbox)
+-folder2 (dir)
  +-folder3 (file: mbox)

4.x writes this .mailboxlist, when all "folders" (including folder2) are
selected:

folder1
folder2/folder3

However, Mozilla displays neither folder2 nor folder3. To achive that, folder2
has to be included in .mailboxlist.

Proposed fix for 2. problem: Add folder2 to the Mozilla internal folderlist.
Yes, looks like the proposed fix is the right way for 2. I worked around this
problem by adding the "dir"-folders (like folder2) to .mailboxlist and 4.7 gives
me failed selects e.g. while 'searching including subfolders'.
QA Contact: lchiang → huang
I remember there was a problem for UW IMAP folders (bug#19045)
*** Bug 19045 has been marked as a duplicate of this bug. ***
Target Milestone: M14
The duplicate bug was targeted as M14 so I'm going to set it here.
I'm not aware of the "dual_use_folders" flag. David?
OK, I now annoint thee "aware of the dual-use folders flag". This flag says
whether a server supports dual use folders, as described at the top of this bug.
In particular, UW does not support dual use folders in the more primitive
mailbox drivers. The flag is an advanced imap server property - there's a ui for
it and everything in 4.5+
Depends on: 7511
Bug #7511 already covers the 2. problem, adding dependency.
Phil,
some of the consequences of the setting include:
- The above described folder list (2. problem / bug 7511)
- Don't try to select the folder, e.g. if you click on a folder-only folder,
don't display an error, but just display 0 msgs.
- "New folder" asks for the folder type
Depends on: 28916
Moving my remaining M14 bugs to M15 which is the next targeted milestone.
Target Milestone: M14 → M15
I'm hoping Jeff can take a look at this.
Assignee: mscott → jefft
Status: NEW → ASSIGNED
Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.
Target Milestone: M15 → M16
Not M16 stopper, marking M17.  Please add beta2 keyword if you think this is a 
beta2 stopper.
Target Milestone: M16 → M17
This is interop.  I'll mark beta2.
Keywords: beta2
Keywords: nsbeta2
Just did a grep on 4.7 code. We seem not using dual_use_folders prefs at all 
although they are presented in the UI. It basically does nothing. No one ever 
try to use whatever the value set to the pref. Whether a folder can be a msg 
only, folder only or both can be told by its associate flag. A folder with a 
\NoSelect flag tells that it cannot be a msg folder. I propose that we take out 
the pref from the UI because you cannot tell from the server capability 
response. You can only tell when specifically listing the folders.
jennifer? What do you think about taking out of the UI?
Jeff, 4.x Windows does honor the pref. If false, the new folder dialog selection
for "folder only/message only" is disabled.
em, enabled, of course.
Yes, the pref is only good for creating new folders. It's sort of front end 
UI pref not necessary the server pref (backend don't use it). You really cannot 
tell whether the server supports dual use of the folders or not. I think the 
name itself is misleading too. I believe most servers allow you to create 
whether a container mailbox or a message mailbox (I am not sure about Cyrus can 
have a hierarchy of mailbox folders. They might be a flat system.) Some can be 
both container and message mailbox. What we need to do in 6.0 is to allow users 
to specify whether they want to create a container mailbox or message mailbox in 
new folder dialog. No need for an UI element in the account manager pref.
To clarify whether a mailbox can be a container or a message folder is indicated 
by is name attributes flag. A container only mailbox will have the \Noselect 
flag set. A message only mailbox will have the \Noinferiors flag set. A folder 
can be a container and a message mailbox will have no \Noselect and \Noinferiors 
flag set.
Isn't it irritating for users of servers, which support dual use folders, if
they have to decide between (new) "folder-only" and "message-only" folders?
But, they don't really need to care. The next time they want to create a child 
of the to be created folder they will always be granted. I guess this is one of 
confusions we need to live with no matter which way we go. Either way is not 
optimal.
> The next time they want to create a child 
> of the to be created folder they will always be granted.

Sorry, I don't understand that. If I create a new folder, it has to be either a
noselect (=folderonly) or noinferior (=msgonly) folder. I do have to know before
creating it, what I will want to do with it. I do have to care, don't I?
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: [nsbeta2+][5/16]
Sorry not clear. When creating folders client don't get the chance to set the
\Noselect or \Noinferiors flag. It's all server specific implementation. When
creating a folder only mailbox we issue the following command:

1 create "foobar/"

when creating a message only mailbox we issue the following command:

2 create "shooshoo"

notice that folder only mailbox end with "/". It's all up to the server to set
\Noselect or \Noinferiors flag as it likes. Client doesn't get the control for
it. So for servers that allows both mailbox there is no difference between

1 create "foobar/"

vs

2 create "shooshoo"

they can create child of "shooshoo" by issuing

3 create "shooshoo/foofoo"

which will not be allowed in a uw server.
As this bug is initially described it seems to work fine for me - I've attached
my .mailboxlist which allows me to see all my folders and subfolders without
needing a subfolder to be listed individually.
jeff, ic. But I still think, we need to expose this difference in the UI, even
if it only means appending a "/" for the implementation. I think, I know UW-IMAP
to some extent :), but it was not clear to me, that I could create a folder-only
folder by just specifying "<name>/", before I saw it at Karen's examples. I dare
to claim, that less experienced users will come to the conclusion, that they are
not at all able to create folders within folders, unless we provide UI for it.
The server pref is less of a problem, because it can be specified by an
administrator.
I think we really need to involve the IMAP server people...Cc: jgmyers even he 
said that he is not familiar with UW IMAP......
Also there was bug 29926 updates regarding to "<name>/" folder name.
More investigate/follow-up:
Based on Jeff's opinion:
I have questions:
1) If after take out of the dual-use setup from Account Setup.
Does that mean that the new folder dialog need to be redesign? 
see bug 28254....after uncheck dual use folder from the IMAP server's Advanced 
dialog. The new folder dialog will display for asking users for folder-only or 
message only folders (I am thinking this way will be enough for users to know 
the restriction for specific UW IMAP when they are trying to create the folders) 
But if after take out the dual-use from preference....we need to think a way how 
UI can trigger for new folders dialog to display the normal new folder dialog 
for general IMAP servers or specific UW IMAP server.....I think that's why we 
have the preference setting on 4.x.
2) I agree Jeff that this is only control by server, but I also understand what 
Ben's concerns. We should think a way how desgin to handle this if take out the 
preference. Otherwise it will be just keep the same......
Ah, I think, I understand Jeff's original suggestion now. Jeff, is it save to
display the new folder dialog with a choice between folder-only and msg-only for
exactly all /NoSelect folders (i.e. only them)?
What about the INBOX? I never used it, but IIRC Karen's descriptions, it is
possible to create subfolders of the INBOX (i.e. propably won't have the
/NoInferior flag). Those subfolders would be single-use folders, but INBOX
isn't, i.e. INBOX propably won't have the /NoSelect flag.

In any case, we shouldn't even give the option to call the new folder dialog, if
the parent would be a /NoInferior folder.
Component: Networking - General → Networking - IMAP
Summary: IMAP: Support "dual_use_folders" = false → Support "dual_use_folders" = false
You should probably word the folder creation dialog so that the user is 
specifying a preference for messages or folders.  Don't tell the user that the 
server doesn't support both.  Something like:

The new folder will be for containing
  (*) messages   ( ) folders

I don't know if you have to explicitly tell the user that their server might give 
them a dual-use folder as a bonus.
Yes, Ben. It is safe to have a choice for users to choose whether to create a 
folder only or message only mailbox as John pointed out. This is the original 
suggenstion I have in mind. I want to get ride of the "sever support dual use of 
folder" pref in the {Account Setup | Server | Advanced} dialog. And have the 
user to choose what type of mailbox they want to create. We could have the 
default set to message only folder. We could also check with the parent folder 
node's attribute whether they have \Noselect or \Noinferiors to prevent user 
from creating a subfolder with \Noinferiors attribute. 
After discuss with Jeff.
Since this is regarding to Design issue.
I am thinking that we should bring up this issue in the issue meeting.
Cc: Seth -- since this will be involved new design for the folder dialog.
I mean "new folder dialog"
As of the 5-16-2000 mail issue meeting, the group decided to stick with the 4.x 
implementation. dual_use_folders pref stays in the Advanced server dialog box.

Karen, I am closing down this bug as fixed. The backend implementation is all 
there. You should open a new bug and assign to Seth to have the new folder 
dialog box pay attention to the dual_use_folder pref. The new folder dialog 
needs to bring up the choice of folder only or message only radio buttons. When 
choosing folder only mailbox the Ok button callback needs to append the "/" char 
at the end of the folder name and then calling imap service CreateFolder() 
method.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
> In any case, we shouldn't even give the option to call the new folder

> dialog, if the parent would be a /NoInferior folder.



What about this?

Summary: Support "dual_use_folders" = false → Support "dual_use_folders"
bug 28254 already logged before.
Summary: Support "dual_use_folders" → Support "dual_use_folders" = false
Yes, the entries in the new folder dialog parent folder pick list should grey 
out if folders have the \Noinferiors flag and not being selectable.
Sorry about the summary change, it wasn't intended. (I used Mozilla.)
Verified all the platforms:
WinNT 05-22-09-M16 commercial build
Linux 05-22-08-M16 commercial build
Mac 05-22-08-M16 commercial build

Now Netscape6 support "dual_use_folders" = false which associate with the dual 
use advance preference for some specifiec IMAP server now (ex. UW IMAP server)
user_pref("mail.imap.server.sspitzer.mcom.com.dual_use_folders", false);

Need to follow-up bug 28254 for New Folder dialog Design for this specific IMAP 
server....
Marking as verified!!
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: