You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As an admin, I want to be able to sort alphabetically and then get to the letter I want (such as C), which then shows me the users that begin with C. I need to manage hundreds of users within the ownCloud authentication system, or to manage attributes for a few users in a 20,000 user installation that uses an external authorization server, and lazy loading is not working.
A heads up on the "going to C": What we would need to do is to filter with C,
but without the wild card in front of it (opposite to the current mechanism.
We cannot load everything until we reach C. Why? Think about 500.000 LDAP
users.
We would not be able to use established methods, but create new one's for the
user backends. First, because as stated before we automatically insert
wildcards. But then also: in LDAP you can search in several attributes, but in
this case we must only search the display name attribute. This is not a
problem, but to have it in mind when implementing.
The problem however is to do this on the user name. Not for local users, but
for LDAP, because they are only created "on-the-fly" (they are persistent and
ownCloud-specific, not necessarily identical to values in LDAP because we
avoid collisions by creating other names. Also, the rules for the user name
creation can be changed by the admin but apply only to newly fetched users).
When the default UUID attribute is used therefore, sorting does not make much
sense anyway. Maybe just searching for that attribute is a good enough
solution. Needs more investigations.
The text was updated successfully, but these errors were encountered:
As an admin, I want to be able to sort alphabetically and then get to the letter I want (such as C), which then shows me the users that begin with C. I need to manage hundreds of users within the ownCloud authentication system, or to manage attributes for a few users in a 20,000 user installation that uses an external authorization server, and lazy loading is not working.
Acceptance Criteria:
See #11852
Remarks by Engineering:
A heads up on the "going to C": What we would need to do is to filter with C,
but without the wild card in front of it (opposite to the current mechanism.
We cannot load everything until we reach C. Why? Think about 500.000 LDAP
users.
We would not be able to use established methods, but create new one's for the
user backends. First, because as stated before we automatically insert
wildcards. But then also: in LDAP you can search in several attributes, but in
this case we must only search the display name attribute. This is not a
problem, but to have it in mind when implementing.
The problem however is to do this on the user name. Not for local users, but
for LDAP, because they are only created "on-the-fly" (they are persistent and
ownCloud-specific, not necessarily identical to values in LDAP because we
avoid collisions by creating other names. Also, the rules for the user name
creation can be changed by the admin but apply only to newly fetched users).
When the default UUID attribute is used therefore, sorting does not make much
sense anyway. Maybe just searching for that attribute is a good enough
solution. Needs more investigations.
The text was updated successfully, but these errors were encountered: