Closed Bug 114656 Opened 23 years ago Closed 18 years ago

allow arbitrary number of labels

Categories

(MailNews Core :: Backend, enhancement)

Product:
MailNews Core
Component:
Backend
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: johann.petrak, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.8.1, verified1.8.1.3)

Attachments

(4 files, 2 obsolete files)

snapshot of work in progress
189.20 KB, patch
Details | Diff | Splinter Review
patch ready for review
185.74 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review
add ui for creating a new tag
21.01 KB, patch
moco
: superreview+
Details | Diff | Splinter Review
fix message menu tags sub-menu
1.56 KB, patch
moco
: superreview+
Details | Diff | Splinter Review 
Instead of providing exactly 5 possible labels, let users define
an arbitrary number. Many users will be glad to work with more than 5.
Severity: normal → enhancement
Summary: [RFE] allow arbitrary number of labels → [RFE] allow arbitrary number of labels
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → laurel
I'm with you on this one.  I ran out of my 5 already.  But, for the moment
that's all we're going to be able to provide.  I hope that changes one day.
Assignee: sspitzer → ssu
Target Milestone: --- → Future
Status: NEW → ASSIGNED
Nominating; this is definitely something I'd want pre-1.0
Keywords: mozilla0.9.9
Jglick, here's a proposed solution for the spec: let's add a listbox, much like
the one in the Filter Editor window, where you can press a "More" and "Fewer"
button to dynamically add new rows.  Every row is exactly like the one in the
prefs right now, just that there would be a dynamic number of them.
*** Bug 137910 has been marked as a duplicate of this bug. ***
*** Bug 141695 has been marked as a duplicate of this bug. ***
The labels specification actually say:
A potential future feature would be to allow creation of additional [labels].

http://www.mozilla.org/mailnews/specs/labels/
I very much want more labels.
*** Bug 155069 has been marked as a duplicate of this bug. ***
Summary: [RFE] allow arbitrary number of labels → allow arbitrary number of labels
*** Bug 175480 has been marked as a duplicate of this bug. ***
I ran out of labels a LONG time ago, and expected more than five to be available
in each Mozilla version - and no luck so far.

Is there any specific reason why this is not implemented? By specific reason I
*don't* mean development time - that I understand, and I know how valuable it
is, being a developer myself. I'm just curious whether this is really difficult
to implement, or if there are any standards or recommendations against more than
five lables. Thank you!
*** Bug 197401 has been marked as a duplicate of this bug. ***
We need more labels too ! Labels is the only way to manually assign a category
to a message on the receiver's side (isn't it?).

So what is new about this enhancement ? Is it under development ?

