Help Desk Ticket Reference: https://na7.salesforce.com/500A000000908DG project_key: JBEPP The last user listed in the organization portlet (user management) appears multiple times. If I delete the last user list, the one before him/her appears duplicated. If I search for "*" in the search field, there is no duplicate any more.
Hi! It looks like a cache invalidation problem in org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl In order to fix it temporarily I made the following fix in org.exoplatform.services.organization.idm.UserDAOImpl: best regards, Marc Index: component/identity/src/main/java/org/exoplatform/services/organization/idm/UserDAOImpl.java =================================================================== --- component/identity/src/main/java/org/exoplatform/services/organization/idm/UserDAOImpl.java (revision 8257) +++ component/identity/src/main/java/org/exoplatform/services/organization/idm/UserDAOImpl.java (working copy) @@ -468,6 +468,14 @@ ); } + if (q.getUserName() == null && + q.getEmail() == null && + q.getFirstName() == null && + q.getLastName() == null) + { + q.setUserName("*"); + } + // if only condition is email which is unique then delegate to other method as it will be more efficient if (q.getUserName() == null && q.getEmail() != null && @@ -548,19 +556,7 @@ qb.attributeValuesFilter(UserDAOImpl.USER_LAST_NAME, new String[]{q.getLastName()}); } - - - if (q.getUserName() == null && - q.getEmail() == null && - q.getFirstName() == null && - q.getLastName() == null) - { - list = new IDMUserListAccess(qb, 20, true); - } - else - { - list = new IDMUserListAccess(qb, 20, false); - } + list = new IDMUserListAccess(qb, 20, false); if (cache != null) {
Labels: Removed: EPP_5_2_1_Candidate
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: CAUSE: Portal is not able to perform efficient paginated user query in certain configurations. One such example is when some users are duplicated in both LDAP and DB while both stores also contain different users. In such scenario it is impossible to perform efficient paginated query count and Organization API can return non consistent data. Portal then displays last entry in returned list several times. This is still considered less harmful then returning user list with null data. FIX: Configuration switch was provided in idm-configuration.xml to alter this behavior and perform accurate user query instead that will return consistent paginated results. There is "countPaginatedUsers" switch that should be set to "false" to not have duplicated entries in the list.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1 @@ -CAUSE: Portal is not able to perform efficient paginated user query in certain configurations. One such example is when some users are duplicated in both LDAP and DB while both stores also contain different users. In such scenario it is impossible to perform efficient paginated query count and Organization API can return non consistent data. Portal then displays last entry in returned list several times. This is still considered less harmful then returning user list with null data. +A bug in the Organization API caused inefficient paginated user queries. This was identified when user duplication occurred across LDAP and within the database, and there was different user data contained in these databases. The portal displayed the last entry in the returned query several times, which was considered less severe than returning a user list with null data. The fix introduces a configuration switch "countPaginatedUsers", which is configurable in the idm-configuration.xml file. The switch should be set to false to prevent duplicated entries in query results.- -FIX: Configuration switch was provided in idm-configuration.xml to alter this behavior and perform accurate user query instead that will return consistent paginated results. There is "countPaginatedUsers" switch that should be set to "false" to not have duplicated entries in the list.
Thanks Jared! Looks accurate however with comment that it is not really a bug that caused it but more design limitation. In certain configuration it prevents to perform paginated query that is both efficient and accurate. Hence user duplicated entries was considered as less harmful outcome. Configuration switch just uses less efficient query that will return accurate results (no duplication) with a performance tradeoff.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -A bug in the Organization API caused inefficient paginated user queries. This was identified when user duplication occurred across LDAP and within the database, and there was different user data contained in these databases. The portal displayed the last entry in the returned query several times, which was considered less severe than returning a user list with null data. The fix introduces a configuration switch "countPaginatedUsers", which is configurable in the idm-configuration.xml file. The switch should be set to false to prevent duplicated entries in query results.+A design limitation in the Organization API caused inefficient paginated user queries. This was identified when user duplication occurred across LDAP and within the database, and there was different user data contained in these databases. The portal displayed the last entry in the returned query several times, which caused confusion when interpreting the query results. The fix introduces a configuration switch "countPaginatedUsers", which is configurable in the idm-configuration.xml file. Set the value to false to activate the switch, and improve query accuracy.
Jared, Looks good. Thanks! I will just trust your judgement :)