553647 - "Edit Contact" properties dialog: Implement dropdown field to show and change the name of containing address book (as in Inline Contact Editor from yellow star)

Status: NEW

(Thunderbird :: Address Book, enhancement)

Description

[Shari Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Thunderbird/3.0.3

When you open the Edit Contact there is no indication of which address book the email address is listed in. I think this is information that is necessary. If the email address is in the collected address book, it just means I've sent email to that person, not that I've actually setup a contact card. 

Reproducible: Always

Steps to Reproduce:
See star next to from
Click select Edit Contact
No indication for address book.
Click edit details
No indication for address book.


Expected Results:  
Either in the initial information or when clicking details. The address book the information is being shown from should be included.

I don't think this should be considered an enhancement, as the word details should imho include all details specific to the information being shown, including the address book the card is located in.

Comment 1

[Möbius]

Expected Results: ...and the posibility to choose in which address book save the address

Comment 2

[Shari Smith]

I can confirm this, and agree that this is necessary, especially as searching in the address book only searches individual address books, and doesn't keep the address in the search box when you move to the next book. Making for a time intensive application to make sure you have the "right" contact.

Comment 3

[Jim Porter (:squib)]

It sounds like there are two issues here:

1) Edit Contact from the message header doesn't show the address book (bug 474721)
2) Edit Contact from the address book (or Edit Details from the message header) doesn't show the address book

Comment 4

[Shari Smith]

Yes, I guess it would be two issues. I have multiple address books, with the same person in more then one, and the details need to be different based on the address book (I'm a VA and work for others, and they sometimes have the same client, but they need different information). I love that I can open the card and add the details from the message header, I just wish I knew if I was adding it to the right contact.

Comment 5

[Jim Porter (:squib)]

Oops, I meant bug 456167 above. I think there's also a bug for the second issue, but I'm not sure.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> Oops, I meant bug 456167 above. I think there's also a bug for the second
> issue, but I'm not sure.

I couldn't find one, so confirming.  And I could swear there is a bug for not showing the name for the currently selected address book in the AB window - couldn't find that either. So there may be seamonkey bugs for one or both of these.

Comment 7

[Thomas D. (:thomas8)]

STR

1) From whereever you like, open the "Edit contact for foo@bar" dialogue with the full contact properties.
2) From full(!) contact properties, try to find out or change the containing AB (as an important contact property).

Actual Result:

Can neither see nor change the containing AB from contact properties.

Expected Result:

See Inline contact editor from message reader's yellow star, where we offer a dropdown field for showing and changing the containing AB. We should add the same field to the full properties dialogue.

Comment 8

[Thomas D. (:thomas8)]

This would be nice complement for bug 170270, because it is now possible to trigger the "Edit contact for [e-mail]" properties dialogue from cross-AB search results where the containing AB is not necessarily shown. Also to be ux-consistent with the miniature version of contact properties, the inline "Edit contact" panel from message reader's yellow star, where we already have a Containing AB selector.

Possible UI:

(In reply to Thomas D. from bug 170270 comment #81)
> 3) Further points (from bug 170270 Comment 60)
> a) For contact card properties, now need a display of parent AB
> - At the top of card properties dialog, above the tabs, there should be a
> dropdown list for showing and changing the current parent AB of the card.
> The full functionality is available (right-click on to-header in mail
> reader, Edit Contact), but with more and more ABs/directories around, this
> should now also become part of the properties dialogue for easy and
> efficient accessability from anywhere. Containing AB looks like an important
> contact property to me, viewing and changing of which should be easier.

So basically, imo the UI choices seem to be:

1) AB selector *above* the contact's tab row (somewhat visualising that this is the parent AB):

Address book: [Containing AB selector v]

[*Contact*][Private][Work][Other][Chat][Photo]
First:        John                          Work:
Last:         Doe                           Home:
Display:      John Doe                      ...


2) AB selector *on* the [Contact] tab (parent AB as one of many properties of the contact)

[*Contact*][Private][Work][Other][Chat][Photo]
Address book: [Containing AB selector v]
First:        John                          Work:
Last:         Doe                           Home:
Display:      John Doe                      ...


Maybe 2) is better:
- AB selector above the tabs row might be misunderstood that you could use it to change the AB and show other contacts with same name, but found in another AB (location bar to change currently viewed location)
- Changing the parent AB of contact will not happen frequently, so it's not important enough to be so emphasized and outstanding on top of the tab bar. Otoh, it's an important property to have in mind when editing a contact.
- Logically better design in the long run, in a contact-centric approach where the parent AB is just another property of the contact, more like a group tag which links the contact with the group/category which is the AB.

