Show system address book as read-only address book in contacts

[schiessle]

In organizations it is quite common that you want to have a shared address book with the contact data of all your colleagues.

Today you can achieve this with a address book created within the contacts app and shared with all others. But this has some issues:

1. If you share it read-only someone has to be in charge to keep it up to date
2. If you share it read-write so that everyone can add their own contact data people have to maintain their information twice, once in "contacts" and once in the personal settings.
3. If you share it read-write you risk that people delete contacts by accident, add contacts which doesn't belong to the address book, etc

All information from the personal settings are already written to a carddav system address book. So technically we already have everything we need in the back-end. The idea is to expose it to the contacts app for all users and via carddav in a read-only mode. This way:

1. Every time someone updates their personal settings or if they are updated in a central user management like LDAP the address book will be updated as well.
2. People don't have to maintain their information in multiple places
3. You don't risk that people delete contacts by accident or add personal contacts which doesn't belong to the address book.

~~Of course there should be a Admin switch to enable/disable this behavior. In most organizations this will be quite useful but of course a shared hoster for example doesn't want to present all users in a address book to all the other users (Although keep in mind that they do it already though the "people menu" which can not be disabled so the feature suggested here has no additional impact on the users privacy).~~ The feature should respect the existing sharing and user enumeration settings.

Acceptance criteria

• Data sources
  1. User backend
  2. Profile
  • Respect profile privacy settings
• Exposed as read-only CalDAV collection
  • Has to be listable in Contacts app
  • Has to be readable by CalDAV clients
  • Name: "Accounts" (should have localized display name, if possible)
• Respects sharing settings for user enumeration
• Do not show in share dialogue (would duplicate users)
• Org chart continues to work
• Mapping
  • Manager -> X-MANAGERSNAME (set by admin via user management, not the user)
    • Optional: map from LDAP
  • Display name -> FN
  • Primary email addresses -> EMAIL (without TYPE)
  • Secondary email addresses -> EMAIL (without TYPE)
  • Phone number -> TEL (without TYPE)
  • Organisation (to be renamed to Company) -> ORG
  • Role (to be renamed to Title) -> TITLE
  • Location -> ADR
  • Language -> LANG
  • Profile page https://cloud.domain.tld/u/<uid> (if enabled) -> URL
  • Optional: https://cloud.domain.tld/apps/spreed/?callUser=<uid> -> URL
  • Optional: Nextcloud groups -> CATEGORIES (if possible and OK with data privacy)

Work packages

• [ ] https://github.com/nextcloud/server/issues/38021
• [ ] https://github.com/nextcloud/server/issues/37800
• [ ] https://github.com/nextcloud/server/issues/37963
• [ ] https://github.com/nextcloud/server/issues/37797
• [x] https://github.com/nextcloud/contacts/issues/3317
• [x] https://github.com/nextcloud/contacts/issues/2187
• [ ] https://github.com/nextcloud/documentation/issues/10020
• [ ] https://github.com/nextcloud/documentation/issues/10021
• [ ] https://github.com/nextcloud/server/issues/37799
• [ ] https://github.com/nextcloud/server/issues/37798
• [ ] Add repair step to remove all guest users from system address book

[georgehrke]

Duplicate of https://github.com/nextcloud/server/issues/693

[schiessle]

People think it makes more sense to have it in the server repo, although from my understanding it is mainly a contacts-app question if and how the app exposes the address book which already exists in the server. Nevertheless I will let others figure it out.

I think it is a well defined use case which makes sense to discuss independent from https://github.com/nextcloud/server/issues/693 which went in many different directions. That's why I prefer to keep it as a separate issue.

I don't see a privacy issue here because the exact same information are already exposed over the "people menu" which is always enabled (no way to disable it) while the suggested feature here would be opt-in.

[jospoortvliet]

I agree that 'just' solving this basic case is legit. It doesn't have the privacy issue (as it can and should respect the privacy settings in the user settings) and provides a useful feature on internal/private instances while it can be disabled (or should be off by default?) on public/hosting provider instances. We might be able to get away without a setting as we have other settings for hosting provider like instances already, in sharing (don't auto-complete or something like that).

[SomeFixItDude]

Please implement this feature.

We also use nc to sync contacts to mobile devices. Since we need phone numbers and email addresses the same exact users in the system contacts are also in the users contacts. As a result, when in the files app and you want to share a file you begin typing in the name of the user. Two entries pop-up and we are counting on the user clicking the system user.

Thank you!

[adamshand]

Has there been any progress on this? It would be very helpful if system users could show up in contacts!

[whiskeytangofoxy]

+1 for another interested user in this feature.

[jancborchardt]

Very related issue, possibly duplicate @ChristophWurst https://github.com/nextcloud/contacts/issues/2361

And also related app, for LDAP at least: https://github.com/nextcloud/ldap_contacts_backend

[scratch-a]

Đã gửi từ iPad của tôi

Ngày 17 thg 3, 2022, vào lúc 20:18, Jan C. Borchardt @.***> viết:

Very related issue, possibly duplicate @ChristophWurst nextcloud/contacts#2361

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[ghost]

A Users and Groups directory would be very useful indeed.

[ghost]

Is there any progress on this? Is there any progress on this? Synology and co all have this feature.

[ghost]

Is there any progress on this? Is there any progress on this? Synology and co all have this feature.

Not really, no. They seem to think that people in the same organisation are not allowed to see other people working in the organisation. I find that to be a bit extreme, given you usually do know the people you work with anyway and that in most orgs people use their business contact info and not their private ones but you know, "privacy concern" is a great argument to weasle yourself out of doing work too these days. Collaboration by it's very definition eliminates user privacy to some degree. At this point, I'm considering hiring a developer myself to build an app that list the users and groups (read only). Will update if and when that happens.

[ghost]

I think the developers are doing their best. And I hope we will eventually find a solution. All the organizations I know use such a feature whether at Teams, Synology, ... and with Nextcloud we still have to add it manually. I don't think it's a permanent solution and believe sooner or later the feature will come.

Personally, I do not see any concerns of such a function. But we can talk about it here.

@nickvergessen @jancborchardt @ChristophWurst What speaks for the moment against such a function?

[ghost]

I think the developers are doing their best. And I hope we will eventually find a solution. All the organizations I know use such a feature whether at Teams, Synology, ... and with Nextcloud we still have to add it manually. I don't think it's a permanent solution and believe sooner or later the feature will come.

Personally, I do not see any concerns of such a function. But we can talk about it here.

@nickvergessen @jancborchardt @ChristophWurst What speaks for the moment against such a function?

I know, I was being sarcastic. Their argumentation on this matter is mentioned in this thread: https://github.com/nextcloud/server/issues/693

[ghost]

I think the developers are doing their best. And I hope we will eventually find a solution. All the organizations I know use such a feature whether at Teams, Synology, ... and with Nextcloud we still have to add it manually. I don't think it's a permanent solution and believe sooner or later the feature will come. Personally, I do not see any concerns of such a function. But we can talk about it here. @nickvergessen @jancborchardt @ChristophWurst What speaks for the moment against such a function?

I know, I was being sarcastic. Their argumentation on this matter is mentioned in this thread: #693

Thank you, I have already read it. But that was a few years ago now and maybe something has changed since then.

[nickvergessen]

If it works for your personal usecase that's great, but doesn't work for:

• providers: think of a provider giving you free accounts or allowing you to buy storage space
• university/schools: giving you access to the names and details of thousands others

[ghost]

If it works for your personal usecase that's great, but doesn't work for:

* providers: think of a provider giving you free accounts or allowing you to buy storage space

* university/schools: giving you access to the names and details of thousands others

So perhaps a setting to enable it would be really useful too.

[ghost]

If it works for your personal usecase that's great, but doesn't work for:

* providers: think of a provider giving you free accounts or allowing you to buy storage space

* university/schools: giving you access to the names and details of thousands others

Therefore, the function could be disabled by default and the system address book is created and displayed only when enabled.

[SomeFixItDude]

Be nice if this was implemented and configurable. Issue been open for 2 years, so not looking like it will be.

[TristanCottam]

If it works for your personal usecase that's great, but doesn't work for:

• providers: think of a provider giving you free accounts or allowing you to buy storage space
• university/schools: giving you access to the names and details of thousands others

Making such a feature available on a per-group basis would solve this issue.

[derekpurdy]

Looking for this feature as well.

[fabien-anabasis]

A major downside of how things work for now is that when I want to invite a user to an event in the calendar, things work differently if I select the contact or the user… :-(

[clayrisser]

I'm still watching this. Looking forward to it as well.

[mrtn223]

This would be a very cool feature - I‘d be very happy to see it implemented.

[miaulalala]

@schiessle what about federated sharing? I saw some code instances where federated sharing was accessing the system address book. Should this behaiour be influenced by the backend option I have added?

[miaulalala]

Split in work packages:

• [ ] Expose address book (respect share enumeration) - don't forget frontend part in Calendar, backend part already WIP
• [ ] Research: federated sharing and the system address book - how does federated sharing work - will exposing the address book break the instance encapsulation (i. e. are other system address books accessible through federated sharing, is that wanted, what happens with share enumeration etc)
• [ ] Fix search provider enumeration (with backports to 25) if it's not already filtered somewhere else
• [ ] Write profile information to system address book (with above mentioned mappings) and map backend properites to above mentioned mappings

[tcitworld]

I saw some code instances where federated sharing was accessing the system address book. Should this behavior be influenced by the backend option I have added?

Trusted servers exchange each other's system addressbooks, in order to ease file sharing with users from external servers. As federation is limited to file sharing at the moment, I don't think we should expose those addressbooks as well.

[miaulalala]

I saw some code instances where federated sharing was accessing the system address book. Should this behavior be influenced by the backend option I have added?

Trusted servers exchange each other's system addressbooks, in order to ease file sharing with users from external servers. As federation is limited to file sharing at the moment, I don't think we should expose those addressbooks as well.

Do you know if getting the VCards from principal/system/system would expose cards from other system principals too? Or is it safe to add the principal to the addressbook home?

[tcitworld]

Nope, everything seems to be exposed. The only way to filter them may be to use the CLOUD property.

[miaulalala]

Nope, everything seems to be exposed. The only way to filter them may be to use the CLOUD property.

~~But also $shareWithTrustedServers needs to be set to true/yes, no? That could possibly be enough.~~ Nevermind I misunderstood the purpose of the setting. Thanks Thomas!

[schiessle]

tested with @miaulalala: Each server has their own address book: