Store all known users from all user managers in a single table

[PVince81]

Current issue in a LDAP scenario (also applies to other user managers):

1. Only local users are stored in oc_users
2. LDAP users are stored separately in mapping tables, the tables are LDAP specific
3. No easy way to work with all users on SQL-level (repair steps, etc)
4. On PHP level, additional round trips required to all user managers when doing user searches, for example for share autocomplete

Proposed solution:

Either reuse oc_users or provide new tables to store all users (and maybe groups too) that are known to this ownCloud instance. The table itself will have a "externalUserId" and "externalUserType" to be able to link it to other user-manager specific tables (ex: LDAP).

Ref: #19600 (comment)

@DeepDiver1975 @karlitschek @blizzz @icewind1991 @schiesbn @rullzer

[PVince81]

This is also important to be able to properly map users to their storages. Currently LDAP users have no entries in oc_users, so if you start with a storage in the DB and want to go back to the user data you're out of luck.

[DeepDiver1975]

related #18227

[blizzz]

oc_users are and should be kept for local users. There are other information we like to store as well in a unified way and still user backends will continue to take care of their affairs (managing users) in their systems. So it's best to imagine oc_users is an external resource as well.

#19600 mixes up user names and login names. The problem is programtic: developers used to expect that the login name matches the user name which is even not always true for internal users as you can login with JABBAtheHUTT but your username still is 'jabbathehutt'.

In that table we can store all the user related information, like displayname, email, maybe user directory path, and keep the user backends in charge to keep the information up to date. It will be difficult for search, because user backends (like LDAP) offer more advanced search functions that are run on backend side. For just internally done searches (in user or display names) the table will suffice.

[MTRichards]

The bigger sledgehammer needs a milestone so it gets considered. Setting to 9.1.

[schiessle]

With the new auto-complete for federated sharing across ownClouds we create a carddav address book with all system users. We can use this address book in the future for other stuff as well.

[blizzz]

Thoughts from LDAP PoV

What are the use cases/goals?

To start with. Taken from above:

1. Be able to work with all users on SQL-level (repair steps, etc)
2. On PHP level, additional round trips required to all user managers when doing user searches, for example for share autocomplete

Further possibilities

• assist user backends in providing a unique ownCloud username that follows constraints (e.g. allowed characters). LDAP does it by itself, which leads to code duplication and complexity.

Integration in current procedures

• User backends may keep their private, specialized tables (e.g. to map the ownCloud name to one or more backend-native features like DN and UUID).
• rows must only be removed on a successful user deletion operation, triggered by core (in other words, user backends must not delete from the table).
• user exists calls must to be done against the user backend, after a successful lookup in this table. Possible "isDeleted" (see below) field should not be taken into account (possible Undos or Backups on server side).

Population: full and active vs. on demand

• How shall the table be populated?
• Some user backends do not have a user listing thus are not be able to provide user information without knowing a user by login.
• An automatic sync requires cron. Triggered by Ajax over huge user backends does not sound right.
• An incomplete (i.e. not up to date) table can be only used for maintenance and background tasks
• A combination of both (backends with listings populated and keep up to date automatically, backends without populate+update on logins and changes)

Search

• LDAP allows to search in several, configurable attributes (e.g. email adresses, different combinations of first and last name, license plate number, …). Despite having a central table it must be possible to provide a server-side search.
• This contradicts goal 2.
• Plain lookups without a search string may operate on this table.

Table Fields

Not necessarily complete, suggestions.

Field suggestions

• id - :)
• ownCloudName - ownCloud user name
• nativeUid - the backends native username. Now with LDAP this can be complicated, however with hindsight to add LDAP specific API call to resolve an LDAP (login) name to an ownC… #19600 this would always be the values of the configured username attribute
• displayName
• email - currently saved in preferences, app "settings"
• homeDirectory - name/path of the user home directory (LDAP allows to override whole path). Basically the return value of the backend's getHome().
• backendName

Additional candidates ("nice to have")

• lastLogin - currently saved in preferences, app "login"
• firstLoginAccomplished - a mark that is set when the first login is done. (Currently saved LDAP specific in oc_preferences. FirstRunWizard does something else.)
• isDeleted - a flag that can be set by the userbackend, if a user is not accessible on the backend anymore. Currently, LDAP uses this in oc_preferences.
• quota?

Further considerations

• I do not see how this table helps with add method to user-backend to check if allowed to update email address #19053, except that stuff is written by default. This requires abstract classes, which are not practical and do not work with LDAP backend.
• It does not help much with Cache groups (and users?) as exisiting when fetched from server #9271 either

[PVince81]

A rough design has been proposed here: #23558

[blizzz]

@PVince81 should we close this one in favor of #23558?

[DeepDiver1975]

@PVince81 should we close this one in favor of #23558?

yes

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.