Blake, what do you think?

Comment 9

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #8)

> 2) AB selector *on* the [Contact] tab (parent AB as one of many properties
> of the contact)
> 
> [*Contact*][Private][Work][Other][Chat][Photo]
> Address book: [Containing AB selector v]

Where [Containing AB selector v] would actually look like this (showing the name of parent AB in a dropdown field):

Address book: [Personal Address Book v]

Comment 10

[Blake Winton (:bwinton) (:☕️)]

So, I have a couple of thoughts here.

1) It seems to me that the containing address book contains the entire contact, including Private, Work, Other, Chat, and Photo.  So putting the containing address book inside Contact doesn't really reflect either the implementation, or the mental model we want to give the user.

2) I'm curious as to how this is going to work in a merged-contacts-from-multiple-address-books world, and what steps we can take now to try and ease that transition.  (Thus, needinfo-ing mconley.  ;)

3) Perhaps we don't actually have a dropdown selector like that.  Maybe we put a button at the bottom of the properties dialog that says "Move contact" or something similar.

Comment 11

[Thomas D. (:thomas8)]

(In reply to Blake Winton (:bwinton) from comment #10)
> So, I have a couple of thoughts here.

Thanks for sharing them :)

> 1) It seems to me that the containing address book contains the entire
> contact, including Private, Work, Other, Chat, and Photo.

Correct.

> So putting the
> containing address book inside Contact doesn't really reflect either the
> implementation, or the mental model we want to give the user.

Well, that depends on the mental model we want to give the user.
If that mental model focuses on tags/properties, it'll be fine to consider "Containing AB" as just another tag or property of the contact. Which btw blends in nicely with your thoughts below when in the future, one contact might somehow belong to multiple address books (iow, one contact can have multiple group tags, and the groups happen to be considered as "Address books"). The current UI with a simple parent-AB dropdown in the inline contact editor (right below name and email properties) already suggests that parent-AB is just another property of the contact.

Having said which, I'm fine with placing the AB selector above the tabs row as you suggest, and see how we like it there and how it works out wrt the caveats mentioned in my comment 8. So I think that's a good way forward for this bug.

> 2) I'm curious as to how this is going to work in a
> merged-contacts-from-multiple-address-books world, and what steps we can
> take now to try and ease that transition.  (Thus, needinfo-ing mconley.  ;)
> 
> 3) Perhaps we don't actually have a dropdown selector like that.  Maybe we
> put a button at the bottom of the properties dialog that says "Move contact"
> or something similar.

That's all fair in an ideal world with unlimited developer time and happy users in rapid release cycles, but I'll humbly submit that the latter two points seem to expand the scope of this bug and thus considerably delay implementation. Whereas our users are desperate for anything which improves their AB UX now, and not at some unforeseeable time in the future.

"Move contact" button would require showing the parent AB name as a fixed string somewhere in the full properties dialogue, which looks unnecessary complex in the current scheme of things.

The goal of this bug is very simple: Copy the existing(!) Parent-AB-Selector from the Inline Contact Editor (simple "Address book" dropdown in "Edit contact" panel from yellow star) into the full-fledged contact properties dialogue ("Edit Contact for John Doe").
- Inline Contact Editor ("Edit Contact") is just a reduced version of the all-details "Edit Contact for John Doe" contact properties dialogue, which requires that *all* properties found on the mini dialogue *must* also be in the full dialogue (and using different controls for the same purpose should be avoided, ux-consistency)
- Having the Parent-AB-Selector in the full dialogue is especially important for scenarios that do not involve going through inline mini dialogue; such scenarios will now occur more frequently than before because we have more starting points from new "All Address Books" search results where the parent AB may not be obvious (ux-efficiency, ux-error-prevention), and changing the parent AB may be desired as part of de-duplication/consolidation/reorganisation scenarios.

Bottom line:

There's an existing Parent-AB-Selector control (simple dropdown) in the inline mini dialogue which works well with current AB design, but the same control is missing in the full properties dialogue. That gap in the current design should be fixed asap, especially because new "All ABs" search is likely to increase the number of scenarios where the parent AB may be unknown or should be changed. The current dropdown selector control is simple, efficient, and intuitive, both for showing and changing the parent AB with a single action (2 clicks). Duplicating the same control now in the full properties dialogue will not prevent or make harder any potential future design changes in a "merged-contacts-from-multiple-address-books" world, but will provide our users with more ux-efficiency and ux-control without further delays.

