Version 9.1.202.2 (Support Release - 7 January 2026)

System Access 
 Update email confirmation logic for user import and update to allow a user without an email to log in (#142626) 
 Problem 
 
 A user without an email address cannot log in because the email has not been confirmed 
 
   
 Solution 
 
 In ImportUsersCommandHandler, email is now considered confirmed if the user has no email address 
 In UpdateUserCommandHandler, email is always marked as confirmed 
 These changes ensure consistent handling of email confirmation status during user import and update operations 
 
   
 
 Imports 
 Remove duplicate self-service settings in validation when importing users (#142626) 
 Problem 
 
 Cannot import users when ESS settings are duplicated in the DB  
 
   
 Solution 
 
 This pull request addresses the issue of duplicate entries in the `SelfServiceSetup` table and improves the handling of required fields in the user details validation logic. The most important changes are as follows:
 
 Removes duplicate rows in ESS settings, keeping only the most recently edited entry for each unique combination of `FieldSection`, `FieldId`, and `RulesetId`. 
 Updated the construction of the `requiredFields` dictionary in `UserDetailsValidationService.cs` to ensure unique combinations of `FieldSection` and `FieldId` are included, preventing issues caused by duplicate settings. 
 
 
 
   
 
 Performance Management 
 Resolved KPI not being able to delete (#143253) 
 Problem 
 
 Primary contract bool value not being sent through, which caused an invalid object  
 
   
 Solution 
 
 Add a change to pass through the primary contract's bool value 
 
   
 
 People Management 
 Re-add transfer person JS logic (#143186) 
 Problem 
 
 The transfer button was removed.  
 
   
 Solution 
 
 Re-add it 
 
   
 Fix materialisation when a people group has not materialised before | Fix regression bug on people termination (#136729) 
 Problem 
 
 When materialising people groups and the list of people groups to materialise is empty, it only materialises for people groups that have already been materialised in the past.  
 
   
 Solution 
 
 When the 'forceSync' parameter is true, refresh for ALL people groups on the ruleset (if an empty people group was received). 
 Still, only materialise people groups already materialised when 'forceSync' is false.  
 PLUS Other issue picked up while testing:
 
 Termination broken due to a regression bug. 
 A new field was added to a model used in a query in the job profiler, but the query was not updated, which results in the query breaking, meaning ultimately, people cannot be terminated anymore.  
 Updated the model to make use of auto properties instead of a constructor, which makes it easier for Dapper to map the query result to the model.