Closed Bug 652432 Opened 14 years ago Closed 14 years ago

Search all messages results does not identify folder location / path

Categories

(Thunderbird :: Search, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 570787

People

(Reporter: stfkerman, Unassigned)

Details

(Whiteboard: [dupeme])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 Build Identifier: ALL Most of the time, search results are almost useless because only the name of the folder containing the message is identified without the path to it. Reproducible: Always For anyone except the most beginning user, mail folders are likely to be organized in a multi-level hierarchy. The folder in which a searched for message is located may not be unique or even if unique, its location may not be obvious. Without a a path to the folder I often find myself unable to find the actual folder where the message is located without spending minutes looking here and there by trial and error. I often find myself searching the Windows file system with Windows Explorer to find the folder(s) whose name(s) were reported by Thunderbird SEARCH because the TB SEARCH does not provide a path. An application user should not need to delve into the Windows file system to perform such a basic function.
There are 2 search types, and you haven't identified which one you are talking about or listed, steps. But perhaps you mean "Search all messages"? And Bug Summary is not descriptive of the problem. I'm pretty sure such a bug report already exists, although I doubt the guided bug form is much help.
Component: General → Search
QA Contact: general → search
Summary: Search function is essentially useless → Search all messages results does not identify folder location / path
Whiteboard: [dupeme]
If there are 2 search types, what are the 2? "Search all messages" and search what? "And Bug Summary is not descriptive of the problem."? Huh??? Very cryptic. Please explain what that means.
surely you are familiar with "Search Messages" (ctrl+shift+F or edit > find > Search Messages) which has existed forever? "Search function is essentially useless" is an expression of sentiment, not a technical description of the issue to help someone understand the issue. If in bugzilla you click the word Status it gives you "The bug summary is a short sentence which succinctly describes what the bug is about."
Maybe I'm missing something but your question seems to me to be about a distinction without a difference. As far as I can see, whether the message search function is invoked using (1) the CTRL-SHIFT-F keys, (2) the EDIT/FIND/SEARCH MESSAGES or (3) by right clicking on a mail folder, the same search specification window comes up and the same results are reported: the name of the folders containing matching messages with no paths to any of the folders. So how does it matter which method is used since they all produce the same results: the names of folders that often are buried a layer or two down in one of dozens of possible places in the folder hierarchy. "Search function is essentially useless" may indeed be an expression of my sentiments rather than a technical description of the issue but the problem was described clearly enough for anyone to understand. You continued: "If in bugzilla you click the word Status it gives you 'The bug summary is a short sentence which succinctly describes what the bug is about.'" If I understand correctly, you seem to be complaining about my failure to adhere to form even though the substance is perfectly clear. I thought what I was saying was clear enough for anyone to understand but I will be more careful to cross all the "T"s and dot all the "I"s in the future. But contrary to what you stated, when I click the word STATUS it gives me: "STATUS - RESOLUTION - The Status field indicates the current state of a bug. Only certain status transitions are allowed." which does not match what you stated. Perhaps you are talking about clicking the word STATUS in some other context which you did not state.
> the problem was described clearly enough for anyone to understand. no it is not. because you have not specified which search function, and the solution rendered depends on which function you are using. In addition, "Search all messages" has in effect two results screens, the initial "facet" results screen, and the more traditional message list returned by "Open as list". it will help if you use the bug submission which asks for a list of steps to reproduce the problem. > Perhaps you are talking about clicking the word STATUS in some other context which you did not state. yes. I don't drink coffee, and today I'm suffering lack of sleep.
Although I did not originally state which search function I was talking about, I *did* specify in the previous message: ALL. I don't know where to find "the more traditional message list returned by OPEN AS LIST". I have never seen such a command or list. Search results I've seen are always reported as a list of messages with 7 possible columns which can be individually enabled or disabled, as in so many other list screens. One of those columns is the LOCATION column, which as I stated from the gitgo, states the name of the folder but no path and in a hierarchically organized folder system, folder names can be duplicated many times over and the location of any one of them is likely to be buried below the top layer, only to be found by trial and error or the user's recollection of where the folder is located. But I repeat myself.... Whether you are suffering from lack of sleep or coffee, you STILL have not answered the question as to in what context clicking on STATUS produces the result you stated or what needs to be clicked on to produce that result.
> Perhaps you are talking about clicking the word STATUS in some other context which you did not state. Have a look at the bug form - I meant click on "Summary"
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.