Comment 12

[Thomas D. (:thomas8)]

So, for anyone who wants to start working on this bug:

Notwithstanding further inputs and future refinements along comment 10, we could start by trying the way of least resistance and fastest improvement: Duplicate the existing parent AB selector (simple dropdown) from inline contact editor, and add that at the top of the tabs row of full properties dialogue (per Blake's comment 10):

> 1) AB selector *above* the contact's tab row (somewhat visualising that this is the parent AB):
> 
> Address book: [Containing AB selector v]
> 
> [*Contact*][Private][Work][Other][Chat][Photo]
> First:        John                          Work:
> Last:         Doe                           Home:
> Display:      John Doe                      ...

Comment 13

[Michael Resnick]

Attachment: Edit Contact can now move cards between address books

A card cannot be moved if it apears in any mailing list. This is the
case with the existing "inline contact editor".

The only thing I'm not sure of is the use of SetAbView() in
mailnews/addrbook/content/abResultsPane.js. This is done to ensure the
proper refresh of the result pane when the selected address book is the
root address book.

Without this call, moving cards between the personal and collected
address books while the root address book is selected result in odd
refresh results. Either duplicate entries appear or the entry disappears
altogether.

With this call, the update looks correct, though focus moves to the next
entry in the list.

I wonder if something else should be called here and I'm just not aware
of.

Other than that, I await the review to find out what else I don't know
about in this environment.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8666300 [details] [diff] [review]
Edit Contact can now move cards between address books

I feel awful for having never gotten to this. I think it's clear that I'm not the right reviewer here. Sorry. :(

I'm going to redirect to Magnus.

Comment 15

[Magnus Melin [:mkmelin]]

Comment on attachment 8666300 [details] [diff] [review]
Edit Contact can now move cards between address books

Review of attachment 8666300 [details] [diff] [review]:
-----------------------------------------------------------------

Finally got to trying this out.

It's pretty close. I think the address book selector should be at the bottom, not top of the dialog. I'll attach an updated patch.
Another problem is that the contact seems not to get moved in some cases, it duplicates instead. Isn't a problem between Collected and Personal, but from another (local) address book it's reproducible.

Comment 16

[Magnus Melin [:mkmelin]]

Attachment: 553647.patch

Updated to move the selector to top.

Comment 17

[Thomas D. (:thomas8)]

I'd hate to see this fine patch offered by Michael (a new contributor) rotting away without attention.

Michael, it would be great if you'd be willing to continue working on your patch. Can you look into the problem mentioned by review comment 15 that with your patch, it seems that sometimes contacts get duplicated instead of moved?

Once again, big apology for the severe delay with your first review request; it just happened that you picked a reviewer who was no longer doing reviews for TB as he's now officially working on another project.
I'm confident we'll have faster review turnaround times if you continue working on this now, as we now have 3 key TB developers on board here, Magnus, Aceman, and Jörg. You'll be aware that TB is currently almost completely run by volunteers.

Can someone please look into Michael's comment 13, maybe the duplicate contact seen by Magnus is just an artefact due to directory refresh issues?

Jörg, can you have a look at the patch? Large portions are just re-indented, so the actual patch code is less and should be reasonably straight-forward given our current experience from other AB bugs...
Certainly some potential for code cleanup, too...

Comment 18

[Michael Resnick]

Sorry to take so long to respond.

Given the 14 months between review request and initial response, I've gotten involved with other things.

However, I still have the development environment somewhere on my system and can probably update it and take a look at the duplicates issue in comment 15.

Also, I'll try to do a better job of keeping the indenting of the code from changing.

Comment 19

[Thomas D. (:thomas8)]

Ping @ everyone... ?

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #17)
> I'd hate to see this fine patch offered by Michael (a new contributor)
> rotting away without attention.
> 
> Michael, it would be great if you'd be willing to continue working on your
> patch. Can you look into the problem mentioned by review comment 15 that
> with your patch, it seems that sometimes contacts get duplicated instead of
> moved?
> 
> Once again, big apology for the severe delay with your first review request;
> it just happened that you picked a reviewer who was no longer doing reviews
> for TB as he's now officially working on another project.
> I'm confident we'll have faster review turnaround times if you continue
> working on this now, as we now have 3 key TB developers on board here,
> Magnus, Aceman, and Jörg. You'll be aware that TB is currently almost
> completely run by volunteers.
> 
> Can someone please look into Michael's comment 13, maybe the duplicate
> contact seen by Magnus is just an artefact due to directory refresh issues?
> 
> Jörg, can you have a look at the patch? Large portions are just re-indented,
> so the actual patch code is less and should be reasonably straight-forward
> given our current experience from other AB bugs...
> Certainly some potential for code cleanup, too...

Comment 20

[:aceman]

Comment on attachment 8823413 [details] [diff] [review]
553647.patch

Review of attachment 8823413 [details] [diff] [review]:
-----------------------------------------------------------------

Hi, I have looked at this now. It seems to mostly work, thanks.

The patch itself does not need to contain the commentary about SetAbView() in the final version.

When playing with this, and actually changing the AB of a card, I got an error in the error console:
13:58:40.590 TypeError: aDocumentNode is undefined 1 msgHdrViewOverlay.js:1425:1
	UpdateExtraAddressProcessing chrome://messenger/content/msgHdrViewOverlay.js:1425:1
	updateExtraAddressProcessing chrome://messenger/content/mailWidgets.xml:908:17
	OnAddressBookDataChanged/< chrome://messenger/content/msgHdrViewOverlay.js:395:9
	forEach self-hosted:282:13
	OnAddressBookDataChanged chrome://messenger/content/msgHdrViewOverlay.js:389:3
	onItemAdded chrome://messenger/content/msgHdrViewOverlay.js:371:5
	EditCardOKButton chrome://messenger/content/addressbook/abCardOverlay.js:184:5
	anonymous chrome://global/content/bindings/dialog.xml%20line%20379%20%3E%20Function:3:8
	_fireButtonEvent chrome://global/content/bindings/dialog.xml:380:28
	_doButtonCommand chrome://global/content/bindings/dialog.xml:348:28
	_handleButtonCommand chrome://global/content/bindings/dialog.xml:336:18
	goEditCardDialog chrome://messenger/content/addressbook/abCommon.js:740:3
	AbEditCard chrome://messenger/content/addressbook/abCommon.js:495:5
	AbEditSelectedCard chrome://messenger/content/addressbook/abResultsPane.js:263:3
	doCommand chrome://messenger/content/addressbook/abResultsPane.js:480:9
	goDoCommand chrome://global/content/globalOverlay.js:93:7
	oncommand chrome://messenger/content/addressbook/addressbook.xul:1:1
(and the same also for line 1440)

You need to have a message open and viewed in the message preview pane. It seems the headers listen to changes in AB cards to update the view and something went wrong here when moving card to another AB.

I've seen the talk in this bug about the placement of the AB chooser menulist. I have just noticed that when creating a new contact, the AB menulist is on the top. When editing a contact, the AB list is at the bottom. If that is intentional, I'm fine, I just wanted to mention it so that we are sure we want that.

::: mail/components/addrbook/content/abCardOverlay.js
@@ +180,5 @@
> +    // The card was moved from one address book to another. By definition,
> +    // this means it's not in any mailing lists.
> +
> +    // Add it to the chosen address book...
> +    newDirectory.addCard(gEditCard.card);

Can you check if addCard succeeded and only then remove the card from old AB? I think you need to 'try { addCard () } catch (e) {}' to catch the failure.

@@ +186,5 @@
> +    // ...and delete it from the old place.
> +    let cardArray =
> +      Components.classes["@mozilla.org/array;1"]
> +                .createInstance(Components.interfaces.nsIMutableArray);
> +    cardArray.appendElement(gEditCard.card, false);

You can shorten this to cardArray = toXPCOMArray(gEditCard.card, Components.interfaces.nsIMutableArray); if you add 
Components.utils.import("resource:///modules/iteratorUtils.js"); at the top of the file.

@@ +189,5 @@
> +                .createInstance(Components.interfaces.nsIMutableArray);
> +    cardArray.appendElement(gEditCard.card, false);
> +    directory.deleteCards(cardArray);
> +
> +    NotifySaveListeners(newDirectory);

Is this needed? There is another call of the same later on.

@@ +194,4 @@
>    }
> +  else {
> +    // See if this card is in any mailing list
> +    // if so then we need to update the addresslists of those mailing lists

Please make this a proper sentence and put a full stop (dot) at the end.

@@ +200,2 @@
>  
> +    // create a list of mailing lists and the index where the card is at.

"Create".

@@ +200,3 @@
>  
> +    // create a list of mailing lists and the index where the card is at.
> +    for (let i = 0; i < listDirectoriesCount; i++) {

You can do 'for (let subdir of fixIterator(directory.addressLists, Components.interfaces.nsIAbDirectory) ...' and drop listDirectoriesCount.

@@ +286,5 @@
> +  }
> +  gEditCard.abURI = directory.URI;
> +
> +  // Is this card in at least one mailng list?
> +  let inMailingList = false

missing semicolon

@@ +287,5 @@
> +  gEditCard.abURI = directory.URI;
> +
> +  // Is this card in at least one mailng list?
> +  let inMailingList = false
> +  let listDirectoriesCount = (directory.addressLists != null) ? directory.addressLists.length : 0;

Have you encountered a case where .addressLists returns null? I think it returns an empty array (nsIArray) if there are no cards.

@@ +289,5 @@
> +  // Is this card in at least one mailng list?
> +  let inMailingList = false
> +  let listDirectoriesCount = (directory.addressLists != null) ? directory.addressLists.length : 0;
> +
> +  for (let i = 0; i < listDirectoriesCount && !inMailingList; i++) {

You can do 'for (let subdir of fixIterator(directory.addressLists, Components.interfaces.nsIAbDirectory) ...' and drop listDirectoriesCount.

@@ +298,5 @@
> +      // Must compare card contents using .equals() instead of .indexOf()
> +      // because gEditCard is not really a member of the .addressLists
> +      // array.
> +      let listCardsCount = subdir.addressLists.length;
> +      for (let index = 0; index < listCardsCount; index++) {

You can do 'for (let card of fixIterator(subdir.addressLists, Components.interfaces.nsIAbCard) ...' and drop listCardsCount.

@@ +302,5 @@
> +      for (let index = 0; index < listCardsCount; index++) {
> +        let card = subdir.addressLists
> +                         .queryElementAt(index, Components.interfaces.nsIAbCard);
> +        if (card.equals(gEditCard.card)) {
> +          inMailingList = true;

You can add 'break;' here and not check !inMailingList in the main loop. It will also be faster as you will not need to run until the end of current mailing list.

@@ +309,5 @@
> +    }
> +  }
> +
> +  // set popup with address book names
> +  var abPopup = document.getElementById('abPopup');

Double quotes.

@@ -268,2 @@
>    {
> -    if ("abURI" in window.arguments[0]) {

Why can you drop this? What is the replacement? It seems it was possible to send the "abURI" to the dialog and it obeyed it. You fetch the ABdirectory yourself now at the top of the function. But that seems to change behaviour. The directory.readOnly and its code block was only run when the "abURI" was passed in. Can you check all the callers of the dialog to see when they pass the abURI and when not?

@@ +634,5 @@
> +{
> +  var directory = GetDirectoryFromURI(abURI);
> +  if (directory.isMailList) {
> +      let parentURI = GetParentDirectoryFromMailingListURI(abURI);
> +      directory = GetDirectoryFromURI(parentURI);

Only 2 spaces for indent please.

::: mailnews/addrbook/content/abEditCardDialog.xul
@@ +23,5 @@
> +           control="abPopup"
> +           value="&addressBook.label;"
> +           accesskey="&addressBook.accesskey;"/>
> +    <menulist id="abPopup">
> +      <menupopup id="abPopup-menupopup" class="addrbooksPopup" writable="true"/>

You make this writable also for Seamonkey and add the needed strings in /suite . But you do not add the code you add in mail/components/addrbook/content/abCardOverlay.js . Will changing the AB do anything for Seamonkey?

::: mailnews/addrbook/content/abResultsPane.js
@@ +260,5 @@
>  
>  function AbEditSelectedCard()
>  {
>    AbEditCard(GetSelectedCard());
> +  SetAbView(GetSelectedDirectory());

Yeah, I'm also not sure if this is needed. I'd hope refreshing the list already works automatically as we have editing functions on cards. But it is true that there are some open bugs about the cards not being refreshed properly.

Comment 21

[Thomas D. (:thomas8)]

Hi Michael, sorry for nagging, but are you going to address the latest review of comment 20 (plus comment 15 if possible)?
I think if you start working along comment 20, then we'll gladly assist if there are any problems. Comment 15 might also need some teamwork to get it out of the way.

(In reply to :aceman from comment #20)
> Comment on attachment 8823413 [details] [diff] [review]
> 553647.patch
> 
> Review of attachment 8823413 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Hi, I have looked at this now. It seems to mostly work, thanks.
> ...
> I've seen the talk in this bug about the placement of the AB chooser
> menulist. I have just noticed that when creating a new contact, the AB
> menulist is on the top. When editing a contact, the AB list is at the
> bottom. If that is intentional, I'm fine, I just wanted to mention it so
> that we are sure we want that.

Magnus intentionally moved it to the bottom in comment 16 (in spite of claiming that he moved it tot the top).
There were pros and cons.
Can I please have a screenshot of the current position with the patch?

Comment 22

[Thomas D. (:thomas8)]

Looks like we have lost Michael (assignee) due to repeated, extended review lags.
What's the way forward here?

And I'd really like to see a screenshot...

Comment 23

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #22)
> What's the way forward here?
Someone picks up the patch, not me.

Comment 24

[:aceman]

Screenshot of what? Isn't there just the AB picker menulist added?
Thomas can you pick up the patch and fix the review comments? It seems to be in JS only. I'm not sure why adding a new .dtd file is needed (together with the jar.mn changes).

Comment 25

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #24)

Screenshot of what? Isn't there just the AB picker menulist added?

I wanted to see without applying the patch exactly where it has been added, because there has been some discussion and some erroneous claims.

Thomas can you pick up the patch and fix the review comments? It seems to be in JS only. I'm not sure why adding a new .dtd file is needed (together with the jar.mn changes).

Unfortunately, I can't afford the time atm for this type of unpaid volunteer work... :-/

Comment 26

[Philipp Schlesinger]

Attachment: contact edit dialog

Comment 27

[Philipp Schlesinger]

Attachment: *add* contact window

Comment 28

[Philipp Schlesinger]

While this is an old bug, it still applies to thunderbird 102.0.1 (see previous attachments to the bug)

• when adding a new contact, one can choose the address book to save in
• upon editing an existing contact, the dropdown to see in which address book the contact is contained currently and where to save in in is missing.

proposed solution: add the dropdown like in the contact add dialog in the edit contact dialog.

Comment 29

[Philipp Schlesinger]

@

Comment 30

[Alessandro Castellani [:aleca]]

Indeed, we need to consider this since, if I'm not wrong, there's currently no way to move a contact to another address book that doesn't involve drag & drop.
I know we have the contact popup in the message header, which offers that option, but something similar should be available also in the Address Book tab itself.

I'm not sure having the dropdown visible in the Edit view makes sense as the user is not saving the contact in an Address Book but moving it, and moving a contact and editing a contact's info I think should be separate actions.

We need to visually prototype something to make sure we offer an optimal workflow.

Comment 31

[Philipp Schlesinger]

I agree with you that there should be other ways to move a contact besides drag & drop.
But that is not the only issue: there is no way to see in which address book a contact currently is, e. g. if there a multiple Jane Does in the address book and one searches via "all address books", there is no distinction of contacts regarding their address books, neither via colors (like in calendar and tasks) nor via a hint stating the name of the address book.

While there may be better workflows to this, I think having the dropdown available as one option to move contacts would be fine and a common thing (even if it would only be transitionally): the calender and tasks in thunderbird also use this kind of dropdown to move items between calenders. In Nextcloud there are dropdowns to move calender items, tasks and contacts. Some android apps like Simple Mobile Tools and aCalendar use dropdowns to move items as well.

Comment 32

[Wayne Mery (:wsmwk)]

Attachment: Screen Shot 2022-07-08 at 8.38.53 AM.png

(In reply to Philipp Schlesinger from comment #31)

I agree with you that there should be other ways to move a contact besides drag & drop.
But that is not the only issue: there is no way to see in which address book a contact currently is, e. g. if there a multiple Jane Does in the address book and one searches via "all address books", there is no distinction of contacts regarding their address books, neither via colors (like in calendar and tasks) nor via a hint stating the name of the address book.

The address book column can be added, top right

Comment 33

[Philipp Schlesinger]

(in reply to Wayne Mery from comment #32)

The address book column can be added, top right

Thanks for the hint, this works for now in 'horizontal layout' (though the horizontal view is not optimal on smaller screens).

Please friendly consider adding the dropdown in the Edit contact view as it is a simple, unobtrusive approach used throughout all components in thunderbird.

Comment 34

[Philipp Schlesinger]

see also bug 595354