Possibility to restrict the autocompletion search to full username/email match only

[pitilux]

Hello,

When searching for a user to add to the workspace, the autocompletion allows to retrieve the full list of created accounts. Could it be possible to restrict the result to match exactly the full entered text (username/email)?

This would be useful on a public instance where groups of users manage different workspaces without leaking private information on other users.

What I’d like to achieve is something similar to the behavior of the file sharing privacy setting where it is possible to force the full username or email to be entered before it returns a result (option Allow autocompletion when entering the full name or email address in the file sharing configuration).

Regards

[pitilux]

I had a look on this, and came up with the following proof of concept that could work in our case.

diff --git a/lib/Service/WorkspaceService.php b/lib/Service/WorkspaceService.php
index 56a29fb..b1dc094 100644
--- a/lib/Service/WorkspaceService.php
+++ b/lib/Service/WorkspaceService.php
@@ -91,7 +91,10 @@ class WorkspaceService {
                $REGEX_FULL_MAIL = '/^[a-zA-Z0-9_.+-].+@[a-zA-Z0-9_.+-]/';
 
                if (preg_match($REGEX_FULL_MAIL, $term) === 1) {
-                       $users = $this->searchUsersByMailing($term);
+                       // On our instance, we use email addresses as username
+                       // and we don't fill the user's email field
+                       //$users = $this->searchUsersByMailing($term);
+                       $users = $this->searchUsersByDisplayName($term);
                } else {
                        $users = $this->searchUsersByDisplayName($term);
                }
@@ -134,6 +137,11 @@ class WorkspaceService {
                        }
                }
 
+               if (method_exists($this->shareManager, 'allowEnumerationFullMatch')
+                           && $this->shareManager->allowEnumerationFullMatch()) {
+                       $users = $this->shareMembersFilter->filterUsersFullmatchOnly($users);
+               }
+
                // transform in a format suitable for the app
                $data = [];
                foreach ($users as $user) {
diff --git a/lib/Share/Group/ShareMembersOnlyFilter.php b/lib/Share/Group/ShareMembersOnlyFilter.php
index fa5e4a5..d02631f 100644
--- a/lib/Share/Group/ShareMembersOnlyFilter.php
+++ b/lib/Share/Group/ShareMembersOnlyFilter.php
@@ -67,4 +67,14 @@ class ShareMembersOnlyFilter {
 
                return $usersInTheSameGroup;
        }
+
+       public function filterUsersFullmatchOnly(array $users, string $term): array {
+               $usersFullmatch = array_values(array_filter(
+                       $users,
+                       function ($user) use ($term) {
+                               return $user->getUID() === $term;
+                       })
+               );
+               return $usersFullmatch;
+       }
 }

[ThibautPlg]

Hi,
Thanks you for your input.

Most of our use cases are business related, and usually the General/Wsp Manager is a staff member, as such it must be able to see and list the entire user base.

Using the allowEnumerationFullMatch as you did isn't an option either, as this should not impact administrative actions like managing Workspaces members. However, having a dedicated toggle somewhere could be the way.

We however understand your use case and need for such an option. I'll get in touch with our product manager regarding this issue.

Best regards,

[pitilux]

Hello thanks for the reply and sharing your position on this.

From the documentation (section 3.1.1 - p7) two possibilities are currently covered:

1. the GeneralManager can see all the accounts on the Nextcloud instance
2. the GeneralManager can only see accounts with whom a group is shared ("when the option is checked at the Nextcloud level by a Nextcloud admin")

Important : en fonction des configurations de votre instance Nextcloud, le Gestionnaire Général verra tous les utilisateurs existants sur l’instance Nextcloud (par défaut) OU uniquement les utilisateurs présents dans les groupes dont fait partie le Gestionnaire Général (lorsque l’option est cochée par un administrateur de l’instance Nextcloud).

The idea here would be to add a third possibility:

3. the GeneralManager does not see any account unless providing the full account name or email

From what I understand from your answer, relying on the toggle allowEnumerationFullMatch at the Nextcloud instance level (similarly to 2. that rely on shareWithGroupMembersOnlyExcludeGroupsList) is not an option because (correct me if I'm wrong):

• in a business context, it might be ok to limit the sharing to full match only
• and in this same context, GeneralManagers should be able to list all accounts on the instance to add a member to a workspace

In that case, it makes sense that relying on this Nextcloud option is not enough. Hence your suggestion for a dedicated toggle somewhere.

I (and some people around me) would be happy to contribute on this feature.

[smarinier]

allowEnumerationFullMatch is a strange option. If it's a security option, the target is not fullfilled as it is not secure at all. For me it's just an annoying non-choice. Imagine admin that need to add a swedish or romanian user. Or a Kristel ? Christel ? Krystel ?

You can't neither implement a "method_exists($this->shareManager, 'allowEnumerationFullMatch" on an interface class, nor replace the email by the displayname.

It seems that you invented a new role for the GM that we didn't match yet. So could you move a step behind, and describe what is your use case (without providing a solution ;) ).

[pitilux]

We are a group of volunteers hosting a public Nextcloud instance with >500 active accounts.

Some of the people behind the accounts would like to work together and share documents. Currently, they share a folder or the document between each others. We would like to improve their workflow with the usage of group folders.
However using group folder means that admins (we) create and keep up to date the groups. We don't want and don't have the energy to keep track of all the groups.
Hence our interest for your workspace application. From our understanding and tests, with the workspace application we can delegate to one or two people the capability to create and manage their own working group. We just need to create a workspace and promote some account as WorkspaceManager. Then it's up to the WM to add other accounts into their workspace (we are no longer involved in the process).

Currently, when a WorkspaceManager searches for accounts to add to its workspace, she either sees:

1. all the accounts on the instance
2. only the accounts in her group

We definitely want to avoid 1. for privacy issue (this is a public instance). We could rely on 2. but this means we should define the groups beforehand, which moves us back to the solution based on group folders only. And as explained we can't deal with the groups' management.

To fulfill our need, it would be great to have a third way to add accounts to a workspace where a WM could add an account without having access to the whole accounts list nor already being part of a group.

I hope this clarifies our use case and need (and as said, we are ready to provide help on this topic).