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

• [Bug]: System address book is not syncable #38141
• Store local properties in system addressbook too #38021
• Write profile properties and backend properties to system address book #37800
• Assign managers to users and map value in the system address book #37963
• [Feature] CardDAV - expose system address book #37797
• Frontend part: expose system address book contacts#3317
• Raw z-app-generated--contactsinteraction--recent URI visible to user contacts#2187
• Document system addressbook for admins documentation#10020
• Document system addressbook documentation#10021
• [Bug]: ContactsSearchProvider not respecting share enumeration #37799
• [Research] federated sharing and exposing the system address book #37798
• Add repair step to remove all guest users from system address book

[georgehrke]

Duplicate of #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 #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.

[jancborchardt]

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

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

[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?

[ChristophWurst]

Idea: materialize all properties that are at least local. Those props should be readable to other users. Store the scope next to the prop value inside the vcard and when we send data to another server we filter out all properties with the local scope, so only published and federated data remains.

Alternative: build two materialized address books. One for local use (system address book in the new sense) and a federation addres book (system address book in the old sense).

[ChristophWurst]

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.

We do not. The address book only contains federated and published data. Local data (which would be ok to expose to others) is missing as per above.

[schiessle]

Idea: materialize all properties that are at least local. Those props should be readable to other users. Store the scope next to the prop value inside the vcard and when we send data to another server we filter out all properties with the local scope, so only published and federated data remains.

Alternative: build two materialized address books. One for local use (system address book in the new sense) and a federation addres book (system address book in the old sense).

I discussed the second option with @miaulalala but I like the first idea with the prop value if it is technically feasible to filter during the sync process. This would avoid having yet another address book.

[tcitworld]

Local data (which would be ok to expose to others) is missing as per above.

There should be a way to opt out of system addressbook, for instance on a server where not everybody has to know each other. Otherwise you can just create lists of users, which can be troublesome.

[ChristophWurst]

Local data (which would be ok to expose to others) is missing as per above.

There should be a way to opt out of system addressbook, for instance on a server where not everybody has to know each other. Otherwise you can just create lists of users, which can be troublesome.

It is planned for the system address book to respects share enumeration settings. If an admin configures Nextcloud to now show other users, the system address book will also not show anyone else.

This is part of acceptance criteria "Respects sharing settings for user enumeration"

[ChristophWurst]

I discussed the second option with @miaulalala but I like the first idea with the prop value if it is technically feasible to filter during the sync process. This would avoid having yet another address book.

We will give this a try. The change is tracked in #38021.

[ChristophWurst]

Add repair step to remove all guest users from system address book

@miaulalala is this still to do or done with the filter for guest users when exposing the SAB?

[miaulalala]

Add repair step to remove all guest users from system address book

@miaulalala is this still to do or done with the filter for guest users when exposing the SAB?

I thought that was done with the Migration but that doesn't seem to be the case. I will look into it.

[ChristophWurst]

Add repair step to remove all guest users from system address book

@miaulalala is this still to do or done with the filter for guest users when exposing the SAB?

I thought that was done with the Migration but that doesn't seem to be the case. I will look into it.

Can't see what's missing in the current state. Seems fine.

[ChristophWurst]

From my notes

Options

1. Expose system address book as is, with guest users
2. Exclude guest users
3. Somehow try to separate guest users

Seems 1 is simplest, 3 is the best case, but 2 might be the best balance

So currently real users see guest users but guest users don't see anyone else. It's the simplest yet acceptable solution.

[chrisherzberg]

Hi all,
is their any update on this topic? We are using nextcloud 27.0.2 and would like to access the system address book via cardDav but we can´t. The personel addrssbook works fine.
Thanks
Christian

[julianwinkel]

Hi all, is their any update on this topic? We are using nextcloud 27.0.2 and would like to access the system address book via cardDav but we can´t. The personel addrssbook works fine. Thanks Christian

Do you try this: occ config:app:set dav system_addressbook_exposed --value="yes"
https://docs.nextcloud.com/server/27/admin_manual/groupware/contacts.html#address-book-sync