Reproduction: 1. Search a folder hierarchy on an UW-IMAP server Actual result: 2 error dialogs appear for each folder-only-folder that is included in the search (equal or below the selected folder): "... SELECT failed... not a selectable mailbox" "failed ... UID FECTH" Expected result: Folder-only-folders are not searched (only their msg-onyl subfolders). Additional Comments: Relevant checkbox is activated. Folder-only-folders recognized in folder pane.
reassigning to naving
This happens in 4x also. I think it is a UW:IMAP server problem because it should clean-up the folders that are no longer there.
Navin, are are misunderstanding this bug. It does not happen with 4.x. It is not about "folders that are no longer there", but about folders, that can contain only other folders, but no messages, i.e. are not "selectable" and cannot be searched. Nevertheless, they are subscribed and completely valid, since they are my only way to get to other lower-level folders, which do contain messages. Technically, folder-only-folders are directories on the server file system, while msg-only folders are mbox files. Both of them can be visibile ("subscribed"). So, the server does behave corrent. (Unless I'm missing something.)
*** Bug 92151 has been marked as a duplicate of this bug. ***
Yes! This problem is not occurring on 4.77. But, I can only reproduce this problem by uisng 08-02-06-trunk build: It shouldn't display this alert when search the msgs under the UW folderonly folder since it's possible to create sub-msgonly folders under the folderonly folder. And users should allow to search those msgs under the folderonly folder if they don't know which sub-msgonly folders that those msgs reside.... Updating the summary a little bit to specify this problem....
Created attachment 44467 [details] Attach the alert dialog screen shot when search msgs from the folder-only folders from UW account.
Actually after I select the OK from this alert. The search functionality is working from the UW folder-only folder. Just the alert shouldn't display, it will mislead users that it's not working......
> Just the alert shouldn't display, it will mislead users that it's not > working...... It's not only misleading. Search a large hierarchy, and you easily get 20+ errors during a single search.
naving and I talked about this. the two parts of the fix: 1) don't allow users to search "no-select" folders from the search picker. 2) when searching across an account, skip the no-select folders.
I already have fix for the 2nd part in my tree. I will attach it soon.
For the first part we need to add that rule to the picker, right ?
right, we need to extend the picker to have disabled menuitems when the folder is a no-select folder. since it's UI, feel free to leave that to me if your overloaded with back end bugs.
> don't allow users to search "no-select" folders from the search picker. No, no no! This is important functionality. E.g. I have a folder-only-folder for Mozilla, which contains folders (and other folder-only folders, e.g. Beonex) to sort the mails/bugmails after certain criteria. Sometimes, I remember a mail (about Mozilla), but can't remember where I sorted it. So, I search in all Mozilla folders. Searching the whole account is not an option, because that would search through probably 100.000 mails in 400 folders. Searching msg-folders is no option either, because I have about 50 folders under Mozilla. When it works for whole accounts, why deliberately disable it for subhierarchies? Illness healed, patient dead.
Yes. As I said: >users should allow to search those msgs under the folderonly folder >when they don't know which sub-msgonly folders that those msgs reside.... I think my opinion is the same as Ben.....
This patch should fix the problem in an ideal scenario, but the noSelect flags are not set correctly for some folders at start-up, investigating that part of the problem.
Do we have another uw:imap server, the one I am using is sspitzer.mcom.com and I think it does not return a correct LSUB response, or may be server does not want to return any flag (NoSelect, NoInferior) (trying to optimize).
benb is right, changing the UI is wrong. thanks for catching my mistake.
naving, are the folder-only-folders grey and italic for you in Mozilla? If so, they should already be recognized as folder-only-folder (which is a synonym to NoSelect folders, IIRC, not?). If not so, then check the file ~/.mailboxlist (or yourroot/.mailboxlist?) on the server (it's a textfile). Your folder-only-folders should have either no entry there at all (only their subfolders - the folder-only-folder will then be reported as subscribed automatically) or an entry with a trailing slash.
benb, that is not true for me. I find folder-only-folder there w/ no trailing slash. If we delete .mailboxlist will the server; regenerate the files.
> If we delete .mailboxlist will the server; regenerate the files. Was that a question? Yes, the file keeps your subscription list only. You can delete it, and the server will recreate it with good entries (I think - make a backup to be sure), when you use Mozilla to resubscribe to the folders. To be sure, do not check (subscribe) the folder-only-folders in Mozilla's subscribe UI, only the msg-only-folders which are their childs. The folder-only-folders should appear nevertheless. Alternatively, you can manually delete all entires (lines) for folder-only-folders in that file.
This is basically the first patch w/ minor changes to not search when we have a folder only folder with no subfolders. As benb notes , .mailboxlist should have subscribed folder only folder with / at the end. When this is true we explicitly do a list for folder-only folder that sets the no-select flag for that folder. I think that uwtest account is messed up because the .mailboxlist on the server does not have correct entries. It worksfine for me on that other acct. seth, please review.
fix checked in.
Verified on UW IMAP mail account for all the platforms: Users can search msgs from the subfolders of the folderonly folder now. Verified. Linux 10-15-05-0.9.4 WinNT 10-15-05-0.9.4 Mac OSX 10-15-11-0.9.4
verified here too. Thanks!