User match behavior when sharing on client apps

[phil-davis]

Core issue owncloud/core#30313 "Configurable minimum characters before autocomplete user searches" implemented a default minimum of 4 chars to be typed before the autocomplete will respond and display matching users or groups.

For short user or group names, this creates a problem - e.g. 3-character user names (tom) or short group names gg - this was fixed for the webUI by issue owncloud/core#31058 and core PRs owncloud/core#31067 (stable10) and owncloud/core#31070 (master) - so if you type tom and there is a user or group called tom then the exact match will come up.

For the existing client apps, no matches come up unless 4 (default) or more characters are typed.

To share with tom you have to type tom<space>, then the match is shown and you can select it.

To share with a 2-char group gg you have to type gg<space><space> to see the match.

This will happen on client apps after a server is upgraded to 10.0.8

This behavior needs to be documented somewhere. In 10.0.8 release notes, then also somewhere more fixed?

[phil-davis]

I have confirmed the behavior on ownCloud Android 2.7.0

I will check on iOS and report here.

[phil-davis]

On android they set android:searchSuggestThreshold="4" back in Sep 2017 for 2.5.0 and later android releases. So this was already the behavior in the android client.
owncloud/android@0abefc9

If user.search_min_length is set to less than 4 on the server, then the android app makes you type 4 chars anyway before it even tries. If user.search_min_length is set to greater than 4 on the server, then the android app behaves itself, and search results only appear after typing the greater number of characters.

[phil-davis]

On iOS it behaves as expected. Typing less than 4 characters results in finding an exact match, if there is one. After typing 4 characters, multiple matches are displayed. This is the same as the new behavior on the webUI. So just general documentation about the new min search behavior is needed.

[settermjd]

Thanks for documenting this in such detail. I'll get it sorted out.

[phil-davis]

No problem - I needed to get my head around it all while testing the new core 10.0.8 behavior and it took me time to realize that Android had a setting that also interacted with this.

[settermjd]

Ok, I've read through the Issues and PRs and have a fair gist of what's going on. I've also gotten a 10.0.8 installation working and have been able to play around with the configuration option. Now, I just need to find the aptest places to document the feature. I should have it sorted early next week.

[settermjd]

@phil-davis, I've been testing the functionality on version 3.7.3 of the iOS app. Adding the spaces doesn't work for me. I've yet to try it on the Android app.

[phil-davis]

@settermjd Android needs the spaces, e.g. to find "tom" type "tom" - that is because the Android app itself has a hard-coded minimum of 4 chars, so it does not even send a request off until 4 chars are typed.

iOS should find "tom" OK without typing space.

[settermjd]

I've been unable to test on Android, as my Android phone's not playing nice atm. I think I need to add more test data to my setup so that I can test it more thoroughly on iOS.