Using builds 2000-05-22 on win98, mac and linux we currently don't support creating a List within a List. I don't see this mentioned in the spec whether we want to support the 4.7 behavior or not support it at all. Currently in 4.7 you can create a List within a List but it's a little confusing. First, you have to select the target List (not the parent address book) in the left pane when clicking New List button (note: the drop down in the new list dialog doesn't show lists only Address Books). It looks as though you are creating this sub list in the selected parent address book, but it is actually added as a List of the selected target List and as a top level List for the parent address book. If we are going to support this in 4.7, are we going to have the same behavior as 4.7 mentioned above? Assigning to jglick first for comment, reassign to Candice if this is going to be supported.
Reassign to Kmurray for decision of whether we need to do this feature. Personally, I don't think its that critical. And the 4.x implementation is very confusing so we'd have to come up with a different one.
Assignee: jglick → kmurray
The only problem I might see is if when we migrate a 4.7 profile or import a 4.7 abook what would happen to the list within a list? Does it become just a top level list of the parent address book?
I would say yes. Given how unclear it is in 4.x to do this (and how unclear the feedback that you have done it is), I would bet a list within a list isn't that common.
IMO - The creation of a new list within a list using the Seamonkey Address Book is not critical. I would not spend the effort. However, as pointed out below, data loss is bad. If a user has created a list within a list in 4.7, we should try to preserve the data. I just tried this in 4.7x, and the sublist is presented both as a top level list under the parent address book, and as a member of the parent list. When moving from 4.7 to Seamonkey, ideally, we would preserve the sublist as a top level list under the parent address book, and expand the parent list to include all of the entries of the sublist.
I agree that this isn't that common. Accepting and setting to Future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Changing severity value to enhancement.
Severity: major → enhancement
*** Bug 45893 has been marked as a duplicate of this bug. ***
Summary: [Feature]Are we going to support a List within a List for Address Book → [RFE] Support a List within a List for Address Book
*** Bug 98167 has been marked as a duplicate of this bug. ***
*** Bug 133459 has been marked as a duplicate of this bug. ***
I disagree with the severity enhancement. Reason: Business segments needs this feature (that's why we have opted for different email client than Moz in my institute). If not implemented, Moz. is no real alternative to be considered by this segment in the future.
*** Bug 147918 has been marked as a duplicate of this bug. ***
Marking nsbeta1 to make the address book more robust and 4.x supported this feature.
*** Bug 154528 has been marked as a duplicate of this bug. ***
For me this bug is very important, and the argument that the list hierarchy in 4.7 is ambiguous and is therefore not to be duplicated is specious. The fact is that pine and other e-mail programs in the UNIX world have supported this feature for years. Anyone who's been using e-mail for more than a few years has probably had occasion to create lists within lists, and under 4.7, you could do that easily and consistently. And on the matter of inconsistency, downgrading this bug effectively means the introduction of another inconsistency, in that Mozilla and Netscape claim to be able to import LDIF files, and yet they are unable to preserve the addresses contained in even a two-level hierarchy, never mind the structure of the hierarchy itself. Mozilla does not, in fact, correctly import LDIF files. The result in my case is that every time I add an address, I have to put it in as many as five lists, where before I was putting it in just one list.
This is an irritating omission for us. Even the UNIX cmdline mailers support nested aliases (via ~/.mailrc). Functional aliases are often created by grouping disparate organisational groups of people. These groups often have their own alias. Having to type in multiple aliases everytime I want to send an email to this "functional" group is bloody annoying.
*** Bug 172041 has been marked as a duplicate of this bug. ***
Should address lists "owned" by an address book? Currently they are, which means that addresses "owned" by another address book would be duplicated in the address book "owning" the list. The ability to have lists which can utilise address (and lists) from different address books is very useful. This is also true for addresses from LDAP... which currently duplicate the address. This duplication is confusing when updating personal information, as you have to keep updating each copy of the address (very error prone) and can lead to using incorrect information.
Of course Mozilla should support lists within lists. Eudora does, Entourage does, Outlook does, Outlook Express does, pine does, and Netscape 4.x does. I don't know of any mail software that doesn't. This is causing bug 151814 Also, the strange behavior in the original post is something that I do NOT experience with Netscape 4.8 on the Mac - a list is always at the the address book level, and it can easily contain other lists just by dragging and dropping. There is no duplication. Please don't base a new feature on bug in some versions of Netscape 4.x It is a critical feature for any large organization to have lists that can contain other lists in addition to addresses. With the advent of the Calendar project Mozilla could actually begin to challenge Outlook, but not as it stands with such a limited address book.
*** Bug 180104 has been marked as a duplicate of this bug. ***
Assignee: kmurray1115 → putterman
Status: ASSIGNED → NEW
reassigning to sspitzer
Assignee: putterman → sspitzer
Keywords: nsbeta1 → nsbeta1-
Nominating again. Comment# 18 states that many mail applications already support this feature. If Mozilla wants users to convert to Mozilla then this should be fixed.
Keywords: nsbeta1- → nsbeta1
Mail triage team: nsbeta1-
Frankly, I do not understand the "nsbeta-". All major and minor mailclients support the lists of lists. This feature is crucial for business use. (Actually, this is the only reason why our institution supports/recomends users to install Outlook or Pegas and not Mozilla&Netscape6). I feel that this bug also blocks any solution of bug 133459 , see bug 133459, comment 6 .
I strongly support the opinion in comment #24 that this feature is crucial for business use. Please fix it.
*** Bug 159590 has been marked as a duplicate of this bug. ***
I agree with the general business sentiment expressed for this bug, especially by Calum Mackay. For business users who are trying to build hierarchical lists to distribute information to different groups it is very annoying. In fact I'm resorting to setting up majordomo lists to enable me to do this when I'd be quite happy to have it local. However, for me this is still just at enhancement level. It's a feature that would make my use of Mozilla easier, but the lack of it will not encourage me to use a different mail tool.
Many of us out there use e-mail lists for various non-business activities. For instance, I have political, humor and Egyptology mailing lists. Having to flatten my hierarchy of mailing lists, and then add different names to some blend of 10 different lists, is a real pain. But I would argue that just about anyone who's been doing e-mail for 10 years or more has by now built up a hierarchy of mailing lists, and is inconvenienced at the very least by the lack of hierarchy. And note that the feature has been in UNIX for more than 20 years now. Why is it so hard to put it in Netscape? Unfortunately, I have to use mail programs on multiple platforms: IRIX, Macintosh, Windows and Linux, and am forced to use Netscape/Mozilla because no other combination of browser and mail runs across all these platforms. Otherwise, I would have switched by now.
*** Bug 211761 has been marked as a duplicate of this bug. ***
*** Bug 222617 has been marked as a duplicate of this bug. ***
Modifying summary to increase findability.
Summary: [RFE] Support a List within a List for Address Book → Support a List within a List for Address Book (nested, inside)
Assignee: sspitzer → bienvenu
*** Bug 161426 has been marked as a duplicate of this bug. ***
*** Bug 151814 has been marked as a duplicate of this bug. ***
Should a separate request be opened for this feature in Thunderbird, or will this one cover both products?
it would cover both products. The work is almost all in the backend address book code.
For those who are after 4.5 years tired waiting for this feature: Just randomly pick any other existing mailclient, I cannot find any serious product without this feature. And I doubt that Santa Claus will bring a fix to us this year. Can we get from Santa at least "nsenterprise+"?
>> Just randomly pick any other existing mailclient I am about to do that. This is one of the features I have be waiting to get added and 4.5 years in long enough. I switched to MozMail/TB because it offered security features that I couldn't find in other email clients at the time. But the rest of world has caught up and these security features can now be found in other email clients that don't lack such features such as nested email groups/lists. After using Thunderbird and MozillaMail prior to that for the past couple of years I am close to switching to Courier Email.
Nice to have, but we won't push out any release for that, not even a developer tesing release like SeaMonkey 1.0 Alpha.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: nbaca → addressbook
Nested lists are possible in the linux version of thunderbird 2.0 but not in the windows version. So I guess it would be not so difficult to fix it.
I've tested it in TB 1.5 in windows and it's possible to create nested lists. So, somewhere we loose this usefull feature.
This now works in the Mac version of Thunderbird 2 as well. Is it fixed but someone forgot to close the bug?
Seems to be already implemented in Seamonkey 1.1.x
I've got it working in Thunderbird 126.96.36.199 in Windows Vista Ultimate. I created a nested list by first opening the properties window of the outer list. Then I started to type the name of the nested list in the addresses field, just like any other email address I want to add to the list. Thunderbird opened a popup list box showing addresses and lists that began with the same chars I typed. I selected the name of the list I wanted to nest and the rest of that list's name was copied in the address field. Once again this is consistent with the way it works for individual addresses. I was able to test it by addressing a new message to the outer list, pressing "Send Later", and then going to the "Unsent" folder to view the message. Thunderbird has correctly expanded both the outer list and nested list to the addresses they both contained. I test changes, too. Any changes/additions/deletions I made to the nested list were also correctly resolved by Thunderbird when it expanded the lists in a sent message's recipient field. There is one hitch but it is not a show stopper. In the process of nesting a list inside another one, Thunderbird creates an individual card entry with the same name as the nested list. It's not a list itself - if you double-click it you get a card's properties, not a list's properties. But it must not be deleted because if you do, you will also deleted the nested list entry in the outer list! The end result is that you wind up with a bunch of nested lists that work, but for each nested list you get an individual card with the same name. Thus there are duplicate list names in the address book which must be retained. This can be confusing if you want to change the members of a nested list but don't know which of the two names to double-click. Pick the wrong one and you get a window showing card properties instead. There is a way to tell which is which. If you fill in the "Description" field for a mailing list, it will be displayed in the address book as the email address of the name that is NOT a list. Ugh. But it works even though it's a very clumsy workaround. So if you must have nested lists, and if your setup is anything like mine, it has a good chance of working for you too. This should make it simple for Mozilla to implement error-free nested lists. All they have to do is suppress the display of those duplicate addresses created every time a list is nested. I can't write with an economy of words unfortunately. I hope you can figure out from this note how to do what I did. If you can't, it's got nothing to do with you, that's fer shure. You can see it being discussed, along with another explanation, here: http://forums.mozillazine.org/viewtopic.php?p=3275161#3275161 Good luck, Big Al Mintaka
(In reply to comment #45) > This should make it simple for Mozilla to implement error-free nested lists. > All they have to do is suppress the display of those duplicate addresses > created every time a list is nested. No, that is not the correct fix. Although you have semi got it working, that is more due to bugs in the current system. The architecture is not properly set up to support nested lists correctly. Some of this is being addressed in bug 413260, but your fix is definitely not what we want to do.
(In reply to comment #46) >The architecture is not properly set up to support nested lists correctly. >Some of this is being addressed in bug 413260, but your fix is definitely > not what we want to do. I stand corrected. I know nothing about Thunderbird's architecture, so I should be reporting only what's broken and what I have working - rather than say things like "it should be easy to...". I'll store this one for future reference. As far as the snip above goes, does that mean that nested lists may be supported in the future? I wasn't able to sift through that bug's page or the dependency tree to find anything I understood. At his point my only concern is that I currently have nested lists set up in Thunderbird and don't want to lose them without warning. If you advise me not to use them for the time being, I'll do so. Thanks for your time in reading my previous post and responding, Big Al Mintaka
3.0alpha1 is a time-driven release, definitely doesn't block that. I'd be interested in hearing thoughts from Standard8 and clarkbw on how important it should be for Thunderbird3.
Flags: blocking-thunderbird3.0a1? → blocking-thunderbird3.0a1-
As per discussion with Standard8, not blocking, but might be wanted for Thunderbird3.
I'm not currently planning on doing this; reassigning to nobody. I hope this falls out of the ab reworking...I don't think it would be hard to do, in either mork or sqlite - just have a list row that is a list alias instead of an e-mail address, and expand recursively (but not infinitely :-) )
Assignee: bienvenu → nobody
Product: Core → MailNews Core
Priority: P3 → --
Target Milestone: Future → ---
This worked fine in TB2. I have several lists which contain other lists, and sent to them all the time. Now, in TB3, it has broken; when sending to one of my top-level lists results in the error "sublistname <sublistname> is not a valid e-mail address because it is not of the form user@host. You must correct it before sending the e-mail." Very annoying to have to recreate and flatten my entire list hierarchy, not to mention maintain multiple occurrences of list members.
Windows 7 Home Premium x64 using TB3.0.3 sending to ntlworld (virgin media) mail server gives slightly different message: "An error occurred while sending mail. The mail server responded: Invalid address syntax. Please check message recipient <the nested list name> and try again." Forgive me, I'm new to this. But Comment 50 (21 months ago) mentions "ab reworking" - is the address book mechanism actively being reworked? If so, when is it likely to appear supporting address list within address list - a feature in such common use that it is almost taken for granted? What caused it to stop working in TB3?
(In reply to comment #54) > > What caused it to stop working in TB3? good question. I found several bugs reported yesterday, and previously incorrectly closed one. And I didn't get as far as being able to answer that question. So I have a small collection of bugs to consolidate in the next day or two, and then hopefully someone will be able to fix it and get released into a future 3.0.x version. stay tuned. and, the rework is unrelated as far as I know.
(In reply to comment #53) > This worked fine in TB2. I have several lists which contain other lists, and > sent to them all the time. DeWrek, see bug 542947 comment 7. No one there as reported doing the regression work - perhaps you could do so, or convince someone else to do it?
Happy to help if I can. I have a test rig (Win XP) on which I can do some testing (I don't use email from that system). I don't have compliers. I may need some debug aids, to trap what TB is actually sending out. How can I assist?
The regression of this functionality which occurred in TB3 is documented in bug https://bugzilla.mozilla.org/show_bug.cgi?id=542947 I think this one can be closed, as the original request was to add the feature 10 years ago. That was done, but subsequently broke.
I would like to nest a mailing list into another one. It is an important feature for me.
Whiteboard: nab-mlist → [GS] nab-mlist
With dozens of duplicates, about time to include the technically correct term "Mailing list" and some other relevant search words in summary... ;)
Summary: Support a List within a List for Address Book (nested, inside) → Support nested mailing lists for Address Book ("list within a list", add/create inside, within another containing email list)
You need to log in before you can comment on or make changes to this bug.