expose system contacts as address book to users

[jospoortvliet]

All users enter their name, choose an avatar, enter their email and more; often this is also loaded from LDAP.

If you're in a company and want to use the Contacts app, you make all employees add themselves, duplicating the work. As we have this data, we should allow the admin to save this work and simply show the system address book.

[Bugsbane]

To me, this is an important first step towards a larger, more important goal, which is providing a unified contacts interface across Nextcloud, which is used by all apps, just as contacts on Android is.

[joergmschulz]

while rethinking the contacts architecture, we should think a step further.
For good reasons, all contacts are unencrypted, This seems to be a must because otherwise *dav clients (like android caldav or like the mail app in owncloud) rely on these data.
Would an architecture be thinkable where we encrypt all contact data and provide end user tools like caldav with proper local decryption functionalities relying on local keys?

[MorrisJobke]

cc @karlitschek and @jancborchardt for the big picture

[jancborchardt]

What do @irgendwie @Henni @skjnldsv @nextcloud/contacts think? This could be a first step towarda better integration of system users and Contacts app. :)

[skjnldsv]

You mean provide an addressbook filled with the nextcloud users?

[jancborchardt]

Exactly :)

[joergmschulz]

Everybody should know the downside - when you want to host multiple organizations on one NC server, all system users will be exposed when there is no limitation of visibility by user groups like:

• Only show contact data of users belonging to the same groups
• exclude certain groups from this criteria (maybe your setup has a group 'all NC users').

[jancborchardt]

That's exactly why there will need to be limitation of visibility just like that.

[camicatze]

I have exactly the same problem.
School with 130 teacher in germany and over 3400 students.
We want to have one central address book for the 130 teacher (First think, one account shares it)
We have two options:

1. One account shares the teachers addressbook and keeps it up to date
   Problem: Now every user is duplicate because every teacher has a account, too. And if you type in Mr. XY to share with, you get two Mr. XY's (one account, one contact). It must be possible to only enable accounts in this option.

2. nd Option, every teacher has a useraccount an keep his address up to date by himself. But WhyTF(Sorry) is there no central addressbook for the usersaccounts? Can not understand it!

[skjnldsv]

Couldn't we use the circle app to provide circle addressbook? :)

[jancborchardt]

@skjnldsv this is something which should be in Contacts and not have Circles as dependency ;)

[skjnldsv]

Then I agree with the groups :)

[ali3seven]

Thanks for this post, but honestly say i'm afraid that we can use "Global Address Book" using next cloud itself. It means two possibilities:

1. you have the LDAP and have to do a Duplicate job for using "Shared Contact"
2. you have just Next Cloud without LDAP

But I think now neither the first nor the second didn't work as "Global Address Book" in the current NextCloud features. So I think we need more than a merge feature for contacts.

Let me take an example to make it clear. As admin you have client contact in your organization. you like to produce the present contact list automatically for each new client as soon as creating clients account.
You may also try to create some new contact in "you cloud space" and sync contact with that OR
Your Admin share contatcs for you that you can access that too.

But Admin Actually share the contacts and it's not any automatic job action right after new client account is created. It means the required job to sync the latest contact list is not very good to have robust contact list:
admin create client account + admin share the client account
briefly say:

Sharing contact job can NOT be equal to a Create Global Address List

Sharing term means for ... , ... and ... . but Global means for everybody. and expected specially for contact
Its also very good for file sharing and permission but absolutely not for sync contact list I think.
I read https://help.nextcloud.com/t/personal-info-visible-for-local-contacts-public-how-to-use/11147
but it seems it approve the lack of this function. I think it is a "requied" for many collaboration software.
However I wondered why NextCloud with such great features missing that. Let me know if we can use and create global address list using current feature too. However the only way I have found for such global address book is LDAP.

[jospoortvliet]

@camicatze if this is important for you tell your Nextcloud account manager/sales person so it can be prioritized.

@ali3seven sorry, I find it hard to understand the problem. You mean a single global address book doesn't work?

It might make sense to create a global address book per group and allow the sysadmin to share those with groups. So you can have users in each group have an address book of the users in their group; and you can share special address books including a group that has all users for example...

But offering all users in a single address book as first step is, imho, a big step forward already.

[ali3seven]

@jospoortvliet Jos, Thanks for reply. Let me explain it in different way.
We are using Mail-In-A-Box package which is included NextCloud latest version.
Everything works fine. It also pull the "Personal contact" from server in outlook very well using ExchangeActiveSync (EAS).
It means if you have an account then you log in to nextcloud and create some personal contact for yourself in web, then you add the account in outlook using EAS, all of your personal contact that you defined in the web will be synced very well.
The only thing that I didn't find is where can we define Global Address Book? it means... if I login as new user and didn't define anything as my personal contact in web url of next cloud server before, And then I want to add my account using EAS, I will not find anything in outlook as contacts. it didn't pull in outlook.
At this way, for each new user its necessary to define whole list of contacts as Global Address Book, that contains list of each previous users.
What I have did:
I try to login in nextcloud server using me@example.com which is super account of mailinabox. then I create some contacts. Pulling Contact form EAS Outlook also works but it seems just works for me@example.com (as personal and not global). And for other user did not work. However I think every new user will find these contacts as soon as add their account in Outlook using EAS.
Infact it seems Contacts defined as personal not global. Am I in wrong or anything miss here? or Any information about superadmin of nextcloud account that I can Login and create such Global Address book.
Thanks in advance

[jospoortvliet]

@ali3seven you're right, contacts are personal, not global. This would be fixed of we do what this issue proposes: make the automatically created system address book available for all users.

[alexanderdd]

Hey!
I just stumbled over this too.
Actually I have to create all cloud users by hand in the contacts app, there is not even a way to export the cloud users as csv (or did I miss it)? And I have to keep everything in sync by hand. Very cumbersome, and surprising to me that this issue was created in Aug 2016 and no one has acted upon it yet (yes I understand how open source dev works. still surprising.)

UX

• It is unintuitive that there are two places for contacts, top left (contacts app) and top right (cloud users)
• type "Tim Burton" in the search or when you want to share a file with somebody. You will see Tim twice, once the cloud user and once the contact. Who is the right one? Why are there two?

large installations: Above, people argued that it's not good to expose system contacts on large installations. I believe that most installations are private or corporate teams (can that assumption be backed by data from nextcloud reports?), so the standard expected behaviour is that system contacts are available to the contacts app. Just include a switch "dont expose contacts to contacts app".

I feel like this issue needs higher priority because it severely affects UX.

[jancborchardt]

@MorrisJobke @rullzer @skjnldsv we should probably talk about the current plans on this at the Contributor Week?

[wdfee]

It might make sense to create a global address book per group and allow the sysadmin to share those with groups. So you can have users in each group have an address book of the users in their group; and you can share special address books including a group that has all users for example...

But offering all users in a single address book as first step is, imho, a big step forward already.

Additionally the user preferences privacy options (private / contacts / public) should be extended with an "my groups only" option, with a checkbox for each group, where the user is member of. If selected, the information is shown only to group members of the chosen groups.

[skjnldsv]

@nickvergessen so like we discussed, security speaking, we should not do that, right?
But adding a way of specifying a link between a contact and a local user nextcloud/contacts#243 and to import an existing user to the contacts list, would be the way to go. Closing then?

[nickvergessen]

Well the "Link" already exists, the field in carddav is CLOUD

[alexanderdd]

@skjnldsv can you please be transparent and explain here why system contacts should not be exposed to address book?

And do I understand correctly that you want to allow users to manually link cloud users to address book entries? Because that does not solve the usability issue here. They should be linked by default.

I would like to have a brainstorming about possible solutions for the problem of consistency between cloud users <> address book entries. Should we do it here? In the forum? Over at nextcloud/contacts#243 ?

I kindly ask everyone to give a higher priority to this issue. IMHO it is the biggest UX issue at the moment, and it has been around since the beginning.

[skjnldsv]

I would like to have a brainstorming about possible solutions for the problem of consistency between cloud users <> address book entries. Should we do it here? In the forum? Over at nextcloud/contacts#243 ?

We already did so many times over the past two years.
This have been one of the most discussed issue.

While it would fit your needs to properly export the users as an addressbook, it is also a very big sensitive issue. All the users are suddenly exposed and it raises a lots of security privacy issues. Even if you allow a config there to disable this feature, it doesn't solve the issue in the first place.
Then comes the question of the technical. And oh boy it gets complicated.

Do we want to have one read only addressbook for the whole instance that is shares with everyone? Do you expose users groups to everyone?
To admins only? Then ux wise people are confused again, I can see everyone, but I cannot edit their data. Users only provide xxx fields, if I want to add a facebook handle or an address, they cannot. So they are creating duplicates of this user vcard to properly add more data. Or we let users add more of their info to their own vcards in the contacts app?
That would means we need individual permissions per vcard and this is technically not possible. So then we have users complaining because they don't understand the UX. Do I edit my infos in my profile? I'm an admin, I should be able to edit users in the contacts app! (etc etc)

