Autocomplete for the member field

[PVince81]

Use the same API like sharing so we benefit from "restrict sharing to only your groups"

[PVince81]

This is critical especially for LDAP cases where the user id is not user friendly.

[PVince81]

Some challenges:

• "restrict groups to only share with groups they are member of"
• when user autocomplete is disabled, only allow full user name
• filtering out sharing results on the server side (client side is not possible if we use pagination as we don't have all results)
  • this makes it impossible to use the existing sharees API and requires reimplementation in the custom groups code

[PVince81]

and for filtering on the server-side, best would be to be able to JOIN between the user account table and members table in a way that excludes already existing members. But that requires the user account table to exist. Since this would join with the customgroups specific table, this code needs to live in this app.

The other alternative, less nice is to add an argument in core for the search:
UserManager->search(..., array $excludeResults) where $excludeResults is an array of all user ids that already exist and that need to be filtered out.

Or yet another method: implement an autocomplete controller in customgroups (private API, app framework) and have that one first call UserManager->search() and then filter out the existing members from the results. This does not work well with pagination because maybe the first page contains members that were already added, so this would cause an empty result set after filtering. This means that this code would need to go forward page by page until we have enough results to output.

And besides this, post-filtering might not be very efficient. Best would be DB-level join because we can also paginate on that...

[PVince81]

Summarizing what I posted in the chat:

I want to build the customgrous autocomplete which looks like the share panel autocomplete when sharing, this to select members to add to a group
now I need to filter out the members that are already in the group from the autocomplete box
the way how the sharing dialog did was filter out the results on the JS side based on what's on the list already
this sucks because it's not compatible with pagination (we never have the full list on JS side)
possible approaches:

1. ignore the pagination issue (if we implement it later) and filter on the JS side: makes it possible to reuse the "sharees" endpoint like the share dialog. I have a prototype of this that works.
2. create a new endpoint in customgroups for the autocomplete results and have the "filter users already in the list" on the PHP side. For that there are at least two approaches:
   a) UserManager->search(...) with pattern and then post-filter with a select on the custom group members table: sucks because it's a PHP level join-like construct
   b) extend UserManager->search(...) to accept a list of exclusions. But also needs a select on the custom group members table to pass it there. Same suckage as a)
   c) wait for user account table and do a single select that joins the custom group members table with the user account table for the exclusion. this is the nicest because it can paginate properly on a single result set, but requires user account table to be ready and also needs JOIN on core tables which we said is not public API
   also what sucks for a) and b) is that we can't easily paginate the search, we need to pump as many pages as possible from UserManager->search(...) until we got enough results. This feels hacky

[PVince81]

I think I'll go with either 2a) or 2c). Both require an endpoint for autocomplete, so I'll start adding that now.

[PVince81]

So I decided to go for 2a. While this might not be the most performant, I noticed that we could pass the search pattern to both the user manager and also the database handler for custom groups.

So when searching for "us" it will also search existing members starting with "us" which will reduce the exclusion algo time a bit compared to if we'd retrieve all members.

[PVince81]

PR here #43