Reconsider implementation of Typo3UserRepository::setUserGroups to retain be_users.usergroup ordering

[J. Peter M. Schuler]

While for fe_users the group orders make no difference, this is not the case for be_users, as groups can not only contain permissions, but also tree mounts. We e.g. got a lot of editors who have access to multiple site and these sites have a priority, e.g.:

• a big major site and smaller sites
• a site with many daily changes vs. some basically read-only sites

In that cases we tend to "sort" the groups in the field be_users.usergroup accordingly, so that the first tree mount is the most relevant one and up on top.

However the implementation for the usergroup check and override at

t3ext-ig_ldap_sso_auth/Classes/Domain/Repository/Typo3UserRepository.php

Lines 398 to 411 in 785ade1

 $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class) 
     ->getQueryBuilderForTable($table); 
 $rows = $queryBuilder 
     ->select('uid') 
     ->from($table) 
     ->where( 
         $queryBuilder->expr()->in('uid', $usergroup), 
         $queryBuilder->expr()->eq('tx_igldapssoauth_dn', $queryBuilder->createNamedParameter('', \PDO::PARAM_STR)) 
     ) 
     ->execute() 
     ->fetchAllAssociative(); 
 foreach ($rows as $row) { 
     $localUserGroups[] = $row['uid']; 
 } 

doesn't filter the current groups by valid ones, but rather replaces them with the SQL result used to find valid ones. While using SQL here is quite elegant in that regard, it doesn't offer the option to retain the order, so the groups are re-ordered on every login (even if group sync is deactivated and keep groups is on).

So I propose to either do that filtering in PHP instead (foreach through current groups and compare with SQL result) or add an static orderBy statement (in many SQL dialects orderBy can not only be asc/desc, but also accept a CSV, however I don't know if doctrine supports that).

[Xavier Perseguers]

Hello. I see. Would you mind create such a PR (based on PHP filtering, I find it more robust than trying to do that with Doctrine but without being able to properly test on all DBMS).

[J. Peter M. Schuler]

I agree completely with that approach.
Will give the PR a go as soon as time comes up, put a blocker for 2nd Nov for it.