Group search in sharing uses internal GID instead of displayName; renamed groups or LDAP groups not searchable by visible name

[akang1798]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Feature request

Which Nextcloud Version are you currently using: (see administration page)

Nextcloud 30.0.10 with LDAP user and group backend 1.21.0

Is your feature request related to a problem? Please describe.
Yes. When using the sharing dialog in Nextcloud to share files or folders with groups, the search only matches the internal gid (for local groups) or owncloud_name (for LDAP groups).

This causes multiple problems:

• Renamed local groups:

For example, we created a local group with gid = test and later changed its displayName to infoDep. In the admin Users UI, the group is shown everywhere as infoDep. However, in the sharing dialog, searching for infoDep fails — we still have to search for test.

• LDAP groups with UUIDs:
  For LDAP/AD integrated groups, the internal owncloud_name is typically a UUID like fdf8a7f6-0e3b-103c-8c7c-cd447775f62c. It’s impossible for users to know or type this. They rely entirely on displayName, but the current sharing dialog search does not use it.

This breaks the intuitive experience of sharing files with groups by their actual names.

Describe the solution you'd like
The sharing dialog’s search should:

• Allow searching by displayName (the current human-friendly name shown in the Users / Groups UI).

• Ideally, display both the displayName and the internal ID (like gid or owncloud_name) in the dropdown, such as infoDep (test) or Marketing (fdf8a7f6-...).

This way, admins and users can find and select groups using the names they actually see.

Describe alternatives you've considered

• Telling users to remember old gid values after renaming, which is unrealistic and error-prone.
• Forcing LDAP owncloud_name to be set to readable names instead of UUIDs, which breaks mappings and is not feasible in enterprise LDAP setups.
• Developing a custom plugin to override search, which would add unnecessary maintenance overhead.

Additional context
This affects both local groups (especially after renaming) and LDAP/AD synchronized groups (where internal IDs are UUIDs).

For LDAP environments, once the share dialog supports searching by displayName, it completely eliminates concerns about owncloud_name being human-readable, improving usability dramatically.

Here is a quick summary table to illustrate the current problem:

Type	Internal ID (gid / owncloud_name)	Visible name (displayName)	Shown in Users UI?	Used in share search?
Local Group	test	infoDep (renamed)	✅ infoDep	❌ must type test
LDAP Group	fdf8a7f6-0e3b-103c-8c7c-cd447775f62c	Marketing	✅ Marketing	❌ must type UUID

Suggested improved logic:

// Current behavior in share dialog
for group in groups:
    if search_input matches group.gid or group.owncloud_name:
        show(group)

// Proposed behavior
for group in groups:
    if search_input matches group.displayName 
        or group.gid 
        or group.owncloud_name:
        show(group.displayName + " (" + group.gid_or_uuid + ")")

This would allow:

• Local groups to be found by their current visible name (displayName), even after renaming.
• LDAP groups to be easily found by their displayName, without requiring knowledge of the UUID.

Thank you for maintaining and improving Nextcloud! We believe this would be a significant UX improvement for many organizations.