Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

do not trigger counting on LDAP #10610

Merged
merged 1 commit into from
Aug 10, 2018
Merged

do not trigger counting on LDAP #10610

merged 1 commit into from
Aug 10, 2018

Conversation

blizzz
Copy link
Member

@blizzz blizzz commented Aug 9, 2018

  1. have LDAP enabled
  2. go to user management

Expected:

  • no user count for "Everyone"

Actual:

  • waiting, then a high number 😱

this fixes it.

(Yes, it also mixed OCA space into OC, it was already the case though 🙊 🙈 )

@ChristophWurst
Copy link
Member

(Yes, it also mixed OCA space into OC, it was already the case though speak_no_evil see_no_evil )

Noted ✍️.

@blizzz blizzz requested a review from juliusknorr August 9, 2018 21:41
@juliusknorr
Copy link
Member

I think we should also just hide the counter in the frontend then, otherwise it could be confusing that the number differs from the number of listed users.

Do we also have that slow counting issue with other user backends? Then we should aim for a more general approach like disable counting for all external user backends for example.

@blizzz
Copy link
Member Author

blizzz commented Aug 10, 2018

@juliushaertl which number to do you refer to? in the sidebar, none will be shown.

@juliusknorr
Copy link
Member

@juliushaertl which number to do you refer to? in the sidebar, none will be shown.

Yes, at least on my test instance it shows the number of local users is shown (for the everyone group). But that is a small design issue we can fix afterwards.

Do we also have that slow counting issue with other user backends? Then we should aim for a more general approach like disable counting for all external user backends for example.

At least user_saml app doesn't implement the countUsers action on the UserBackend so it will not be triggered there. I'm fine with this for now. We can still find a more generic way if we encounter further issues with other backends.

@@ -43,6 +43,7 @@
use OC\AppFramework\Http;
use OC\ForbiddenException;
use OC\Security\IdentityProof\Manager;
use OCA\User_LDAP\User_Proxy;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this, it also seems to work with the user_ldap app enabled. Is it always available though autoloading or are there cases when this might fail?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I tested it, it worked for me with both user_ldap enabled and disabled. In the logic, the class is only referred to when user_ldap was found enabled.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok fine by me then, worked here as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juliushaertl mind updating your review?

@blizzz
Copy link
Member Author

blizzz commented Aug 10, 2018

@juliushaertl which number to do you refer to? in the sidebar, none will be shown.

Yes, at least on my test instance it shows the number of local users is shown (for the everyone group). But that is a small design issue we can fix afterwards.

This should not be the case. The counting goes per general user manager, and it should not happen at all.

Do we also have that slow counting issue with other user backends? Then we should aim for a more general approach like disable counting for all external user backends for example.

At least user_saml app doesn't implement the countUsers action on the UserBackend so it will not be triggered there. I'm fine with this for now. We can still find a more generic way if we encounter further issues with other backends.

We should aim for a proper way, yes, it's just it is a bit late for 14 to introduce new Interfaces, e.g.

@rullzer
Copy link
Member

rullzer commented Aug 10, 2018

$isLDAPUsed = (bool)array_reduce($this->userManager->getBackends(), function ($ldapFound, $backend) {
return $ldapFound || $backend instanceof User_Proxy;
});
$this->userManager->getBackends();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this doing here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chilling around. thanks for the catch.

it's probably too many, degregading performance

Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
@blizzz blizzz force-pushed the fix/noid/dontcountwithldap branch from d83b05d to 1b74bfc Compare August 10, 2018 13:40
Copy link
Member

@rullzer rullzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code makes sense. 🐘

@rullzer rullzer merged commit 2afd373 into master Aug 10, 2018
@rullzer rullzer deleted the fix/noid/dontcountwithldap branch August 10, 2018 18:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants