| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This reverts commit 6a1a4880f0d556fb090f19a5019fec31916f5c36.
|
|\
| |
| | |
Update group.php
|
| |
| |
| | |
Here is fox for my LDAP users OW 7.0.2
|
| | |
|
|/
|
|
| |
First step of a somewhat testable user management. - I know, the JSON returns are in an ugly format but the JS expects it that way. So let's keep it that way until we have time to fix the JS in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add a function getUserGroupIds for retrieving group ids instead of group objects. this significantly improves performance when using many (nested) groups.
Changes a function call in getUserGroups to only retrieve group ids instead of objects.
this change significantly improves performance when using owncloud with many groups, e.g. nested ldap hierarchy (1.2.840.113556.1.4.1941), since getUserGroups gets called in oc_share::getItems, which is needed for every page request.
in my particular case, it took more than 10s to load the calendar page and more than 6s to load the file page.
this was in an environment with 100 user groups (nested) per user. The performance was bad due to the following call stack:
self::getManager()->getUserGroups($user)
- getGroupObject() (executed for every group!)
- groupExists() (resulting in many ldap-requests)
since the groups are loaded from ldap, it is unnecessary to check whether the group exists or not.
|
|
|
|
|
| |
This reverts commit 482eded8b31b257dfed7761c7cb43f35ddcd3408, reversing
changes made to 354cace14ae01e7ff34af3c8a4a3335b89596da3.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Changes a function call in getUserGroups to only retrieve group ids instead of objects.
this change significantly improves performance when using owncloud with many groups, e.g. nested ldap hierarchy (1.2.840.113556.1.4.1941), since getUserGroups gets called in oc_share::getItems, which is needed for every page request.
in my particular case, it took more than 10s to load the calendar page and more than 6s to load the file page.
this was in an environment with 100 user groups (nested) per user. The performance was bad due to the following call stack:
self::getManager()->getUserGroups($user)
- getGroupObject() (executed for every group!)
- groupExists() (resulting in many ldap-requests)
since the groups are loaded from ldap, it is unnecessary to check whether the group exists or not.
|
|
|
|
| |
* test case added to avoid adding them later
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
backends. This is a port to master from PR #7745
remove OC_GROUP_BACKEND_GET_DISPLAYNAME option for group backends
Conflicts:
lib/private/group/backend.php
LDAP: getDisplayNamesInGroup is not an option for group backends anymore
Conflicts:
apps/user_ldap/group_ldap.php
apps/user_ldap/group_proxy.php
clean up group backends
Conflicts:
lib/private/group/database.php
remove now unnecessary test
implement getDisplayNames in group manager
adjust user manager tests
test for group manager's displayNamesInGroup
trim must not be used in empty in PHP < 5.5
keep the constant to not provoke PHP warnings
Conflicts:
lib/private/group/backend.php
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was automatically generated as part of the following inspection:
https://scrutinizer-ci.com/g/owncloud/core/inspections/cdfecc4e-a37e-4233-8025-f0d7252a8720
Enabled analysis tools:
- PHP Analyzer
- JSHint
- PHP Copy/Paste Detector
- PHP PDepend
|
|
|
|
| |
fixes #5209
|
| |
|
|
Conflicts:
lib/private/vcategories.php
|