*** Bug 229226 has been marked as a duplicate of this bug. ***
Is it possible to have this bug fixed finally? I tried emailing someone to ask
if this was in the works, but the person to which the bug is assigned has a
permanent email error. It would be very nice to have what I'm sure is a simple
bug fixed. Thanks!
The E-Mail addresses on this page were at netscape.com. They are no longer valid
I believe :-(

I just took a look at the sources. A maximum number of five labels plus the
special none label is hardcoded, so I could not play around with XUL/JS. I am
not a c++ pro, but as far as I understood the sources it would be quite easy to
allow a higher constant number of labels. But that would be absurd (as it is
now) because you would have n lines of nearly identical code in order to have n
labels. 

Allowing a really arbitrary number of labels would take a bit more effort I
think. But nevertheless it is a feature that I consider very important and I do
not understand why a constant number of labels was hardcoded in first place.

Markus can you maybe share the relevant code lines? It seems that one problem
that will arise when this bug is getting fixed is to figure out how to convert
the old label numbers to the new ones - since the old way of doing it will no
longer be possible (isn't this using some strange flag bits for the labels?). 
Converting old labels to the new ones should not be a significant problem,
because there can only be 5 old labels.  Recreating them in the new format
should not take anyone a long time.
As I said, I am not a c++ programmer, but I took a look at the file
nsMsgDBView.cpp and it has a lot of lines like that in it:

      case nsMsgViewCommandType::label0:
      [...]
      case nsMsgViewCommandType::label5:

So I thought one could easily add some more hardcoded labels (ok, some changes
to nsMsgDBView.h and the GUI would be needed, but that is not a problem, is
it?). But I would not consider this a clean solution. The maximum number of
labels should never be hardcoded.

But if nearly the entire label system was rewritten in order to provide an
arbitrary number of labels it is likely that the old format of storing them
might no longer be useful and thus many users would be angry because their
profiles would be broken. But on the other hand I agree with Dan. Who would
mourn over five lost labels if he gets the power to define an unlimited number
of them?

Maybe I am totally wrong, but since neither Sean Su nor Seth Spitzer seem to be
working on the label system any more I felt somebody should do at least
something on that really annoying bug.

If there is anybody with some decent c++ programming skills willing to do
something I would be glad to assist with my humble XUL/JS "knowledge".
> Who would mourn over five lost labels if he gets the power to define an
unlimited number of them?

The person who doesn't need more than 5 labels.  I for instance only use 3.  At
some point, I may want more labels, but I don't now.  And I know many people who
won't use more than 5.
Yes it seems the code is a bit of a hack and abuses flags to store label
information. This is a bit odd as flags would allow arbitrary sets of labels -
for mutually exclusive labels, an n-bit integer encoding would be better.
Another problem is that with an arbitrary number of labels we would need to
rethink the FE for assigning label texts and colors, and maybe also the way this
info is stored. The question is if a simple hack that would increase the number
of labels to e.g. 10 would be sufficient for this feature (having mutually
exclusive priority classes).
Many users who want more labels probably want something else: a way to assign
arbitrary *sets* of *keywords* to a message and allow formatting, searching etc.
based on these keywords. 
If people could define an arbitrary set of labels it would definitely make sense
to store the label colours, text and whatever more info in an rdf file rather
than in the prefs.js. I even think this is necessary in order to be able to
easily construct the GUI with <template>s. But I am sure somebody can think of a
dirty hack to convert old labels to new ones. 

Probably a simple hack to increase the number of labels (one could make them 20
and put only ten in the UI to prevent confusion...) would improve the situation
for the moment, but if MozillaNews is ever going to have a scoring system, an
arbitrary number of labels will be needed anyway. In fact it would be more or
less a primitive scoring system if we had an unlimited number of labels.
*** Bug 230882 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.9
*** Bug 246436 has been marked as a duplicate of this bug. ***
So is there anything happening on this, or am I heading back to Pegasus?
And in a more helpful vein - can I pay someone to do this for me?

How much?


With the advent of virtual folders (saved searches) in Thunderbird 0.9, I
believe this enhancement gains additional importance. Let's say, as in my case,
a person would like to lump all of his/her on-line orders together in a virtual
folder. The search rules can be modified to include places that person shops a
lot, such as amazon.com - but there needs to be a way to mark one-time-only
purchases as well. With an arbitrary number of user-defined labels (such as in
gmail for example), this is easy because the user can just define a label and
mark the message(s).
(In reply to comment #26)
> With the advent of virtual folders (saved searches) in Thunderbird 0.9, I
> believe this enhancement gains additional importance.

I agree with you.

Mozilla Thunderbird should support an 'unlimited number' of 'mutually
non-exclusive' labels.

Thus, it would be possible to use the Sieve IMAP flag extension more efficiently
http://www.melnikov.ca/mel/Drafts/draft-melnikov-sieve-imapflags-06.txt.

With that kind of feature, it would be possible to create a virtual folder per
label.

Also, the display of labels should be improved with bold, italic, underline and
strike following the example of Mulberry http://cyrusoft.com . Please, see
http://www.cmu.edu/computing/documentation/mulberry31using/mulberry31_use.html#userdefined


I hope this bug is going to be fixed soon.

Thanks for your work.
Product: Browser → Seamonkey
If the number of labels is increased, could a virtual folder correspond (by
default) to a label ?

IMAP keywords could be searched online permanently so that Thunderbird could
dislpay some kind of Gmail labels on the base on Thunderbird labels - because 5
virtual labelled folders are not enough.

Also, I definitely think Thunderbird labels should be mutually non-exclusive
mostly because it is possible to set several IMAP keywords on a message.

Unfortunately, Thunderbird can display only one IMAP keyword at a time.

Should another bug be created ?
what also would be great, that thunderbird could read labels set by other
programs (eg mulberry, etc).
(In reply to comment #29)

> what also would be great, that thunderbird could read labels set by other
> programs (eg mulberry, etc).

I think this could be neatly done by adding UI to bind (several) IMAP labels to
Thunderbird's colors. Then I would be able to paint "$Label2" (Thunderbird),
"Cyrusoft.Mulberry.02" (Mulberrry) and "$Work" (Melnikov's IETF Draft) in color
orange, meaning work whereever I had set the flag/keyword. :)

Shipping with these defaults would also be nice, but going for arbitrary labels
to satisfy GMail fans I would like the flexibilty to edit/add to this in the UI.

The best thing (only partly related) would be all clients using standardised
labels for the most common things ($Junk, $Work, $ToDO, $Personal, etc), see
<http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-melnikov-imap-keywords-02.txt>.

Roland.
*** Bug 281589 has been marked as a duplicate of this bug. ***
A related issue is bug 282366: modifying the text of existing labels.
I could really use a few more labels to keep track, sort and find particular
e-mails.  Hopefully someone could put some attention towards this increasingly
popular request.  With fingers crossed, improvements anticipated.
Add color labels in rules like in Apple Mail.
It would be nice to have automtically labelled e-mails upon receiving it.  It
would be nice to allow an e-mail to have multiple labels or categories (similar
to blog entries) See these posts on the forum for the features people would like
to have:

http://forums.mozillazine.org/viewtopic.php?t=223967
http://forums.mozillazine.org/viewtopic.php?t=220693
http://forums.mozillazine.org/viewtopic.php?t=222354
http://forums.mozillazine.org/viewtopic.php?t=219055
(In reply to comment #20)
[...]
> Many users who want more labels probably want something else: a way to assign
> arbitrary *sets* of *keywords* to a message and allow formatting, searching 
> etc. based on these keywords. 

Exactly! 

Please take a look to the thread in
http://forums.mozillazine.org/viewtopic.php?t=220693 to see this concept
explained. It start as:

> > But if we extend the idea, coupled with the already working 
> > virtual folders, we could have faceted classification. 
> > This makes easier to organize and find messages, like Gmail.

If Tb have this feature, almost every email heavy user would love it. :-)

As always, thanks for Tb guys. :-)

Regards...
I understand that it is not easily solvable, but I believe that i is really a
key enhancement. It is the only way to make VF really usable. Additional label
shoud be unlimited, not mutually exclusive and INDEXED. This is a key issue, as
the search made by VF is very slow and practically unusable on custimized
headers. The indexing (and the caching of VF) would make TB the only possible
choice. The easy alternative is Opera, less good than TB on many extents but
with an effective and quick VF system.
(In reply to comment #36)
> (In reply to comment #20)
> > a way to assign
> > arbitrary *sets* of *keywords* to a message and allow formatting, searching 
> > etc. based on these keywords. 
> 
> Exactly! 

Oh my, yes. I'd love to see something like flickr's tags, and to have the tags
able to be set by the filters. The lack of filters that can automatically set
tags/ categories/ what have you is the only thing keeping me from switching from
M$ outlook. 
It's amazing how far back this bug goes.  Is anyone working on it?

Yes, it does appear that the number of labels is hardcoded.  However, the
X-Mozilla-Status2: message header allots three bits for labels, allowing for
seven (plus None) labels.  It should be easy enough for anyone familiar with the
code to add two more cases in each place where it is hardcoded.  Coming from
Eudora, I can testify that even two additional labels would be a welcome relief,
though still not nearly enough.

But, adding any more than that would require a change in the message headers. 
That in itself is okay, but it is important that the label information (as all
status information) *does* remain in the message headers.
*** Bug 289545 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
I would love (better) labels in messages too. Saved searches are not the solution.

At regular bases I go check the latest builds to see whether this feature is
already implemented, but it never is. Opera Mail has it already for years! How
can Thunderbird ever expect to be the best free e-mail client (as firefox is)
without that?
Second the above - there are 40 people in the CC list for this bug, and 106
votes for it, yet it's getting on for 4 years old, and there's not even any
suggestion of when it might be fixed. Do any TB developers even care?
Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before
posting any more such comments. Thanks.
HeaderTools might a quick fix for some people
http://forums.mozillazine.org/viewtopic.php?t=279907


As far as fixing/coding - as Peter points out no amount of votes and comments
will get this fixed. And a TB developer is NOT "required" and should not be
assumed to take the lead.  Someone with time and coding ability can perhaps more
quickly kick start with the advise, if needed, of a developer. For anyone
seriously ready see
http://forums.mozillazine.org/viewtopic.php?t=271261&highlight=labels and then
ask for help in IRC seamonkey.  (you say you're not a coder?  OK, perhaps you
can find someone?)
No one has explicitly stated that one thing needed is <multiple lables per msg>.  Like gmail and zimbra.

...besides,
- unlimited lables to start with, plus 
- use of the X header in imap to keep track of the lables from multiple Imap clients. (bug 161482)  

Does the latter break proper semantics of X-headers?
Bill, those are separate issues and should be filed separately.
(In reply to comment #45)
> No one has explicitly stated that one thing needed is <multiple lables per
> msg>.  Like gmail and zimbra.

I asked the community about a gmail approach for Tb, but response was negative. However, I do completely accord with you. Unlimited label definition, with unlimited labels per message. 

Regards...
(In reply to comment #47)
> I asked the community about a gmail approach for Tb, but response was negative.
> However, I do completely accord with you. Unlimited label definition, with
> unlimited labels per message. 
> 
> Regards...

I also agree!  I've been playing with plugins, trying to create this functionality, but so far I've failed.  Clearly the gmail approach is something many people would benefit from. 
Hello.

> I also agree!  I've been playing with plugins, trying to create this
> functionality, but so far I've failed.  Clearly the gmail approach is something
> many people would benefit from. 

See http://forums.mozillazine.org/viewtopic.php?t=220693

Regards..

I am a programmer with about 14 years experience.  I know Delphi, VB.Net, C#, PERL, PHP, PocketPC and Compact Framework stuff.

I am starting on an extension to try and accomplish this.  I have my end goal extension planned and right now I'm creating simple extensions to learn how to hook into the menu, events, and GUI.

If someone is interested in helping me, I would like to find examples of extensions that accomplish some of the tasks my extension will need to do.  I am doing this in my spare time and I don't have much, so if would be a big help to look at other extensions for example code.

I need to know how to...

1) How to hook into the message filtering system.  Idealy adding a category should be a filter action, like any other.  The filtering system is very primitive, but I'll leave that for another project.

2) How to add an arbitrary field to an email.  I've heard there is an extension that can do it, but I can't seem to find it.  URL or Keywords for search would be helpful.

3) How to change the color of a mail item in the message list view.  I've tried experimenting with userContent.css, but I can't seem to change colors, fonts or anything.  I think it's a treeCell object but I'm not sure.



I'm considering assigning this bug to myself if Sean doesn't mind, or at least help get it moving.  I understand the basics of XUL and can add a hello world menu item, or toolbar button.  I'm having trouble figuring out how to hook into the deeper systems.  I'm not sure if this can be accomplished completely in XUL, or if it will require C coding as well.

If this is not the correct place to ask for such information, please direct me to a developer forum.

Thanks!
As someone who's wanted this fucntionality for years, can I just say *please* don't implement it using custom message headers. I use TB/Mozilla Mail exclusively with IMAP servers, and message labels are stored as IMAP flags while on the server. This data can be accessed by multiple mail clients in a relatively standard way.

I haven't looked at the TB code, so I can't comment with authority, but it seems to me that implementing an arbitrary number of labels as an extension would be likely to break its use with IMAP servers. The code to do 5 labels is already in the core - surely it's that that needs enhancing to do the job right?
(In reply to comment #52)
> As someone who's wanted this fucntionality for years, can I just say *please*
> don't implement it using custom message headers. I use TB/Mozilla Mail
> exclusively with IMAP servers, and message labels are stored as IMAP flags
> while on the server. This data can be accessed by multiple mail clients in a
> relatively standard way.
> 
> I haven't looked at the TB code, so I can't comment with authority, but it
> seems to me that implementing an arbitrary number of labels as an extension
> would be likely to break its use with IMAP servers. The code to do 5 labels is
> already in the core - surely it's that that needs enhancing to do the job
> right?
> 

I really don't know.  I'm still doing research.  I don't have access to an IMAP mail server so I can't test that.  I've been approaching it from an XUL/Javascript/CSS solution.  

It may be better to do in C, but there is a lot more work to setup my machine to do C development.  Currently I develop mostly on Windows and It would take a while to download the libraries required to do a full mozilla compile, whereas I can just open the JAR files and start changing XUL.  

A C solution has a much steeper learning curve and I'm not sure if I could get anything accomplished.  Possibly TB can access the IMAP fields you mention, or just custom headers or something if IMAP is not avaialable.  

I can say that if there is a hard coded list of 5 labels, then changing it to an arbitrary number of labels will not be a simple thing.  It will require it's own data store and some method of linking back to each message.  Also the current design has exclusive labels -- for instance you can only have Work or Important, but not both.  Changing things at the core of the project like this will no doubt have ripple effects that will affect other parts of the system that assume there is one and only one label.

Understand I have not looked at the C code yet, but I have worked on similar projects and this is no easy task.  I will keep in mind the IMAP fields and see if I can find an IMAP server somewhere I can work on.
(In reply to comment #53)
> I will keep in mind the IMAP fields and see
> if I can find an IMAP server somewhere I can work on.

Possibly not what you meant, but here's a free IMAP account: http://www.fastmail.fm/ ("Guest" account is free)
I think the concept of having unlimited labels, and a message being allowed more than one label is great.
However this is totally out of line with how labels currently work. Labels are currently conceived as more being a *state* a message is in.
The proposal is more similar to a way of *tagging* messages.
The way the labels are currently stored makes it possible to change them without changing the length of the message, because it simply rewrites the fixed-size X-Mozilla-Status2 header. If unlimited tags where supported this would not be possible (so for example HeaderTools has to rewrite the message and append it to the end of the folder). The only way to get around this would be to store the tagging information separately to the mailbox, which has its own problems.
Trying to use the existing X-Mozilla-Status2 header to store more then 7 labels would cause all kinds of other problems with existing mailboxes.
This is not something that can or should be implemented as yet another feature hacked into the code. This should be done rigth and this means that first, a back-end for storing arbitrary meta-data for emails should be implemented. Hence, this bug should be dependent on a bug that discusses/tracks this back-end. I wish there was a better place to discuss design issues esepcailly when the go beyond what would normally be put in a simple "bug" description. 

Without a proper backend for storing meta-data not only the labels feature but many other essential features cannot be implemented decently. 
(In reply to comment #56)
>...
> Without a proper backend for storing meta-data not only the labels feature but
> many other essential features cannot be implemented decently. 

there is already backend bug 161482.  Someone with better understanding than I can make it a blocker if that's appropriate.
Assignee: ssu0262 → mail
Status: ASSIGNED → NEW
QA Contact: laurel
(In reply to comment #57)
> (In reply to comment #56)
> >...
> > Without a proper backend for storing meta-data not only the labels feature but
> > many other essential features cannot be implemented decently. 
> 
> there is already backend bug 161482.  Someone with better understanding than I
> can make it a blocker if that's appropriate.
> 
No - that would be another hack and not a proper way to implement a meta-data backend. 

A decent backend should probably be based on SQLITE or similar. In any case this is complex enough to deserve some discussion. There should be a place to have developers discuss the different possibilities and how costly it would be to implement them. 
maybe instead of labels we should think in the direction of tags?
i.e. spontanously tagging an email message with as many tags as you want, and then later looking at all of the X tagged msgs by clicking on the tag or some search interface.
can be interesting.
X-Label is not useful for allowing the recipient of the message to add labels, at least with our mbox format. 

We're thinking of doing an implementation of arbitrary tags. We'd use keywords on imap servers that support keywords, and an x-mozilla-tags header for local mailboxes. That header would be similar to the x-mozilla-status headers we currently have. We'd insert an x-mozilla-tags header when we download mail to a local folder, and fill that in with bit values that correspond to user-defined tags when the user tags a message. We'd have a file in the profile that maps from those bits to the tag text. There would be a limit to the number of unique tags a user could have for local msgs, probably around 200, at least for those tags stored in the mail message itself.
Assignee: mail → bienvenu
If it's going to be a fixed amount of tags that could be stored in each mbox message, maybe it would be enough to have something like "255 tags" (with a correspondence list in each profile) and save "up to 8 tags" in each message. Let's say as hex tag numbers:

x-mozilla-tags: 0102030000000000

In order to allow more than 8 tags, the remaining ones could be stored outside each message, in a local index.

The only question to answer would be: "How many people, in need of more than 8 tags per message, and more than 255 possible tags, and not wishing/being able to use imap, would have anything against leaving some tags outside each message?" 

I might be wrong, but I don't think there would be many (taking into account that this way of storing tag numbers for arbitrary tags inside each message, is nothing like portable to begin with). Of course a good meta-data back-end would be great, but I see it's been over 4 years, and there is not even a simple hack allowing for these tags.

BTW, how about having a tree-like interface for accessing tags organized in categories? (think: tags with sub-tags. Just interface, nothing to do with storage)
Why limit the number of tags per message to 8? - I was planning on leaving space for a really long x-mozilla-tags: line, on the order of 80 chars.
As the author of HeaderTools, I have had the unique experience of seeing some of the pitfalls and intricacies of providing the ability to 'tag' messages.

I *think* that users would want:
a) an *unrestricted* number of possible tags (labels, catagories whatever )
b) the ability to have a message contain several tags at once
c) the implementation to NOT break IMAP standards
d) the implementation to be as non-intrusive as possible
e) the implementation to be robust

A couple of points..
a) having a back-end metadata 'database' has severe pitfalls 
..1) once out of sync, all metadata is lost
..2) copying and moving messages becomes increasingly hazardous
..3) more datafiles must be maintained in realtime
b) speed is NOT that important
..1) if the processing is flawed but fast, what good is it
c) users *always* want that which is on the other side of any restriction

