Write profile properties and backend properties to system address book

[miaulalala]

Part of https://github.com/nextcloud/server/issues/19575

Part 1: read from user backends Part 2: write to VCARD

Mapping

• [x] Display name -> FN
• [x] Primary email addresses -> EMAIL (without TYPE)
• [ ] Secondary email addresses -> EMAIL (without TYPE) https://github.com/nextcloud/server/pull/38073
• [x] Phone number -> TEL (without TYPE)
• [x] Organisation (to be renamed to Company) -> ORG
• [x] Role (to be renamed to Title) -> TITLE
• [x] Location -> ADR
• [ ] ~~Language -> LANG~~
• [ ] Optional: 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)

[ChristophWurst]

It looks like role and organization are among the props intentionally not published: https://github.com/nextcloud/server/blob/74f31bac8c0473f3dc92fcb54967f4cf977c413f/apps/settings/src/constants/AccountPropertyConstants.js#L148-L154

@Pytal do you recall the details of this? Do we just not want the four props to ever hit the lookup server? I'd like to use them in the system address book.

This is also related to https://github.com/nextcloud/server/issues/19575#issuecomment-1527375723. I hope that we can store more local properties in the system addressbook and perhaps filter when we send data to other server?

[ChristophWurst]

@nickvergessen says these props were not meant for publishing but only the profile.

So two options here

1. Leave the limitation and accept that the system address book has no role nor organization
2. Change the allowed scopes of role and organization so they can be stored in the system address book and sent to other federated instances and the lookup server

[Pytal]

@Pytal do you recall the details of this? Do we just not want the four props to ever hit the lookup server? I'd like to use them in the system address book.

Can't be super certain but iirc as those 4 new properties were only for profile they were not added to the list of properties to be published alongside the ones in https://github.com/nextcloud/server/blob/d6847a975767bb610018d531d614b50f1da09a98/apps/dav/lib/CardDAV/Converter.php#L59C1-L95

[ChristophWurst]

So two options here

Option 3: We will address https://github.com/nextcloud/server/issues/19575#issuecomment-1527375723 because it has wider issues with missing local data in the system address book. So once that is fixed, the private or local role and organization will be mappable. We don't have to make them published/federated.

[ChristophWurst]

Language -> LANG

We noticed that language is not a profile property. It is a simple user setting shown on the profile settings page.

@jancborchardt do we still want to write a user's configured language as their LANG prop of the system address book contact entry? If so, under what scope? Can we assume everyone is okay with others seeing their language?

Semantically it is tricky to interpret the number of the LANG property because it's not necessarily the user's spoken language but what they configure Nextcloud to be in. I've set my Nextcloud to English while I speak also German.