558123 - [RFE] Pass original folder name,too, when passing an email to the archive

Status: RESOLVED WONTFIX

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[pettyRed]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2
Build Identifier: 3.0.*

Archiving an email causes a loss of information regarding the name and position of the original containing folder in Thunderbird 3.*+ 

Although searching single emails was greatly enhanced by TB 3, there is no way to view -for instance- all mails originally placed in the folder "college-mates". If I made the mistake of archiving my emails in that very folder, all previous sorting and filtering would have been in vain, as folder-affiliation is lost the moment I archive it.


Therefore I would like to propose the following solution:

Each email being passed into the archive gets a new field/tag/database-column "folder of origin" containing all information needed to hypothetically reinstall an email to its previous folder. One should be able to sort all mails in the archive by this field to find emails with common origin. Also, a new function "recover/rebuild" should be available passing an email from the archives back to the original folder.

Extension:
Instead of searching for an email by sorting of the field "folder of origin", a new function "preview folders of origin" would be nice. This function would list all "original folders" already mentioned in the archives, thereby helping to find single emails or helping to rebuild entire lists of emails I need.

Reproducible: Always

Comment 1

[Nathan Tuggy (:tuggyne)]

Looks like a duplicate of bug 546292 -- if that's not correct, please reopen this bug and give a reason or two why they're different. Thanks for filing!

Comment 2

[pettyRed]

Whereas the motivation (loss of folder structure) is the same, the proposed solution is slightly different:

[url=https://bugzilla.mozilla.org/show_bug.cgi?id=546292]Bug 546292[/url] asks to maintain a visual folder structure within the archive.

I ask to pass information of original folder structure (without necessarily showing it) when archiving an email such that one can later on search by "former folder" and possibly rebuild it once one moves the formerly archived email back. 

[i]
(As I am new to this forum, I am new to the processes by what you discuss and structure possible enhancements. This is why I am unsure if that difference above is considered significant or not ... also, I do not know how to 'reopen' a bug nor whether setting its status from 'resolved' to 'unconfirmed' would be considered rude.)[/i]

Comment 3

[Nathan Tuggy (:tuggyne)]

(In reply to comment #2)
> Whereas the motivation (loss of folder structure) is the same, the proposed
> solution is slightly different:
> 
> [url=https://bugzilla.mozilla.org/show_bug.cgi?id=546292]Bug 546292[/url] asks
> to maintain a visual folder structure within the archive.
> 
> I ask to pass information of original folder structure (without necessarily
> showing it) when archiving an email such that one can later on search by
> "former folder" and possibly rebuild it once one moves the formerly archived
> email back. 

Yes, that is a difference; perhaps this bug should be set as a dependency of that one, instead, since it's chiefly about the internal metadata required to differentiate original folder, rather than the possible UI that exposes it. That is: bug 546292 (or rather, bug 522761, which I'm duping bug 546292 to) might require something like this bug to be implemented, but not the other way around.

> [i]
> (As I am new to this forum, I am new to the processes by what you discuss and
> structure possible enhancements. This is why I am unsure if that difference
> above is considered significant or not

It's a judgment call, but in this case I think you're probably right. (Strictly speaking, it's rare for anyone to be perfectly sure, especially since the most experienced members here usually have the least time to think about things.)
I'll reopen accordingly, and consider setting blocking as well.

> ... also, I do not know how to 'reopen' a bug

Use the Status drop-down below the comment box, and set it to UNCONFIRMED (if available) or REOPENED (otherwise). (I've done that already in this case, since I think you're probably right and this bug should be reopened.)

> nor whether setting its status from 'resolved' to 'unconfirmed' would be
> considered rude.)[/i]

It's not rude if you have a good reason, no, or even if you just honestly think you do; if you're cantankerous or obstinate, then yes it is. (You're the bug's reporter, after all, so you have a unique position of knowledge about it. As long as you're clearly making use of that, it's not a problem.)
It's especially not rude if you're right ;)

Comment 4

[Jim Porter (:squib)]

Given that we fixed bug 546292 (by way of bug 522761), I think it's safe to say that that's the recommended method to handle this. Resolving as WONTFIX. If you still think this is important and the current solution doesn't work, feel free to comment here and we can reopen this bug to discuss it more.