Write profile properties and backend properties to system address book

[miaulalala]

Part of #19575

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

Mapping

• Display name -> FN
• Primary email addresses -> EMAIL (without TYPE)
• Secondary email addresses -> EMAIL (without TYPE) feat(carddav): Map user's additional emails into the SAB card #38073
• Phone number -> TEL (without TYPE)
• Organisation (to be renamed to Company) -> ORG
• Role (to be renamed to Title) -> TITLE
• Location -> ADR
• Language -> LANG
• Optional: Profile page https://cloud.domain.tld/u/<uid> (if enabled) -> URL Write profile URL into system address book contact #38944
• Optional: https://cloud.domain.tld/apps/spreed/?callUser=<uid> -> URL
• Optional: Write Nextcloud groups as CATEGORIES of system address book contacts #38432

[ChristophWurst]

It looks like role and organization are among the props intentionally not published:

server/apps/settings/src/constants/AccountPropertyConstants.js

Lines 148 to 154 in 74f31ba

	/** List of readable account properties which aren't published to the lookup server */
	export const UNPUBLISHED_READABLE_PROPERTIES = Object.freeze([
	ACCOUNT_PROPERTY_READABLE_ENUM.BIOGRAPHY,
	ACCOUNT_PROPERTY_READABLE_ENUM.HEADLINE,
	ACCOUNT_PROPERTY_READABLE_ENUM.ORGANISATION,
	ACCOUNT_PROPERTY_READABLE_ENUM.ROLE,
	])

@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 #19575 (comment). 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 #19575 (comment) 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.