'Link' Groups and Address Books

[unalignedcoder]

Is your feature request related to a problem? Please describe.

I love the contacts app, but 'Groups' and 'Address books' make little sense the way they are.

Consider this:

1) On the web interface, I cannot 'click' on an address book and see its content or manipulate it. I can only do that via a device. With groups, it's the opposite! I can select a group and look at its content and to an extent manipulate it, but this is irrelevant anywhere else except on the web interface.

2) Even assuming I manually do the job of replicating the content of groups into address books, or vice-versa, this requires constant maintenance. If I modify an address books, by adding a contact to it via a device, I need to manually repeat the operation in regards to the group. Either one or the other are destined to carry outdated data.

4) If I reinstall Nextcloud, I can easily import address books, and have my contacts conveniently organized for devices. Conversely, while I can download groups, I can only re-import them later as address books (?). On a new installation the user has to recreate all the groups once more.

Describe the solution you'd like

I suggest something like this:

Groups could be 'linked' or 'not linked' to Address Books.

1. When importing an address books into the contacts, or selecting it in settings, the user should have the option to 'create a linked group of the same name'.
2. If a user realizes they need their groups to be address books, so that an external device can recognize them, there should be a function to 'create a linked address book from group'.
3. 'Linked' groups and Address books would be automatically kept in sync. If a contact changes Address book, this will apply to the groups also. The user would make their changes on the web interface by looking at groups, knowing the changes are carried through to their linked Address books. No need to repeat a manual action twice!
4. By default, groups would be unlinked from Address books, the way it is now. So an update carrying this functionality wouldn't create any havoc.

[RokeJulianLockhart]

@brucehaynes, please delete your comment, because it is irrelevant to this problem. Instead, ideally report your problem at https://github.com/nextcloud/contacts/issues/new?assignees=&labels=bug%2C0.+Needs+triage%2Cfeature%3A+contacts&template=bug_report_contacts.yml, or contact Nextcloud support or your hoster to assist you.

[pkoevesdi]

I'd like to add another annoying difference: only for adress books I can get a dav-URL. I'd like to get it for groups too. And for "all contacts" too. So, the inconsitency as described continues also in reference to DAV Urls.

[madeda]

+1 for both @unalignedcoder and @pkoevesdi. It's quite hard to understand the differentiation between groups and addressbooks. The seem to have the same purpose, but are handled that different. Does anyone have an idea, why NC has these both types of contact clustering?

[madeda]

OK, as I understood now: It's possible to assign multiple groups to a single contact, that's not possible for addressbooks.

Correspondingly, it's also possible to have a contact not assigned to any group. Those contacts are separately listed in the "Not grouped" folder. But there is no possibility to export those contacts (as it's not possible for "All contacts", too), neither there is an WebDAV link to use them remotely.

Otherwise, each contact needs to be assigned to one addressbook.

Hopefully not just @unalignedcoder, @pkoevesdi and myself are confused by this.

[RokeJulianLockhart]

@madeda, so groups are equivalent to non-hierarchical tags, whereas address-books are equivalent to hierarchical directories?

[madeda]

@rokejulianlockhart Yes, you are right. That is what I found out, in other words. And I am totally fine with this approach, as it allows people to manage their contacts in both ways. However, there are still some pitfalls with it: Afaik, almost all contact apps in the different ecosystems (IOS, OSX, Android, Win ..) are not aware of groups (or better say Categories in VCard schema). They do not allow to edit them, or even make them visible. As one of the most import reasons for using NC (at least for me), is to be independent from vendor specific cloud solutions and contact syncing, and to include all clients to sync to the same information, groups have simply a very low usability.

On the other hand, if someone uses address books, following this conclusion, it becomes quite hard to manage them:

• In the NC Contacts Web UI is not possible to see the content of a single address book, you can filter by groups only.
• Thus, it's also quite hard to manage an address book, or to edit the contained contacts in the Web UI
• The contacts list does not give you this simple information, what's the address book, a contact comes from. You need to click on each single contact to see this --> I guess that's the reason why people frequently asking for syncing or linking address books to groups: they are using both with the same categorisation to get address books to be manageable in the NC Web UI.
• I really missing bulk operations like
  • Moving contact(s) from address book A to B
  • Removing/adding a certain group from/to a selectable list of contacts
• Following the suggestion of @unalignedencoder: When creating a new contact, either with any device or an vCard import into any address book, they usually will not have any group assigned. Couldn't they be added to a group having the same name than the address book? Or even to a default group, you can select when importing? The NC default group is "not grouped" - that's funny, as one of the tools using groups I have found (vCard Editor 2/MacOs) , is adding a group "all contacts" to each contact automatically.

Let's face a very simple use case: Consider a family with to parents and two children. There are contacts belonging to just one family member, there are others used by the parents, some by the children, and some which are needed for the overall family like grandparents. Using address books I must create the following ones: Family, children, parents, and four personal ones. And when a, e.g. personal contact must be visible for other family members I need to move it from one address book to another, which is exporting the contact to vCard, removing it in the old address book, an importing the vCard in the new one. From an usability point of view, this is quite poor. Thus, let's look for groups instead.

How is that when using groups? I would have one single address book, and adding one of the groups family, children, parents or single person to the contacts. But: There is no WebDav Url, to access these groups from any device. A simple Dav Url to present them as address book would really help. For my case I have to sync my devices to three address books: The personal one, parents, and family. There is still the question, to which group contacts newly added on the device, will be assigned now. Maybe simply to the group which the Dav URL is assigned to?

Having more than one group assigned to a contact, and using these groups via Dav is obviously a problem: As they are exported to more than one Dav URL, they may be duplicated on a device, which is conected to more than one of these groups. So e.g. contacts being in group family, must not be in parents as well. From that what @rokejulianlockhart said, I am aware that this approach is somehow abusing the idea of non-hierarchical tags, to build up a hierarchy.

On the other hand, I just tried what @unalignedcoder observed here "If I reinstall Nextcloud, I can easily import address books, and have my contacts conveniently organized for devices. Conversely, while I can download groups, I can only re-import them later as address books (?). On a new installation the user has to recreate all the groups once more."

Actually it is possible to import contacts to an address book based on an export either from a group, a single contact or an address book - and the group information is still there. Even missing groups are created, when importing, that's quite good.

tl;dr I guess the main reason why people struggling with groups and address books in NC is the lack of support in the NC Web UI: No filtering for address books, no information which address book a contact belongs to in the list view, and no simple operations fro editing/moving contacts or even bulk changes.

[RokeJulianLockhart]

In which case, instead of this silly duplication of the directory structure, would it not be superior to actually store the VCard files for each contact within subdirectories of where the contacts are currently stored? That is, use the filesystem for this purpose rather than add a custom layer to achieve the same thing? All that Nextcloud need do is recursively search to acquire contacts.

(I'd even go as far as to say that Nextcloud should ideally use the filesystem to store its tags, as I currently do with BTRFS, but storing them within the vcf files is probably more conveniently portable.)

I'm actually supportive of innovation even at the cost of interoperability IF NECESSARY, but this is totally unnecessary, and actually increases the burden of development.

[madeda]

Hi @rokejulianlockhart, I am confused now. Does Nextcloud currently use the filesystem to store VCard files? On my installation they are stored as blob in the maria DB, and I did not found any physical VCard files in the filesystem. So you are talking about a possible future improvement? Would be great, as it gives someone the possibilty to move contacts from one address book/folder to another, just with a file browser.

On the DAV layer address books are already represented by a subfolder in the URI, and the folder is virtually created and mapped back from the DB by Nextcloud, right? That also means, clients are enabled to move contacts from one address book to another, smartly (but there are only few providing this afaik). On the other hand Nextcloud groups are represented by the field "category" in the VCard. But within the VCard file there is no information about the address book.

So what I am asking for are simply spoken just some little things, to either complete the functionality of addresbooks or groups. "littIe things" is maybe an euphemism, coming from my outdated experience as developer :-) I don't think these are unnecessary things and workarounds by means of a custom layer:

• make address books transparent for users, by providing a filter or a direkt link to the content of a certain address book in the NC Contacts Web UI
• show the address book, a contact comes frome, in the list view of contacts when filtering by group or showing all and ungrouped contacts
• provide a function for bulk moving a contact from one address book to another in the Web UI (maybe not that simple, but doing this for a single contact is already possible when editing in the WEB UI)
• optionally provide WebDav URLs for groups, to allow clients, not aware of groups or categories, to use them.

[RokeJulianLockhart]

@madeda, actually, a database isn't an awful solution to the problem, because of how extensible it is able to be. VCard files are probably only best as a medium of interchange. I suppose that I should have considered why they chose such a solution before somewhat foolishly proclaiming that it was incorrect.

[FBachofner]

Hi @madeda @unalignedcoder et al

tl;dr I guess the main reason why people struggling with groups and address books in NC is the lack of support in the NC Web UI: No filtering for address books, no information which address book a contact belongs to in the list view, and no simple operations fro editing/moving contacts or even bulk changes.

Bingo!

Some of your other comments seem to indicate you may feel separate address books may not be as useful as categories and other methods for organizing contacts.

To anyone who may think along those lines, I would ask you consider that (especially?) structured databases like this should embrace the highest possible data granularity.

One aspect of this is who owns the data. A separation of data into various address books ensures this (and in a very simple way!) and enables much greater adaptability to various use cases.

[ Side note: because of the short sighted refusal of the original designers of VCF-like contact systems to NOT embrace Codd-normalized data structures, "real" granularity, master-detail linking, searching/sorting and many other common DB features actually become "difficult" to implement as the wheel needs to be reinvented (rather than simply being able to use fairly standardized SQL). ]

BUT . . . easier management of address books themselves is the low hanging fruit to address some of the biggest shortcomings of the VCF-inspired design which NextCloud adopted (likely to make it easy to interact with all the smart devices in use, which also all adopted this standard).

I pointed out the tremendous shortcomings in NextCloud's address book management in July 2020. While some improvements have (thankfully) been made, overall it is still a mess and that enhancement request is still open.

As I mentioned in the linked thread, the shortcomings in address book management is likely a "blocker" to significantly greater enterprise uptake of NextCloud. It's too bad, really, as this issue (if solved) would likely lead to greater revenue to NC through increased enterprise uptake and therefore correspondingly faster feature improvements elsewhere in the system.

EDITED: with more friendly respect to the "short sighted" original designers of VCF-type contact management systems