Autocomplete and suggest contact on the related field

[spoorun]

Is your feature request related to a problem? Please describe. When a User tries to add a related contact, they are required to enter a URL. For example: Contact: Mary Jones Related: sibling:https://aaaaaa.aa/aa

The problem is: a) User does not know what to do with this! b) Sometimes the User will just want to enter the name of a person or organisation and not provide a linked contact URL c) Sometimes the User will want to use this field to link a contact to another contact, but there is currently no way to search and enter the UID of another linked contact d) Common apps that allow this field (such as Android) do not require a URL, and accept free text, which makes sync difficult.

Describe the solution you'd like When a user selects 'Related' field, besides choosing a pre-built or custom label (i.e. sibling, friend etc...), the user should be able to a) search for another contact and add it's UID b) enter a URL (as currently) c) enter free text to describe a related contact (including one which is not stored in the addressbook).

Additional context Here is an issue related to that in Thunderbird CardMate client:

https://gitlab.com/CardBook/CardBook/issues/557

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/72551271-autocomplete-and-suggest-contact-on-the-related-field?utm_campaign=plugin&utm_content=tracker%2F46751899&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F46751899&utm_medium=issues&utm_source=github).

[skjnldsv]

Hey @olantrust !

I was almost sure there was already an opened issue about something similar, but I cannot find it :)

Let's simplify a bit the title shall we? :grin:

[spoorun]

Let's simplify a bit the title shall we? grin

Absolutely!

Did you have any comment on the discussion in this bug?

https://gitlab.com/CardBook/CardBook/issues/557

[skjnldsv]

Nothing really related, but why would cardbook require us to fix this? Did I miss a connexion somewhere? But we're both independent vcard manager, right? They could totally add this without us?

Nonetheless, Let's add this into next minor, it should not be difficult. Though would be limited to the same addressbook for the urn:uuid :thinking: I'm not sure it is relevant to allow the link to the vcf file since it might not be accessible by the person who open the vcard? Thoughts?

[carstev]

:+1:

Was confused by the field not showing contacts as an auto-complete.

It is indeed unclear what to do with this field.

I hope auto-completion or suggestions will be available too?

[Aesculapius]

And just freetext would also be requirement I think - if for example I want to store the children of a contact by name, but don't want do create contact cards for them?

[ghost]

And just freetext would also be requirement I think

Yes, because the field RELATED requires per definition an URI (mailto: URL or UID of another vCard object) or a text:

Value type: A single URI. It can also be reset to a single text value. The text value can be used to specify textual information.

if for example I want to store the children of a contact by name, but don't want do create contact cards for them?

Then do it. I handle this similar and accept the red frame.

[j-brewer]

I would also like to see this feature added! However, I do see a significant amount of complexity in doing this "right" (due to client limitations and the number of use cases).

Internal to the NextCloud Website From a data consistency perspective, this is the easy part. When adding a relationship, users should be able to select from the list of existing contacts, enter free text, or enter a valid URI (as required by RFC6350). If a user chooses an existing contact, the relationship should be stored behind the scenes as a urn:uuid reference to the related contact with the UI displaying the actual name of the related contact. It would also be good to create reciprocal relationships automatically (i.e. if Jane Doe is mother to John Doe, then John Doe should automatically be a child of Jane Doe).

When downloading (exporting) an address book, the urn:uuid value should be exported if the related contact is part of the dataset. If the related contact is not included in the downloaded dataset, I would suggest the display name of the related contact be exported instead of the urn:uuid. When importing address books, any urn:uuid relationships in the incoming dataset should be mapped to contact names (just as if the user had added the relationship through the web UI).

Client Applications (Windows/Linux/Android/IOS/etc.) This is where the problems begin. I expect most vCard based address book apps do not implement behavior similar to what's being requested on this thread. This significantly limits the options available for doing this in a way that is both usable and that preserves data consistency.

For example, if the urn:uuid value is synced to clients, most of them are just going to display the value verbatim (which is useless on the client). I can verify that this is how my Android phone behaves. If the related contact's display name is synced instead, then any updates to the relationship entry coming from the DAV client would need to be discarded (to prevent the client from destroying the underlying urn:uuid reference on the server).

Conclusion I'm not sure if implementing the latter behavior (i.e. partially blocking contact updates from clients) is feasible or desirable. As to the former option, while I can see the argument for improving NextCloud's web UI behavior, this feature would largely go unused until/unless client apps implement a similar capability for displaying related contacts.