To sum it up, it is a pandora box. Opening it will just create 10 more ux issues.
And technically a very hard task.

As this sounds like a nice feature, currently there a no plans to implement such a feature. Thus I will leave this ticket closed for now. This does not mean we don't want this feature at all, we definitely agree that it could be an interesting take, but it is simply not on our roadmap. If somebody wants to implement this feature nevertheless we are happy to assist and help out with some pointers, but as an external app.

[alexanderdd]

Hello @skjnldsv & Nextcloud community,

Thanks for the summary & thoughts!

If this has been discussed many times, can you please provide a link to the discussions? I could not find anything. Or do you mean it was discussed offline?

• In a professional work context, it is normal to have a company directory with contact information that you cannot change. If you want to add things, you have to copy the contact to your personal address book. I think this can be implemented with good UX, e.g. Google's G-Suite does it too. The fields you cannot edit can be greyed out.
• you keep talking about contact information being "exposed" as if this was always a dangerous thing. As I explained, in my use cases (and I would argue more two thirds of all Nextcloud installations), I want contact info to be exposed, because its a team that wants to work together. Yes there also needs to be a solution for the other nextcloud installs where contact info should not be exposed, but we cannot ignore the majority use case.
• If no-one is developing the "near-perfect" solution right now, we should at least develop a smaller fix to mitigate severe UX problems. As I said, I believe that the current situation is such a bad, confusing UX, that Nextcloud should not close their eyes (i.e. close the issue) but rather redirect development resources towards this issue. (I mean the issue "why are there two users with the same name? I want to share something - which is the right one?"). If Nextcloud takes pride in good UX, this needs to be fixed.

My proposal (should I open a new issue?):

1. when sharing a file, in the field where you type the username, add the source of the contact. For example, when typing "Tim", it should display "Tim Brown (user of this cloud)" and "Tim Brown (my address book)". Then people are still confused which option to pick, but at least they understand why there are two different Tims.
2. in the contact search at the top right, display only cloud users, not entries from the contacts app. Especially if you use other apps like talk, the cloud user is what you want there. If you want to write an Email to someone from your address book, you will go to the email app or the contacts app anyway. This top bar is perceived as "part of my cloud", so it makes sense to display only cloud users there. OR do the same as in 1. "Tim Brown (user of this cloud)" and "Tim Brown (my address book)".

[jancborchardt]

• when sharing a file, in the field where you type the username, add the source of the contact. For example, when typing "Tim", it should display "Tim Brown (user of this cloud)" and "Tim Brown (my address book)". Then people are still confused which option to pick, but at least they understand why there are two different Tims.

No, we worked towards getting rid of exactly this confusion. If there are multiple ways to share with the same person (Nextcloud share, federated share, email), then it should just be shared with the most integrated way possible. So if the person has an account on the same cloud and is a contact → show only one entry, and pick Nextcloud sharing. (They also get an email notification on share by default.)

• in the contact search at the top right, display only cloud users, not entries from the contacts app. Especially if you use other apps like talk, the cloud user is what you want there. If you want to write an Email to someone from your address book, you will go to the email app or the contacts app anyway. This top bar is perceived as "part of my cloud", so it makes sense to display only cloud users there. OR do the same as in 1. "Tim Brown (user of this cloud)" and "Tim Brown (my address book)".

Yes, the contacts menu on the top right has not been worked on in some time. Plenty of things could happen there:

• System users are prioritized over contacts
• Combine the system users and contacts
• Best: Sort people you interact with often up top

So yes, best to open a new issue for that, thank you. :)

---

Regarding the issue at hand: Design-wise this is something we should ideally do, also yes because people are used to it from Google Suite. One of the big blockers (from what I understand) are our commitment to using open protocols, and that we don’t have so many resources on Contacts.

@alexanderdd if you have a good concise proposal for this, a new separate issue would be better as well, as this one is too long of a discussion to be useful at this point. :)

[ssebech]

Groupware means collaboration, i.e. also communication in collaborative group(s). Contact information exposure is a must!

[jospoortvliet]

@ssebech yes, we know, a solution would be good, but repeating that won't make it any easier... I think the problems are well explained above.