Open Bug 756840 Opened 13 years ago Updated 3 years ago

Address book card should display mailing list membership info

Categories

(Thunderbird :: Address Book, enhancement)

Product:
Thunderbird
Component:
Address Book
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: it, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [dupeme])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: Preview or edit any address book entry. Actual results: No mail list membership info is shown. Expected results: Automatically give info to which list the entry belongs. As far as layout is concerned, I suggest reserving vertical space to display about 4-5 lines, each containing one list name. For the case that more lines are needed or the list name is exceedingly long, add vertical and horizontal auto overflow scroll bars. Manually checking list membership by checking all mailing lists is very cumbersome. This is important because for instance when deleting a duplicate where one of the two (or more) entries is part of mailing lists and one is not, the one belonging to the mailing lists should be preserved. Note: this issue is related to bug 654744.
(In reply to David von Oheimb from comment #0) It is a bug for a contact to appear in multiple addressbooks. See bug 45946.
For clarification: This bug has nothing to do with multiple address books. It pertains a single address book, where an entry may be referenced in one or more mailing lists defined in the same address book. This bug is not (or only very remotely) related to bug 45946. This issue is system and platform independent (I just corrected these attributes).
OS: Mac OS X → All
Hardware: x86 → All
Blocks: 654744
Additional/alternative UI suggestion: - In contact edit dialogue add a new tab "List membership" to display the info. - In address book list provide additional small graphical flag/icon, or modify the icon in the 1st column to signal list membership. On mouse hover on this flag/icon, show the list of memberships (with "show next" bars like on Firefox's bookmarks, if the screen limit it reached)
Mouse hover functionality (alternatively on whole AB list item) could later be extended to display additional info, e.g.: - more details about the card - potential duplicates - ...
Ulf, thank you for filing this bug, a worthy RFE. Here's my search for duplicates: BMO QuickSearch for: :thun,mail address,ab list card So that's https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20address%2Cab%20list%20card;list_id=3127995 From there, Ctrl+F for "card", and "Highlight" all findings for easy eye-scanning of results, which include: Bug 64169, Bug 112970, Bug 173836, Bug 353563 All of these are very similar to this bug (suggested RFE's should be combined into a single UI). Fwiw, there are plans for "New AB" and "AB in a tab", so improvements to the old AB are even less likely than other changes in TB. These are helpful ideas, but we are getting into the area of defining details of an entirely new design/approach, i.e. a new AB.
(In reply to Thomas D. from comment #5) > Here's my search for duplicates: > BMO QuickSearch for: > :thun,mail address,ab list card Probably it would be more clever to search in Adress book component only... ;)
(In reply to Thomas D. from comment #5) > Fwiw, there are plans for "New AB" and "AB in a tab", so improvements to the > old AB are even less likely than other changes in TB. These are helpful > ideas, but we are getting into the area of defining details of an entirely > new design/approach, i.e. a new AB. 1. Since these plans will take time, and at least a warning dialogue, bug 654744, seems cheap to implement, please don't hesitate too much. 2. I'm interested on the new plans and to contribute my own view and data model of an ideal address book. Where is this subject discussed?
(In reply to Thomas D. from comment #5) > Ulf, thank you for filing this bug, a worthy RFE. It was not Ulf, but me. > Here's my search for duplicates: Thanks for your hint how to find potential related bugs. I was using a similar method. > Bug 64169, Bug 112970, I see no relation with these bugs. > Bug 353563 yes, though that bug is about list membership viewing, while bug 353563 is about editing the list membership. > Bug 173836, This indeed is strongly related, but so far only refers to list membership info. I suggest extending that bug to ask for list membership info also when editing a card. If done, this bug could be marked as duplicate of bug 173836. > All of these are very similar to this bug (suggested RFE's should be > combined into a single UI). I agree, except for the first two you mentioned, as I just explained. > Fwiw, there are plans for "New AB" and "AB in a tab", so improvements to the > old AB are even less likely than other changes in TB. These are helpful > ideas, but we are getting into the area of defining details of an entirely > new design/approach, i.e. a new AB. IMHO, the whole design and implementation of mailing lists in TB is broken. Would be nice if this opportunity is used to re-design mailing lists. I strongly suggest using instead tags that the user may introduce for each card and employ for the on-the-fly creation of mailing lists via logical expressions, which would be very flexible and convenient, e.g.: "send mail to all entries that have both tag1 and tag2, but not tag3."
(In reply to David von Oheimb from comment #8) > (In reply to Thomas D. from comment #5) > > Ulf, thank you for filing this bug, a worthy RFE. > It was not Ulf, but me. Sorry, I missed that. > IMHO, the whole design ... > ... via logical expressions, > which would be very flexible and convenient, e.g.: > "send mail to all entries that have both tag1 and tag2, but not tag3." I would suggest: - create mailing list from all entries that have both tag1 and tag2, but not tag3 - manually check the result - send mail to mailing list What is the current relation between mailing lists and cards? An unambiguous pointer to the cards or something else?
(In reply to Ulf Zibis from comment #9) > > IMHO, the whole design ... of mailing lists in TB is broken. > > ... via logical expressions, > > which would be very flexible and convenient, e.g.: > > "send mail to all entries that have both tag1 and tag2, but not tag3." > > I would suggest: > - create mailing list from all entries that have both tag1 and tag2, but not > tag3 > - manually check the result > - send mail to mailing list I also like this less radical approach, which is more like a compromise. That is, tags would be offered in addition to the already existing mailing lists, and the latter can be constructed conveniently from the former. > What is the current relation between mailing lists and cards? > An unambiguous pointer to the cards or something else? AFAICS, a mailing lists is merely a list of email addresses, used as pointers to cards. This bad design results in dangling references in case email addresses are changed or cards whose email addresses are in lists are deleted :-(
(In reply to David von Oheimb from comment #10) > AFAICS, a mailing lists is merely a list of email addresses, used as > pointers to cards. According my tests below, I believe you're wrong :-( > This bad design results in dangling references in case > email addresses are changed Also here I can't see this :-( > or cards whose email addresses are in lists are > deleted :-( This is correct, it's the underlying cause for bug 654744. I've done some tests: 1. Changed display name of a card. --> In referenced mailing list the display name changed accordingly. ==> Seems correct to me! 2. Changed main email of a card. --> In referenced mailing list the email changed accordingly. ==> Seems correct to me! In other words, if a physical person changes his/her email, IMO sender of mailing list still wants to address the physical person, so using the "corrected" email seems intuitive, resonable and correct to me. 3. Added additional email to a card. --> In referenced mailing list nothing changed. ==> It's not clear by the UI view, if the additional email is additionally used while sending to the mailing list. IMHO this needs clarification by UI and discussion! 4. Deleted primary email of a card. --> In referenced mailing list, email field in list column is blank, but additional email is displayed in bottom pane if card is selected in the upper list. ==> It's not clear by the UI view, if alternatively the additional email is used while sending to the mailing list. IMHO this too needs clarification by UI and discussion!
Good idea.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [dupeme]
(In reply to Ulf Zibis from comment #7) > (In reply to Thomas D. from comment #5) > > Fwiw, there are plans for "New AB" and "AB in a tab" > [snip] > 1. Since these plans will take time, and at least a warning dialogue, bug > 654744, seems cheap to implement, please don't hesitate too much. I'm not sure if it's simple to code, but you are most welcome to provide a patch. I agree we should have the warning dialogue asap because nobody knows when new AB will come, and preventing dataloss should take priority. FTR: I'm not a developer, just a volunteer. I'm not an expert coder, either. > 2. I'm interested on the new plans and to contribute my own view and data > model of an ideal address book. Where is this subject discussed? https://wiki.mozilla.org/Features/Thunderbird/Modern_Address_Book I don't know, but I don't think there is a meta bug for that yet. On 2012-03-23, Blake Winton (UX-Lead) outlined UX-priorities on tb-planning@mozilla.org mailing list, and address book was last-but-one on the list: > Address Book. > re-design as a web-app, possibly targeting Mobile first… > This seems important and useful, but it's also a very large task, and I > think I'ld like the front-end team to work on some smaller stuff for a > little while. http://mikeconley.ca/blog/2012/05/07/a-slight-redirection/ Discussion is probably best done on m.d.a.t. newsgroup.
Discussion is explicitly unwanted in Bug 118665, but it's an interesting read anyway about problem of "Bandaid-fixing of bad bugs in old AB" vs. "Waiting for new AB forever".
(In reply to Ulf Zibis from comment #11) > (In reply to David von Oheimb from comment #10) > > AFAICS, a mailing list is merely a list of email addresses, used as pointers to cards. > According my tests below, I believe you're wrong :-( No, but your tests were incomplete - see below. > > This bad design results in dangling references in case email addresses are changed > Also here I can't see this You didn't see this just because there are some workarounds implemented. Actually, some more workarounds would be needed because of the bad design. > > or cards whose email addresses are in lists are deleted :-( > This is correct, it's the underlying cause for bug 654744. Yes. > 2. Changed main email of a card. > --> In referenced mailing list the email changed accordingly. > ==> Seems correct to me! In other words, if a physical person changes his/her email, > IMO sender of mailing list still wants to address the physical person, so using > the "corrected" email seems intuitive, reasonable and correct to me. Would be nice if so, but you need to look closer after changing the email address. If you click on the mailing list containing the entry with the changed address, you will notice that the old address is still in there :-( Even worse, if you click "Ok" to close the list, a spurious new entry with the old email address appears in the address book :-( :-(( > 3. Added additional email to a card. > --> In referenced mailing list nothing changed. > ==> It's not clear by the UI view, if the additional email is additionally used > while sending to the mailing list. IMHO this needs clarification by UI and discussion! The secondary email address is not referenced in the mailing list. > 4. Deleted primary email of a card. > --> In referenced mailing list, email field in list column is blank, Yes, which is bad :-( As you can see, I know why I wrote, and I still maintain, that both the design and the implementation of the TB mailing lists are *broken*. Yet actually, this is not the right place to discuss the general problem. I strongly suggest again to add tags as an alternative concept/solution.
Severity: enhancement → normal
P.S. To observe the weird effects of changing the primary email of an entry that is a member of a mailing list, one needs to *double* click on the list name, then click Ok. Another indicator that there are deep problems with the TB mailing lists is that their development documentation is very poor, nearly non-existing. Where is the right place to discuss the more general mailing list issues, which are of much higher (at least major) importance than the specific topic of the current bug?
Severity: normal → major
I just filed a new bug report addressing the general problem: bug 757736. This allows reducing again the severity of the current bug to "enhancement".
Severity: major → enhancement
Blocks: 757736
(In reply to David von Oheimb from comment #15) > (In reply to Ulf Zibis from comment #11) > Would be nice if so, ... a spurious new entry with > the old email address appears in the address book :-( :-(( Oops, I see 8-) > > 4. Deleted primary email of a card. > > --> In referenced mailing list, email field in list column is blank, > > Yes, which is bad :-( Don't agree. If I have wrong email from an individual, I want to delete it but keep the individual in the list. Later I want to insert a corrected email.
(In reply to Ulf Zibis from comment #18) > > > 4. Deleted primary email of a card. > > > --> In referenced mailing list, email field in list column is blank, > > > > Yes, which is bad :-( > > Don't agree. If I have wrong email from an individual, I want to delete it > but keep the individual in the list. Later I want to insert a corrected > email. Oops, you are right: interestingly, the entry persists even if the primary email is deleted temporarily. But then another weird thing happens: if one just single-clicks the list to view its members, the name of the card with the deleted email address is correctly shown without the email address, but if you double-click the list to edit it, the only entry *including* the deleted address is present, and if you then click "Ok", a spurious new card appears in the book with the old data. Apparently is this an instance of the same bug I pointed out for case 2. There are further strange effects if you add a card to a list that only has a secondary (and no primary) email address, but these things are not the topic of *this* bug, so let's better stop here (and maybe point them out elsewhere).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.