LDAP fix quota and case, fixes #20043

[blizzz]

This is a forward port of two issues found only when backporting #18469 to stable8.1 (#19427, #19427 (comment)). This also fixes #20043.

It needs to be backported to 8.2. Please confirm @karlitschek

Please test and review @davitol @eidota @MorrisJobke

[karlitschek]

makes sense. please backport 👍

[eidota]

Working as expected - Quota is delivered and even the mass 'displayName' errors in our logfile are gone 👍

[MorrisJobke]

Tested and still works 👍

[MorrisJobke]

@blizzz Can you please prepare the backport? Thanks

[eidota]

Contrary to my last comment my logs still show the displayname error:
{"reqId":"aKzMlvmDUGzMFNVLD3lX","remoteAddr":"","app":"PHP","message":"Undefined index: displayname at \/disk1\/webserver\/owncloud\/apps\/user_ldap\/lib\/access.php#696","level":3,"time":"2015-10-28T12:15:08+01:00"}
Before i edited the code with your changes the log showed the same message but with the index 'displayName'.
Is this error a separate issue?

[blizzz]

@eidota in that case it seems that the attribute was either not read or not available at all for the record. Can you give me reproduction steps?

[eidota]

The error doesn't occur on demand, e.g. when i reload the users page. I get blocks of 66 entries of this error message about once per hour. Seems to happen when checking the ldap data in the background.
The 66 entries match our 66 users in our testing environment. I checked the ldap-records - the attribute displayName is filled for all of them.

Is this attribute used to fill the 'Full Name' field on the users page? Because they are shown correctly there.

[blizzz]

$userRecord[$displayNameAttribute] must be [0]. Thanks to @eidota 's hint, i rechecked that part. I does not cause any trouble, because in dn2ocname this is used just for mapping a group. With that inside, i could cleanup dn2ocname() a bit… So, actually we can just leave the part displayNameAttribute part away, which will save any undefined index warning (which is probably a user record without display name).

[blizzz]

I get blocks of 66 entries of this error message about once per hour. Seems to happen when checking the ldap data in the background.

Yes, it's the background job, calling usersInGroup() which only looks for the DN. This can also happen when viewing selecting groups on the Users page. It makes sense to read the other attributes in this case as well. There are more places in group_ldap where we are fetching users like that. But in countUsersInGroup() and inGroup() it is good keep it simple and don't read and do any more than necessary.

So, Todos for me:

• don't provide the displayname (and asssume it is there) when passing it to dn2ocname
• usersInGroup() should also read additional meta data about users
• I will do ^this^ for master in a new PR and backport both together.
• additonaly i clean up dn2ocname a bit, but only for 9.0 → LDAP: cleanup Access::dn2ocname() #20369

[blizzz]

Please see #20124 which fixes remaining tasks