Obviously, if Mozilla moved from mork to sqllite, datafile maitenance and sync issues would be less valid ( NOT invalid, mind you ), but sqllite has its own implementation issues (  TIME to implementation being one biggie)

Having the tags (labels, catagories whatever) as part of the message (as custom headers) has advantages 
..1) export and import will preserve the tags (can be VERY significant)
..2) nothing can get out of sync
..3) moving and copying will not have to be 'hardened' 
..4) tags do not have to 'fit' into some programming construct and therefore will not be restricted
..5) Mozilla apps will not create messages that are incompatible with other apps (custom headers are supported in all other messageing apps)
..6) Mozilla's current searching/filtering/copying/moving/exporting implementations work *right now*
..7) moving moz message files to a new system will "just work"

Having the tags (labels, catagories whatever) as part of the message (as custom headers has disadvantages 
..1) more disk intensive/slower
..2) modified message gets tacked on at the end of the file ( why is this a problem ?? )

It would be a great shame if the devs were to implement some scheme which is restricted... this is what we have now !  increasing the tags to *any* finite number would just prolong the agony...  

We need *un*restricted tags (ala gmail)

I might be wrong, but it seems to me that custom headers is the ONLY way to implement this properly
My proposal is for a "mixed storage", in-message + out-message.

I think in-message storage of up to 8 labels from 255 possible is a reasonable compromise for not too demanding users. For all the rest, an external out-message metadata storage would be needed.

I think IMAP is a non-issue; while mbox is a real pita.

You can't keep rewriting whole messages (think "10Mb attachments"):
1- rewriting whole mbox storages is unfeasible (up to hundreds Mb per rewrite)
2- appending modified messages is no much better
3- real solution is to have "fixed-length" headers to update in-position, or an out-message metadata storage

Maybe there could some other mixed approach, perhaps a 3-level one:
level 1: fixed-length custom headers in message
level 2: out-message metadata - if not enough reserved space in message
level 3: insert full keyword headers - when rewriting messages (for example, when moving from one folder to another, or optimizing folders)

That way both speed, flexibility and portability could be addressed without compromising each other.
(In reply to comment #64)
> My proposal is for a "mixed storage", in-message + out-message.
> 
> I think in-message storage of up to 8 labels from 255 possible is a reasonable
> compromise for not too demanding users. For all the rest, an external
> out-message metadata storage would be needed.

Maybe, 8 labels on mail will be enough for 30-50% of users, 80 labels on mail will be enough for 80% of all users?
Adding to #63...

I use Frank's HeaderTools extension to achieve arbitrary tagging. It works beautifully...so well in fact that I debated even posting here.

The approach I use is dead-simple:

  -One custom header inserted to hold tags (I use "X-Tags")
  -Each tag separated by whitespace

For example

   X-Tags: john marketing important

It's human-readable, stays with the message if moved/copied, allows unlimited tags, and isn't lost if the mail is moved to another platform. Furthermore, it's searchable with the existing UI (though a cool tag searcher would be welcome), and wouldn't break any existing functionality because it would be treated like any other custom header.

To merge this idea with the existing labels/colours...allow all tags to be assigned a colour (just keep a local table), and paint the message with the colour of the FIRST tag. A simple message tag editor would allow us to swap a different tag into 1st place to make it dominant.

Waddaya think?

P.S. Somewhat related to this bug, I also use a custom header for adding NOTES to a message:

   X-Notes: Ask Bill about this at board meeting!

Only difference from X-Tags is that this header is treated as freeform text when edited, not tag units.

Final suggestion...if either X-Tags or X-Notes are present there should be a UI indicator/flag for the message to tell the user there's added info. A pencil for notes, and a "tag" for tagged messages.

OK, now I'm done!
(In reply to comment #66)
> Adding to #63...
> 
> I use Frank's HeaderTools extension to achieve arbitrary tagging. It works
> beautifully...so well in fact that I debated even posting here.

How does it work on large mbox folders + large attachments?
More important: how does it work when applying tags to existing folders, let's say with thousands of messages each? (like: select 100 messages, apply tag)

I've tried it on IMAP and it seems to work quite well... but then on IMAP this shouldn't be needed.
1. HeaderTools has never worked for me on OS X, and I was under the impression that it does not work on any OS with TB1.5. Am I incorrect?

2. Thunderbird needs to use IMAP keywords. It would be a mistake for it to start using Mozilla-only custom tags. Thunderbird's keywords should be searchable with the IMAP protocol, via the standard IMAP API's (like PHP's http://us3.php.net/manual/en/function.imap-search.php). 

Because some IMAP servers (e.g. Courier) store their keywords in separate files on the server, I would be okay with Thunderbird maintaining and paying attention to an X-Keywords AS WELL, but the SERVER's IMAP KEYWORDS should take precedence. (and the header should PROBABLY (or not?) be one of the standard headers that other IMAP servers use to store keywords)

3. Refer to the all-platform mail client PINE for a nice way of implementing keywords. PINE has the ability to pay attention to as many IMAP keywords as you want. You go into the configuration and select which keywords you want. You also have the OPTION of specifying a label for each keyword. For example, the keyword on the server might be "@someday" but it might be displayed as a "Someday Maybe" in your "keyword" column and it may have a "{S}" added to the start of the subject. (if there are two keywords, you might see two letters like "{S!}")

It would be terrific if Thunderbird supported an infinite (= 255 or higher) number of one-word keywords (that support characters like $, @, etc.) that you can display with a custom label. You could save that list of label-keyword pairs to a file to make it portable.

4. PINE also has another nice option. You can have it store its configuration (including address book) to an IMAP folder (which could be hidden). Backups are saved there too. This means that any PINE you open on any machine has the exact same configuration. This also means that the keyword lists automatically move with you. It's ultra nice.
(In reply to comment #68)

> 2. Thunderbird needs to use IMAP keywords. It would be a mistake for it to
> start using Mozilla-only custom tags. Thunderbird's keywords should be
> searchable with the IMAP protocol, via the standard IMAP API's (like PHP's
> http://us3.php.net/manual/en/function.imap-search.php). 

I'd just like to voice my agreement to the above. I have 50-60 TB users, and many make extensive use of labels currently. As the labels are stored as IMAP keywords, they are searchable and accessible from multiple IMAP clients, including a webmail front-end. The limitation to 5 labels that currently exists is a problem, but shifting to the use of Mozilla specific custom tags would be a far worse one. If labels were to end up being implemented in a Mozilla specific way, I'd want a way to disable them entirely. The confusion caused by having labels visible only from the desktop mail client would be far worse than the problems caused by a limited set of labels, and for me this would be a step backwards, not forwards.
Adding to Comments 60, 61, 63, 64, 68, and 69 on the subject of tagging:

Reading and writing keywords to all messages in a mbox should not take forever, nor should finding all messages with a given keyword set.  The default storage on the server could be as a list in X-Keywords, unless it is an IMAP server in which case the keywords can be stored however the server prefers.  Locally, up to, say, 256 keywords could be stored in the user profile, and in each message 16 hex digits could be used to indicate which of those keywords apply to the message.  These digits would be present for every message, and could be stored (always) as the first keyword of the X-Keywords header or as the contents of a separate header, say X-Mozilla-Keywords.  Thunderbird would dynamically determine which were the most popular keywords, and would rewrite the few messages with ousted digits keywords that were present in the digits but not in the list.  Applying a digits keyword to an entire mbox would be a simple matter of applying a bitmask to the appropriate digits byte of the message.  Whenever the whole message was moved, rewritten, optimized, or sent to the server, the strings corresponding to the digits keywords would be written into the keyword list.  Additionally, if the keyword chosen for a message were not popular, then the keyword would simply be added to the list and the message would be rewritten.  The same keyword could be both in the digits and in the list, but locally the digits would have precedence and remotely the list would have precedence.

Hopefully this implementation would work reasonably well for all cases.

It seems like there's a lot of tension here between those who use IMAP exclusively and those who use the keyword-deficient POP3. Maybe there is a way to close that gap and solve other problems too. After all, I think that this bug is just a symptom of a larger problem.

Why not think of Thunderbird as a sort of "local IMAP server"? I don't mean it should actually SERVE mail, but why not borrow (almost literally copy and paste) the mailbox storage behavior (including keyword support) from one of the commonly used open source IMAP servers available? Plenty of them use mbox files AND have IMAP-standard keyword support. This puts IMAP users and POP3 users on a level playing field. Plus it helps Thunderbird integrate into existing applications much more smoothly.

In fact, while you're at it, why not convert from mbox format to maildir format?  (note: there are many utilities that convert mbox files to maildir files, so it would be easy to upgrade mailboxes) This solves bug 290057 too (Thunderbird should integrate with Spotlight).

https://bugzilla.mozilla.org/show_bug.cgi?id=290057

It seems like a bad idea to create a whole new proprietary keyword behavior. Other people have solved this problem and have had years to perfect it. Just because Thunderbird is just starting now doesn't mean it has to start from scratch.

Plus, it would be nice to be able to point Thunderbird at an existing mail store just like you can do with every other UNIX local e-mail application. 

Personally, I think Thunderbird should borrow a lot more from PINE. PINE will read and write nearly any standard mailbox format (including both mbox and maildir) and supports keywords PROPERLY. It doesn't have any strange proprietary hooks. It's widely used. It's source is available to look at. (though I recommend patching it with the maildir patch to see how maildir support could be built into Thunderbird)
Because on an imap server, users can't delete the summary files - whereas with TB, people can and do. I'm planning on making it so TB won't delete summary files as much as it used to, but there's little we can do about the users.

Re maildir, eventually, but not for 2.0
completa, your suggestion sounds similar to what I was describing in #c60. The disadvantage is that if the mapping file between bits and keywords is lost, you lose your keywords. That mapping has to be stored locally for local messages, as there is no server to store things on. I'm not sure I get the second half of your suggestion about popular keywords and rewriting...

For imap labels, I was just planning on storing them as user-defined keywords, using imap-mod-utf7 encoding, perhaps, for non 7-bit ascii labels - that should generate valid keywords.
I think it's okay to have a local list of keyword<->imap_label mappings. For example, something like:

"Someday Maybe" <-> @somedayMaybe

This would make it easy to regenerate the mappings if necessary. (though being able to import/export those mappings later would be fine) After all, if you have multiple IMAP clients, for display purposes you may not want to display the same labels in each.

(it would really be neat if Thunderbird could store its entire configuration on the server somewhere... perhaps even with a backup four or five copies deep)
Sorry David, you're right, my suggestion was quite similar to your planned implementation.  Perhaps the only differences are that the bit values you describe could be a word of ~16 hex "digits" (i.e. the first keyword of x-moxilla-tags), and a "list" of all tags would follow these "digits" in the x-mozilla-tags header.  Thus, the user could create an arbitrary number of tags, but the fastest operations would be reserved for the "popular" tags (dynamically determined), which would involve flipping one of the bits of the ~16 hex digit word.  There would be complete redundancy for the ~256 tags that the ~16 hex digit word represents, as all tags would be listed in x-mozilla-tags after the ~16 hex digit word.  Thus, even if the local mapping file were lost, the tags would not be lost, though for speedy operations the mapping file would have to be regenerated (and saved as part of the profile).  The only case where any tags would be lost is if bitmask operations were used to tag a group of messages and then the mapping file were deleted; the tags would exist within the "digits" but not within the "list" until the messages were moved, optimized, apprended to the mbox, or sent to the server, at which point the all tags would be written to the "list" and also remain within the "digits".  Essentially, the "digits" are a cache for quick bulk operations.
Brandon
For one, if you're going to use a string of bits for quick operations and if that string gets completely invalidated if another local file is lost, then why store the bitstring in the header of the e-mail? It would be faster to store it in an auxillary index. (if mail was stored in one message per file, those 16 digits could be part of the hex file; selecting a group of messages would be as easy as filtering a list of file names) Then your flipping operations could be applied to that other index.

What happens when keywords get added or deleted on the IMAP server? How is Thunderbird going to respond to these changes? (this is already a problem with Thunderbird's IMAP cache) 

It seems like adding 256 bits to each message means that every time a message is handled, Thunderbird has to check on every single one of those 256 bits and determine whether or not keywords in the actual keyword list should be added or not (even when that message has no keywords). So this actually slows down most operations.

The only thing that this speeds up is doing large multi-keyword selects; however, when you start searching for other things other than keywords, things slow down again.

So if Thunderbird does implement some sort of bit flagging, it should maybe give up storing textual keywords in the message anywhere. Just store the keywords in an accessible file that can be backed up with the rest of the message store (somewhat like how Courier IMAP server does it). 
we already have a summary index for both imap and local folders, so we would only rely on the labels stored in local messages or as imap keywords when the summary gets lost. That index would be used for all label searches, etc.
But what happens when an IMAP label is updated on the server? 

Right now it seems like Thunderbird only updates its local cache if an IMAP label is turned ON on the server. If the flag gets turned OFF, Thunderbird keeps its local label (this may be another bug entirely). 

IMAP users often access servers using multiple clients (sometimes at the same time). Any caching system needs to periodically (or at least whenever a message is accessed) make sure that the labels have not been changed (added OR REMOVED) on the server.
>But what happens when an IMAP label is updated on the server? 

then we should update our local cache. If/when we don't, that's a bug.
I've been listening in a little, and there's one aspect that seems to be totally absent from the discussion: Newsgroup messages, especially those downloaded for offline/archiving purposes.

Am I right in assuming such messages would be handled the exact same way as, say, messages from POP?
The MessageNotes extension described in the issue linked below (Bug 285864), might or might not include concepts or functionality useful for this issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=285864
For news, we'd just store the labels in the summary files - we probably wouldn't store them in the offline stores, since we don't currently (re)generate the summary files from the offline store, only from the server. So as long as you don't delete the summary files, your labels would persist.

I thought about having a separate side store for all message labels, but maintaining that in the face of folder operations (moving, renaming, deleting) was daunting because every time, we'd need to go through that side store to update message uri's. And if an imap or local folder was renamed/moved from another client, we'd have no idea to update the uri's.
If labels aren't stored in and/or regenerated from the offline stores, might that be the/one reason why inline archiving of offline newsroup messages doesn't work? 

It quite definitely would be a good thing to have inline (and non-lossy) archiving with labels included, since setting them is some work, and they're extremely useful. Summary files do get corrupted, more often when it comes to NG's it seems, or maybe it's just the effects are worse, since old archived messages can be synched into oblivion.
*** Bug 332323 has been marked as a duplicate of this bug. ***
howdy y'all,

[1] my tb info ...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 - Build ID: 2005120115

[2] REQUEST = change "Product" from "mozilla application suite" to "core"
since many of the comments here are about tbird and the following tbird bug ...
- Tagging of e-mails using IMAPv4 flags
https://bugzilla.mozilla.org/show_bug.cgi?id=332323

... was duped to this bug, shouldn't "Product" = "core"?

take care,
lee
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
Target Milestone: Future → mozilla1.8.1
this bug has both backend and front end pieces - I'm working on the backend, for the most part, right now.
Status: NEW → ASSIGNED
Would it be possible to extend the scheme of storing flags for labels to a more general scheme of storing values with messages? Or could this be implemented in a more generic way so that the same API could be used e.g. for implementing follow-up actions and deadlines? There are many very useful things that would become possible to implement if there was a decent way to associate meta-data with messages. Since this seems to be about implementing the back-end for label/tag meta-data, I am a bit concerned that a chance to make this a tiny bit more general and gain a *lot* in the process could be missed.
(In reply to comment #87)
> Would it be possible to extend the scheme of storing flags for labels to a more
> general scheme of storing values with messages? Or could this be implemented 
...

Two popular plugins for Apple Mail implement this idea. They're very powerful:

http://www.indev.ca/MailTags.html
http://www.indev.ca/MailActOn.html

However, I think it's important to store the metadata in some (preferably not obfuscated) way in IMAP keywords where available (and locally otherwise). This, I think, is a major challenge. In fact, the author of MailTags and MailActOn has avoided doing this specifically because of the difficulty in doing it (however, a major cause of his difficulty is that Apple Mail plugins do not have access to the IMAP API directly). 

If metadata is desired, I think someone should take a look at these applications (MailTags in particular) to get some ideas. However, don't leave us IMAP users out. IMAP users will never use local non-recoverable metadata. It just doesn't make any sense. Why use IMAP if you store lots of data locally?
Attached patch snapshot of work in progress (obsolete) — — Splinter Review 
this is a snapshot of what I've done so far. It allows you to tag messages through context menus, search for tagged messages, create views and saved searches based on tags, and set tags with filters. There's no UI to create tags, but you can do it manually via prefs.js. It upgrades labels to tags. I still need to upgrade filters and saved searches to use tags instead of labels. There are bugs in here, but I wanted to snapshot things.
(In reply to comment #89)
> There's no UI to create
> tags, but you can do it manually via prefs.js. 

Can you explain how to do this?  I'm looking over your diff, and I may grab the source and play around with it.
Brave man! Please don't try this on any profile/data you care about. 

the prefs are of the form:

pref("mailnews.tags.<key>.tag", "tag value");

e.g.
pref("mailnews.tags.tag_value.tag", "tag value");

I'll be attaching a new patch in a day or two that does the upgrading of filters and saved searches, fixes some bugs, and does the persistent storage of keywords in local mail folders (which is fraught with its own peril).

Second snapshot - fixes a few bugs, and adds persistent storage of keywords/tags in local mail folders, search/filters on tags, and offline recording and playback of imap tagging. It also will do things like grow the blank keyword space for local folders, if needed, or add a x-mozilla-keys header if none exists, when you compact the folder. I'm not particularly happy with that code yet, and it should only be used with test profiles.
Attachment #218179 - Attachment is obsolete: true
Message tags should probably be stored on imap servers using the ANNOTATE extension:

http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-15.txt

However, I'm not sure if there are any implementations actually supporting this extension yet. :)
Here it is - this is getting to a place where I'd like to get feedback from trunk users...
Attachment #220473 - Flags: superreview?(mscott)
Comment on attachment 220473 [details] [diff] [review]
patch ready for review

awesome!
Attachment #220473 - Flags: superreview?(mscott) → superreview+
Ok, a little SPAM-ish, I know -- but WHOA! Should we actually expect this to be in production some time reasonably soon? Congratulations, David!
Comment on attachment 220473 [details] [diff] [review]
patch ready for review

+++ xpcom/base/nsDebugImpl.cpp	2 May 2006 00:19:27 -0000
 #elif defined(XP_BEOS)
-   DEBUGGER(aMsg);
+   DBUGGER(aMsg);

was this change intentional? it doesn't seem to belong to this bug, and I suspect it doesn't even compile...
thx, Christian - no, that wasn't intentional - debugimpl.cpp gets whacked occasionally because of the way msdev works, but I would never check that file in...
Nice work, David!
This patch adds some stuff to get it running in SeaMonkey trunk builds (but no changes to the "Labels" pref panel yet).

Some things I noticed while kicking it to work in SM:
- AddTag() does nothing yet.
- The style system doesn't react on tags, even if they're (just named like?) the old labels.
- The context menu "Tag >" could need a menuseparator before the final "Add Tag".
- The menuitem "Add Tag" is currently not localizable (and should probably end in an ellipsis).
On a second thought:
Shouldn't "Add Tag..." better be called "Customize..." and link to the former "Labels" preferences panel, so you can add/remove tags there?
This adds a New Tag... menu item to the tag context menu. 

We're going to go with this for alpha, so people can add new tags easily. Scott's going to work on the full blown tag editing UI, but not before alpha.  I'm not sure that Customize should be directly accessible from the tags context menu anyway - mostly we want to make it easy to add a new tag like this. Perhaps we can add a customize button to the new tag dialog. We'll also want to add a color picker to that same dialog for new tags.

Seth, some of the diffs in mailWindowOverlay.js have already been reviewed - the change from the previous diffs is mostly just the implementation of AddTag and AddTagCallback.
Attachment #224585 - Flags: superreview?
Attachment #224585 - Flags: superreview? → superreview?(sspitzer)
david, from chrome (in this case newTagDialog.js) is window.alert() the right thing to do?  Or are we supposed to use the prompt service?
I don't know for sure, but according to lxr, we seem to be using window.alert in lots of other places...
bienvenu: see bug 313753
thx, from my reading of that, it looks like window.alert is going to continue to be supported from chrome - if it gets dis-allowed, I'll have to fix all the mailnews code that uses it at once...
What? I can't believe there's no option for that. Hurrumph.
Comment on attachment 224585 [details] [diff] [review]
add ui for creating a new tag

sr=sspitzer on the implementation of AddTag
and AddTagCallback.

acting as reviewer while mscott is away.
Attachment #224585 - Flags: superreview?(sspitzer) → superreview+
fixed on trunk. Please open new spinoff bugs for any issues that arise instead of re-opening this bug and spamming everybody!
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Should spinoffs also be filed under 'Mailnews:Backend'?
like any other bug, it depends on whether the bug is in the front end, e.g. SeaMonkey or Thunderbird-specific, or in the backend. 
Comment on attachment 223992 [details] [diff] [review]
additional SeaMonkey changes (-> over to bug 341010)

I think it should be possible to keep the separator and "Add..." option static, rather than recreating them each time.

I'm also not a fan of setting oncommand attributes dynamically.
Comment on attachment 224585 [details] [diff] [review]
add ui for creating a new tag

>+    for ( var index = 0; index < curMsgHdrKeyArray.length; index++ )
>+    {
>+      if (key == curMsgHdrKeyArray[index])
>+      {
>+        keySet = true;
>+        break;
>         }
>     }
You could use array.indexOf(key) != -1, or if you know that the words are space delimited you could use (" " + keywords + " ").indexOf(" " + key + " ") != -1.


>+  if (dialog.nameField.value) {
>+    if (dialog.OKButton.disabled)
>+      dialog.OKButton.disabled = false;
>+  } else {
>+    if (!dialog.OKButton.disabled)
>+      dialog.OKButton.disabled = true;
>+  }
dialog.OKButton.disabled = !dialog.nameField.value; suffices instead of this block, although you probably want to disallow spaces in the value, which !/^\S+$/.test(dialog.nameField.value) would achieve.
I will make the SeaMonkey-related changes in bug 341010.
Attachment #223992 - Attachment description: additional SeaMonkey changes → additional SeaMonkey changes (-> over to bug 341010)
Attachment #223992 - Attachment is obsolete: true
Comment on attachment 219370 [details] [diff] [review]
snapshot of work in progress

>+  nsACString::const_iterator saveStart(start), saveEnd(end);
>+  while (PR_TRUE)
>+  {
>+    if (FindInReadable(keyword, start, end))
>+    {
>+      PRBool beginMatches = start == saveStart;
>+      PRBool endMatches = end == saveEnd;
>+      nsACString::const_iterator beforeStart(start);
>+      beforeStart--;
>+      // start and end point to the beginning and end of the match
>+      if (beginMatches && (end == saveEnd || *end == ' ')
>+        || (endMatches && *beforeStart == ' ')
>+        || *beforeStart == ' ' && *end == ' ')
Or in other words, if ((beginMatches || *beforeStart == ' ') && (endMatches || *end++ == ' '))
Note: I added the ++ here; this attachment doesn't have the end++ but when you checked in you did if (*end == ' ') end++; without first checking that endMatches in which case I don't know whether *end is defined.

>+      {
>+        return PR_TRUE;
>+      }
>+      else 
>+        start = end; // advance past bogus match.
Don't you need to then set end = saveEnd; here?

>+    }
>+    else
>+      break;
In other words, while (FindInReadable(keyword, start, end)) { ... }
Really great enhancement. Thanks.

With Thunderbird-3.0a1 (and Cyrus v2.3.3), it doesn't see IMAP keywords already set on emails unless these keywords are already defined as customized tags on client-side.

Also, sometimes when tags are set with another MUA they are synchronized immediately with Thunderbird and sometimes the message needs to be clicked on to have tags synch.
Kael, your first comment about the tag having to be defined on the client before it's displayed on the client is by design - this allows the user to define which imap keywords get turned into tags and which don't - otherwise, we might be displaying keywords the user doesn't want to have displayed as tags.

Your second comment may be a client bug, or it may just be that the server isn't notifying us of keyword changes (or we're ignoring that notification - an imap protocol log would tell)
(In reply to comment #116)
> Kael, your first comment about the tag having to be defined on the client
> before it's displayed on the client is by design - this allows the user to
> define which imap keywords get turned into tags and which don't - otherwise, we
> might be displaying keywords the user doesn't want to have displayed as tags.

I don't understand this. Does this mean that (trunk) users will have to create "new tags" for every label they already have on every PC they access their (IMAP) account from? Are there supposed to be both IMAP labels and tags? Is the questionable benefit worth the confusing complexity?
(In reply to comment #116)
> Kael, your first comment about the tag having to be defined on the client
> before it's displayed on the client is by design - this allows the user to
> define which imap keywords get turned into tags and which don't - otherwise, we
> might be displaying keywords the user doesn't want to have displayed as tags.

I'm not sure users wouldn't want to have all IMAP keywords displayed as tags.

With the current design, users have to remember all their keywords and to configure Thunderbird each time they run it from a different place.

Moreover, with shared mailboxes users can't see tags if they don't know them.

Discovering tags allow to easily know the topics of a mailbox at on glance.

How about creating an intermediary third column so that when clicking on mailbox, users could see all their tags (FLAGS or PERMANENTFLAGS) at once glance ? And clicking on a tag (in this column) would run SEARCH KEYWORD foo (/mechanically/ creating views for each tag).

I was considering writing an extension for this column, but still learning XUL and XPCOM...
labels are automatically upgraded to tags - users shouldn't have to do anything to keep their labels acting as tags.
(In reply to comment #119)
> labels are automatically upgraded to tags - users shouldn't have to do anything
> to keep their labels acting as tags.

Thanks. Can a message have multiple tags? Can tags have colors? In which tag's color is a message displayed if it has multiple tags? The first tag's color?

BTW: Please don't force users to display a "tags" column just to see which tag(s) a message has. Horizontal space is already too limited, and using colors to show labels (now tags) is the best method (that I can see right now).

Perhaps a column with small colour swatches or icons would provide a compact way to view a list of tags?

-DS
Blocks: 341354
Blocks: 341369
Blocks: 341432
Blocks: 341434
Blocks: 341010
Blocks: 341170
TB 3a1-0613, Win2K: none of this new stuff appears to be working at all:
 - Context Menu:
   Tag | <tag> => no change to tag status of message.
   Tag | "New Tag..."  =>  no response.
 - Message Menu:
   Tag submenu does not display; I see only a small popup square, perhaps 5x5
     pixels (similar to an empty tooltip).
 - Tools | Options | Display | Labels: no UI for adding custom stuff; still
     called "Labels".
 - Thread pane column: still called "Label".

(In addition to the problems cited in bug 341432 and bug 341434.)

But this build seems a little screwy for perhaps other reasons: load a plain-text POP message and the "barbershop" meter runs interminably, generally seems to be drawing down a lot of CPU and acting sluggish.


(In reply to comment #120)
> Can a message have multiple tags? 

This point seems very important to me: if you're not allowing multiple tags 
(and the UI, so far, doesn't indicate otherwise) then there is no point at all to changing the name from "label" to "tag" (other than, perhaps, glomming on to a buzzword).
(In reply to comment #122)
>  - Thread pane column: still called "Label".

David opened bug 341661 for this.  

Bug 341369 may be about the general not-working-ness from comment 122.
Blocks: 341661
this fixes one of the problems Mike mentioned - the message menu's tag sub-menu wasn't getting initialized correctly.

To answer one of Mike's questions, yes, you can have multiple tags per message. The tags menu will show a check mark for each tag that is on a message, and the menu acts as a toggle.
Attachment #226007 - Flags: superreview?(sspitzer)
Retesting with 3a1-0617, which is generally behaving better.

(In reply to comment #122)
> TB 3a1-0613, Win2K: none of this new stuff appears to be working at all:
>  - Context Menu:
>    Tag | <tag> => no change to tag status of message.
>    Tag | "New Tag..."  =>  no response.

These are both working now; possibly the inability to see a change in tag 
status was due to the lack of coloration (bug 341369) and the "Label" column 
not being updated (?) to show tags.

>  - Thread pane column: still called "Label".

This is basically fixed (bug 341661).


(In reply to comment #124)
> To answer one of Mike's questions, yes, you can have multiple tags per
> message. The tags menu will show a check mark for each tag that is on a
> message, and the menu acts as a toggle.

Yes, I see that now; thanks.  That's excellent.
Comment on attachment 226007 [details] [diff] [review]
fix message menu tags sub-menu

sr=sspitzer, acting mailnews super reviewer while mscott is away
Attachment #226007 - Flags: superreview?(sspitzer) → superreview+
last patch checked in to trunk and branch.
Keywords: fixed1.8.1
Depends on: 341173
One problem seems to persist with this - while new tags can be applied and removed, the original five labels (that are now apparently switched to tags automagically) don't seem to be removable. The check mark is removed from the context menu beside them; but the label coloration remains and the tag name (e.g. "Important") persists if you view the "Tag" field in column view.
see bug 342214  for that last issue.
Depends on: 342214
Blocks: 342560
I checked out a recent build to see how this worked, and I think the interface could be better. 

Now it's a bit clunky and slow to manage several tags.  For example, if you want to add three new ones and remove another. A trip through the right click context menu is required for each option. 

Also, it wasn't clear how this would work with large sets of tags. As a del.icio.us user, I know it's easy to have over 100 tags in use by a single user, as seen here:

http://del.icio.us/markjugg

Here's what I think would make a better UI: 

In the expanded header view of a message, Show the "X-Labels" header, with a free form text field next to it. The field can behave like del.icio.us does, helpfully auto-completing each tag for me as I type. 

At least for people who have large sets of tags, I think this would be an efficient to manage them.

  Mark 
Also note that this does not work correctly with IMAP, just POP3 - as per note in bug 342214.
The shortcuts 0..5 do not work anymore.
Imho they are really useful: please make it configurable or at least allow to switch the status of the first 5 tags using the keyboard (like we was able to do with "old" labels)
> The shortcuts 0..5 do not work anymore.

-> Bug 341173; TB patch coming soon.
I can't seem to be able to set Upper case or MiXed case keywords in IMAP. I am using Thunderbird verion 2 beta 1 (20061119).

I would like to use the proposed IMAP keywords from <http://www.melnikov.ca/mel/Drafts/draft-melnikov-imap-keywords-03.txt>, like $Forwarded, $Work, $Personal, $ShouldReply, $ToDo, $Important and others.

The wiki <http://wiki.mozilla.org/Thunderbird2:Tags#Implementation> states that keys may be imap mod-utf7. Why does the GUI downcase everything I enter? And when I edit prefs.js to have mixed case keys, the keyword doesn't show in the mailbox view anymore. (The .msf stores the keywords in lower case, that might be a reason. Does any one know why /that/ is so?)

Regards,

Roland.

(In reply to comment #118)
> (In reply to comment #116)
> > Kael, your first comment about the tag having to be defined on the client
> > before it's displayed on the client is by design - this allows the user to
> > define which imap keywords get turned into tags and which don't - otherwise, we
> > might be displaying keywords the user doesn't want to have displayed as tags.
> 
> I'm not sure users wouldn't want to have all IMAP keywords displayed as tags.
> 
> With the current design, users have to remember all their keywords and to
> configure Thunderbird each time they run it from a different place.
> 
> Moreover, with shared mailboxes users can't see tags if they don't know them.
> 
> Discovering tags allow to easily know the topics of a mailbox at on glance.

Following-up on my previous comment.

The tags integration in Tb version 2 beta 1 (20061206) is almost perfect !

The design of the GUI is really good, colors are smooth, stars à la Gmail rock, the display of tags under header fields in a non-exclusive manner is smart and views based on tags are excellent.

But the the problem of having to define the list of keywords each time a new account is configured in Thunderbird is really breaking the IMAP KEYWORDS experience.

For example, an anonymous user couldn't see the already existing tags of a shared mailbox :

03 examine "Other Users.kael.lists"
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen foo delicious-discuss del.icio.us list $Label5 yahoo! IETF Lemonade IMAP NonJunk bookmarklet MozDev Greasemonkey Firefox autodiscovery hplaylist Kolab-Users Kolab css microformats comments rel-cite xpath uri toggle wikiproxy aadvark spam form e4x tabs microformats-discuss microfotmats Junk amavis $autonotjunk standards-jig xmpp osaf osafgeneral flockstars flock xulfr xul oai-pmh oai-implementers oai-general ietf-caldav caldav webdav calendar ietf-calsify xpcom gmail-users gmail GMusers BIF bookmarks Smarking cap xfn hcard Chandler Chandler-Dev notification $junk mime RDF ATOM DOM google XML SIEVE ho IMAP-protocol streaming context sip IMAPext Thunderbird ACL JavaScript Asterisk-Video Asterisk VoIP Video Asterisk-Users Dovecot IAX)
* OK [PERMANENTFLAGS ()]  
* 31463 EXISTS
* 31463 RECENT
* OK [UNSEEN 1]  
* OK [UIDVALIDITY 1134153051]  
* OK [UIDNEXT 46709]  
* OK [HIGHESTMODSEQ 46790]  
03 OK [READ-ONLY] Completed

A compromise solution would be :

- to get all keywords (FLAGS/PERMANENTFLAGS) immediately visible, as views and in the display preferences pane, when SELECTing/EXAMINing a mailbox ;

- and to have the ability to deactivate them (by ticking) in the display preferences pane.

Cheers to the Thunderbird Dev Crew.
verified fixed 1.8.1.3 using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 ID:2007032620
Keywords: verified1.8.1.3
This bug is still not fixed sorry.
Thunder/2.0.5

Having several default keywords for a message on an imap server only displays the last default keywords

Lets say a message has $label1,$label3

It will only display $label3 upon reconnecting to the imap server.

Having $label1,customlabel will keep displaying boths labels upon reconnecting.
conditionnaly customlabel is registered in the user account.

Having $label1,$label3,custumlabel will only display $label3,customlabel conditionnaly customlabel is registered in the user account.
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: