Ticket #6300 (closed Bug: fixed)
Users seem to be listed twice in the control panel
| Reported by: | limi | Owned by: | laz |
|---|---|---|---|
| Priority: | critical | Milestone: | 3.0b2 |
| Component: | Users/Groups | Keywords: | upstream sprint |
| Cc: |
Description
To reproduce:
- Add a user "testuser" with the full name "Test user"
- Search for "test" in the Users Overview
- Notice how you get two identical users listed in the search results instead of one
Change History
comment:3 Changed 5 years ago by laz
- Keywords sprint added
- Owner changed from wichert to laz
Yes, the users are listed twice when clicking on 'Show all' button in Plone Site Setup / Users and Groups / Users Overview.
Surely due to the same bug that is reported in #5887 ticket comments.
(the search results are given by different plugins, and putted together, but without being merged !)
I'm taking this one (it's the continuing of the work done on #5887 ticket)
Must see with wichert where the merging method should be put :
* should I re-use this method in the other view (see other ticket commit) ?
* or should I put the method lower in the PlonePAS core code ?
comment:4 Changed 5 years ago by wichert
What 'other view' are you referring to? All searches should use the pas_view browser view and that is where the duplicate filtering should happen.
comment:5 follow-up: ↓ 6 Changed 5 years ago by laz
I'm talking about when you search for users in Users Overview in Site Setup / Users and Groups
I'm not sure at all that it uses the Users Overview ... will check later.
comment:6 in reply to: ↑ 5 Changed 5 years ago by laz
I'm not sure at all that it uses the Users Overview ... will check later.
I meant the pas_view browser view of course ...
comment:7 Changed 5 years ago by laz
- Status changed from new to assigned
OK, working on it, discovered a new bug : you may search for a pattern, it doesn't work : the users returned by the search do not match (especially) the pattern.
comment:8 Changed 5 years ago by laz
The use of the pas_view browser view (modified in ) solves the first problem.
But the second one (search pattern) is related to ZODBUserManager and _ZODBUserFilter in particular :
When searching on something else than id or user, this method return 1 so all users are taken !! It is a "# TODO: try using 'kw'" !
This method should return 0 in this case ...
Wiggy, can you tell me what you think about it ?
comment:10 Changed 5 years ago by laz
First bug is fixed.
Second would be fixed by the following diff (Alec asked me to send him an email with that PluggableAuthService patch) :
Index: plugins/ZODBUserManager.py
===================================================================
--- plugins/ZODBUserManager.py (revision 73951)
+++ plugins/ZODBUserManager.py (working copy)
@@ -521,6 +521,7 @@
self._filter_ids = id
self._filter_logins = login
+ self._filter_keywords = kw
def __call__( self, user_info ):
@@ -534,8 +535,11 @@
key = 'login'
to_test = self._filter_logins
+ elif self._filter_keywords:
+ return 0 # TODO: try using 'kw'
+
else:
- return 1 # TODO: try using 'kw'
+ return 1 # the search is done without any criteria
value = user_info.get( key )
Index: plugins/tests/test_ZODBUserManager.py
===================================================================
--- plugins/tests/test_ZODBUserManager.py (revision 73951)
+++ plugins/tests/test_ZODBUserManager.py (working copy)
@@ -243,6 +243,26 @@
self.assertEqual( info_list[ i ][ 'editurl' ]
, 'partial/manage_users?user_id=%s' % sorted[ i ])
+
+ def test_enumerateUsers_other_criteria( self ):
+
+ from Products.PluggableAuthService.tests.test_PluggableAuthService \
+ import FauxRoot
+
+ root = FauxRoot()
+ zum = self._makeOne( id='partial' ).__of__( root )
+
+ ID_LIST = ( 'foo', 'bar', 'baz', 'bam' )
+
+ for id in ID_LIST:
+
+ zum.addUser( id, '%s@example.com' % id, 'password' )
+
+ info_list = zum.enumerateUsers( email='bar@example.com', exact_match=False )
+
+ self.assertEqual( len( info_list ), 0 )
+
+
def test_enumerateUsers_exact_nonesuch( self ):
from Products.PluggableAuthService.tests.test_PluggableAuthService \
comment:11 Changed 5 years ago by laz
comment:12 Changed 5 years ago by laz
comment:13 Changed 5 years ago by laz
Refactoring : released r40104 in the collective also.
comment:14 Changed 5 years ago by wichert
- Status changed from assigned to closed
- Resolution set to fixed

A well known problem and there are already several unittests in CMFPlone that expose this bug.