[Bug]: Recently contacted stores the same local user twice when contacted via share (UID) and calendar (email) #61347

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

If you have a user named "User2 user2@example.net" on your Nextcloud instance, and you share a file with User2 and invite them to an event, they will appear twice in the "Recently contacted" address book. From Share I get "UID and Name without email" and from Calendar I get "email without name"

Steps to reproduce

1. Create a NC user with name and email. Example "User2" with "user2@example.net"
2. Enable: Admin -> Groupware -> "Enable System Address Book" (you need this for Step 4)
3. Share a file with "User2"
4. Create and save an event with "User2" as an attendee
5. Check your "Recently contacted" List

Expected behavior

Since I interacted with the same instance user in both cases, I expect to see User2 only once in "Recently Contacted" with UID/Name/Email - not twice, each holding only part of the information

this requires:

• When sharing files, save not only the UID and name but also the email address (if available)
• When inviting users to appointments, don't just save the email address - also lookup and save the UID and name (if there is only one user with that email address)

Nextcloud Server version

35 (master)

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Enabled:
    - appstore: 2.0.0-dev.0
    - calendar: 6.5.0-dev.0
    - circles: 35.0.0-dev.0
    - cloud_federation_api: 2.0.0-dev.0
    - comments: 2.0.0-dev.0
    - contacts: 8.8.0-dev.0
    - contactsinteraction: 2.0.0-dev.0
    - dashboard: 8.0.0-dev.0
    - dav: 2.0.0-dev.0
    - federatedfilesharing: 2.0.0-dev.0
    - federation: 2.0.0-dev.0
    - files: 3.0.0-dev.0
    - files_reminders: 2.0.0-dev.0
    - files_sharing: 2.0.0-dev.0
    - files_trashbin: 2.0.0-dev.0
    - files_versions: 2.0.0-dev.0
    - lookup_server_connector: 2.0.0-dev.0
    - oauth2: 2.0.0-dev.0
    - profile: 2.0.0-dev.0
    - provisioning_api: 2.0.0-dev.0
    - settings: 2.0.0-dev.0
    - sharebymail: 2.0.0-dev.0
    - systemtags: 2.0.0-dev.0
    - theming: 3.0.0-dev.0
    - twofactor_backupcodes: 2.0.0-dev.0
    - updatenotification: 2.0.0-dev.0
    - user_status: 2.0.0-dev.0  
    - weather_status: 2.0.0-dev.0
    - webhook_listeners: 2.0.0-dev.0
    - workflowengine: 3.0.0-dev.0

Nextcloud Signing status

Nextcloud Logs

Additional info

I'm aware that this cannot be solved completely. There are users without an email address. Or multiple users sharing the same email address. But for a cleanly maintained NC instance with unique users, I still see value in it. The question is how much effort/risk is justified. As background info: entries are removed automatically after 7 days without renewed contact.

Questions for the maintainers:

1. Just enriching the entry with the email address on the sharing path would probably already give us the improvement when, after sharing, the same user is invited to an event via email. Are you OK with this approach?

2. For an event attendee, only the email address is known at save time. So we could try getByEmail(email), and if that returns exactly one result, then try findMatch with the uid or email. If a match exists, update the timestamp; if not, generate the contact with UID/Name/CloudID/email. Are you OK with this approach?

Note: #31606 was addressed by #41046, but only deduplicates against the user's personal address books. The cases here - same-instance users (system address book) and the UID-vs-email split - aren't covered.