Contacts: Ability to share groups

[Mannshoch]

Replace the current "Adressbook" with Groups that could be upgraded to an Adressbook what means that this Group has the ability to get shared by Carddav.

[MariusBluem]

What would happen then, if you assign multiple groups to one contact? ;)

[Mannshoch]

Thats the effect I wish. I could set up a Group "Private" which allow me to connect all my "Private" and "public" contact in separate address book, but I'm also able to share a set of specific Contacts in the Group "Familiy" with my Family and only add a limited set of Companys in the "Busines" group to my Outlook (CalDav Synchronizer).
At moment I set up a nextcloud for a Club I'm a Member and If maybe in Future a Federated contact share is possible I maybe could sync their Contacts with my Private adressbook and be able to avoid double contacts.

At Moment I have little Problem with double contacts because they fit in more then one Address book. These five guys I know without problems. But what happened in Future?

In my Opinion It should be able to rise a Group to an Addressbook group.
Maybe (I do not need it) a little overview is able to show me Conacts that fit in more then one Address book.

[Mannshoch]

What you think about this @MariusBluem ?

[jancborchardt]

The issue here as far as I can see is that many clients only support syncing one address book, or at least make it difficult to sync more than one address book.

What we should really do hence, is simply make groups shareable via the Nextcloud Share API. cc @nextcloud/contacts @nextcloud/sharing

[Jab2870]

@jancborchardt Is there any update on this? Being able to share groups or individual contacts via the Nextcloud API would be very helpful. I, too, would like to share a Family group with family members.

[skjnldsv]

@nextcloud/contacts this should be in server right?

[jancborchardt]

@skjnldsv not sure if CardDAV itself supports sharing? What do you say @schiessle @nextcloud/sharing – should this be in the server or in the Contacts app?

[irgendwie]

We should be able to do this with JavaScript by fetching the contacts with a filter on the groups, combine the resulting vcards in one file and make it downloadable. Still, with big pictures or huge amounts of contacts it would be really slow. A server-side solution would be faster.

[skjnldsv]

Yep, agreed. I'm against doing it client side. The app is heavy enough already! :)

[jancborchardt]

@irgendwie @skjnldsv maybe it’s best if you open an issue in the server repository with some plan / todos for it? :)

[barthel-eu]

From https://nextcloud.com/sharing/
"Sharing is who we are. At work, we share and collaborate with colleagues to get work done. At home, we share our good and our bad moments with family and friends. With Nextcloud, sharing is a core part of your experience."
Unfortunately we are forced to share either the whole address book or nothing. That ... is unrealistic. Reality is that we human beings share either "groups of contacts" or single contacts, but to share a single contact we do not want to share our entire personal address book.
A single contact we can share through the VCF. So while we may not share such remotely, we must at least be able to share them with fellow NextCloud-users. Or we have multiple datasets. It is also impractical to use different address books, as else we start searching our address books, which is what CardDav was developed for: To remove the need to run multiple address books. Or so I thought.

[jancborchardt]

@schiessle could you comment here regarding sharing feasibility?

[rullzer]

Just a comment here. Files sharing and DAV (so calendar/contacts) sharing are completely distinct.

[jancborchardt]

@rullzer @schiessle yes – however, could we maybe help come up with a way to handle this? :)

[skjnldsv]

@barthel-eu The issue here is based on the vcard specification. Groups are written there. A group is not an entity on the nextcloud server. What you request is basically like sharing a "birthday" where every contact having the same birthday would be shared to the user you want. It's also unrealistic.

We could on the other hand create and map vcard to a group entity on the nextcloud instance, but this could get very heavy. 😕

[barthel-eu]

@skjnldsv The issue is that "sharing" is what Nextcloud claims, but does not deliver. As a user, I do not "know" how it can be done, I was looking for the answer to that, seen it in groupware. I just think this is a prime sample what Nextcloud claims to do: Sharing. But does not deliver (yet) upon? Not in regards to sharing contacts.

[gerbsen]

Would it be possible to share individual contacts or groups with circles from this app: https://github.com/nextcloud/circles ?

[Loki3000]

Think that solution could be easy way to move contact between addressbooks. Now we can't create contact and share it. But if would be possible to move contact in another addressbook, then we can share it's another addressook.
What you think?

[barthel-eu]

@gerbsen - circles is like a mailing list tool, where you register "users", they can maintain their data themselves. But we talk about address book. My address book contains +400 entries, of which the majority are business contacts I want to share with other NextCloud users on our NextCloud installation.
NONE of those users wants to maintain a foreign NextCloud profile. You don't want to contact 300 different companies you work with and update your contacts, that's not how it works in real life.
ANY groupware allows shared contacts, as nothing is more idiotic in a team if you apply a change to a commercial contact and the rest of the group does not know about it and works with outdated phone numbers until they also learn better and then manually update what was known to your peer.
In a common workgroup you suddenly run 10-20 different datasets for the same contact in one environment. That is not contemporary, not well designed. It's one of the reason of success for social networks and groupware. Again, NextCloud claims it's about sharing. Not sharing a vital aspect like "contacts"?
Side note: I made a lot of money in my live "naturalizing" CRM data. Where companies moved to CRM and "groupware", but needed to merge the different previously used contact files, be it Excel, Word, VCFs, but also "uncommon" formats. And where i.e. "Lufthansa German Airlines" was identified as different from "Deutsche Lufthansa AG", different from "Lufthansa", etc., etc., - you don't believe how many ways people write phone numbers. I had a small startup with five different users in their OwnCloud with about 20-30 000 contacts each. The CRM (CAS genesisWorld) they trialed identified 3% duplicates. We found another 68% (total of 71% where duplicate). Guess the worktime invested. And their "sales" had another version than "support". Which is why they needed a groupware/CRM. OwnCloud did NOT do what they believed it would. Neither does NextCloud.

[barthel-eu]

A minor thought I thought to clarify. There are two (three?) approach angles and steps (first one first).

Step 1 (priority): My initial approach was "internal", so that I can i.e. assign contacts to groups and intentionally share that group to other users on the same Nextcloud installation (like in a CRM). Purely internal. Most pressing. The other Nextcloud user must be able to share those "naturally" with his devices, edits by that user matching the master dataset.
_Nice to have_ would be to have a "readonly"-flag when sharing with info on the user side who "owns" the dataset.

Step 2: Sync only and exclusively that given group with my smartphone/PC (or multiple sync-pairs). Duplicates resulting from duplicate grouping being my own problem.

Step 3: Optional, not really worth the trouble IMHO... Make the group accessible through CardDav with non-Nextcloud users (security, read-only, write?). Main problem there is a bug in the CardDav-interpretation, causing reproductive trouble if a user uses deprecated or "custom" fields like PO-Box. That's why I don't much bother about Step 3 myself.

[PackElend]

I had a similar request, see #111 and calendar#328, what could be solved by this approach as well.

[skjnldsv]

Closing since this is basically #111 with #213 groups