Allow searching for users by displayname in the database group backend

[juliushaertl]

When searching for users in a group by displayname only the uid was matched before:

server/lib/private/Group/Group.php

Line 309 in 653628c

$userIds = $backend->usersInGroup($this->gid, $search, $limit, $offset);

With this PR usersInGroup will also check for matching displaynames when called with a $search parameter

[blizzz]

tests :)

[juliushaertl]

Hmm needs more adjustments since this change will no longer find users in other backends then

[MorrisJobke]

I also stumbled over this.

In the database we search over userID, displayname and email:

server/lib/private/User/Database.php

Lines 266 to 278 in 145eee9

	$query->select('uid', 'displayname')
	->from($this->table, 'u')
	->leftJoin('u', 'preferences', 'p', $query->expr()->andX(
	$query->expr()->eq('userid', 'uid'),
	$query->expr()->eq('appid', $query->expr()->literal('settings')),
	$query->expr()->eq('configkey', $query->expr()->literal('email')))
	)
	// sqlite doesn't like re-using a single named parameter here
	->where($query->expr()->iLike('uid', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))
	->orWhere($query->expr()->iLike('displayname', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))
	->orWhere($query->expr()->iLike('configvalue', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))
	->orderBy($query->func()->lower('displayname'), 'ASC')
	->orderBy('uid_lower', 'ASC')

I'm coming here, because searching in groups (in the user management) only searches user IDs, while searching the "all" tab it checks for user ID, display name and email:

server/apps/provisioning_api/lib/Controller/GroupsController.php

Line 210 in cb05782

$users = $group->searchUsers($search, $limit, $offset);

One can also see that the searchUsers searches for user ID, but there is also searchDisplayName (the method that was changed in here), searches also only for the user ID, because it uses the same backend method. The idea here would be then to provide a new group backend interface that adds then the "search display name as well" feature. The big question then still is: do we then search only display name or userID/displayname/email like in the other methods?

I just checked the userbackend which has a getUsers():

server/lib/public/UserInterface.php

Line 74 in caff102

public function getUsers($search = '', $limit = null, $offset = null);

There multiple backends implement it in different ways:

• guests searches display name, user ID and email: https://github.com/nextcloud/guests/blob/f12938122e0590ce2bd6f9c75d727dd3b1825598/lib/UserBackend.php#L222-L224
• LDAP searches display name and user ID:

  server/apps/user_ldap/lib/User_LDAP.php

  Lines 264 to 265 in cb05782

  	$this->access->connection->ldapUserFilter,
  	$this->access->connection->ldapUserDisplayName . '=*',

• database searches display name, user ID and email:

  server/lib/private/User/Database.php

  Lines 276 to 278 in 734c62b

  	->where($query->expr()->iLike('uid', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))
  	->orWhere($query->expr()->iLike('displayname', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))
  	->orWhere($query->expr()->iLike('configvalue', $query->createPositionalParameter('%' . $this->dbConn->escapeLikeParameter($search) . '%')))

• global site selector backend searches on user ID: https://github.com/nextcloud/globalsiteselector/blob/1c72d573703406a3025c2d3b9727f8ac9d774b22/lib/UserBackend.php#L169

... what a mess, because our public interface only says "search" and doesn't specify anything.

What now?

[blizzz]

LDAP searches display name and user ID:

negative, the first filters for valid users, the second ensures the displayname attribute is present, the third pulls in the search attributes, which are configurable.

[blizzz]

... what a mess, because our public interface only says "search" and doesn't specify anything.

It depends in the user case. For end user search, this fuzzyness is ok and good, as long as the desired results are shown. There are use cases where API-wise you like to search for something specific, e.g. when user_saml gets an id and wants to ensure the corresponding LDAP user is imported. At the moment this is also treated with search.

[MorrisJobke]

I tried porting the function from the User/Database.php in #21138

[MorrisJobke]

Let's close this here in favor of #21138