Hi,

So what you want is for the removed user to still be shown as part of the group or role, for auditing purposes? If that is your goal, then you cannot just rely on the UMUser SmartObject.

The UMUser is querying the information from the Identity.Identity and Identity.IdentityMember tables on the K2 database. The Identity.Identity table stores all your users' identity cache, while the IdentityMember stores all membership information for roles and AD groups.

When a user is removed or disabled in AD, K2 will automatically disable the user's identity cache the next time the user's identity cache expires, and K2 refreshes the identity cache. When the user's identity cache is disabled, the UMUser will not recognize the user as part of the group or role.

If you need to keep the group membership records for auditing purposes, then I am afraid you cannot just rely on the UMUser SmartObject. You will have to find some other way to store the the group memberships.

Hi,

Thanks for your response but maybe I should have been more clear. I'm aware that I can't avoid this with UMUser exclusively. I'm just curious what other users of K2 have built to work around this as the only option I can see is essentially creating my own cache table of users and adding a 'isDisabled' flag when they're no longer matching in UMUser. 

I assume it depends on how one see/understand "historical forms" - in my opinion it should be something that don't rely on too many interactive controls/pickers but something that rather presents a view which should have no trouble displaying user details of disabled users and be further filtered. All controls which hide disabled/deleted users are doing so as they designed for runtime forms and they should not show deleted users. Historical forms supposed to retrieve data from OOB reporting and/or identity cache (there should be no problems with getting disabled user details for displaying them). I'm a bit confused by description of historical form in your question - does not looks as anything "historical" and probably can be addressed through better design.

Essentially when I say 'historical forms', we're generally trying to use the same forms for data capture as we do for data display. This means the pickers need to exclude outdated options when capturing and include outdated options while reviewing. 'Historical forms' just meaning stored data that doesn't match with the current picker dataset. Our standard business practice is to delete a user account after 3 months which means we can't just include disabled users as they'll not be available anymore. This also applies to resolving other lookup info other than users. 

What you've said as to my form design may still be true, but please see the attached sql to maybe understand my requirements a bit better.

Each user/group list control is populated by this stored proc with the relevant LKGroup. Only non-'deleted' values are returned by default. As we're executing the form load before populating these lists we can pass in the stored value to the procedure. This means loading forms that were completed in the past will still display the right information.

I'm a bit of a SQL/K2 newbie but right now I can't see any real downsides to using this approach but I'm happy to be made aware of any risks. 

Providing that you populate pickers through custom SQL stored procedure - you can then pass different parameters or use different stored procedure based on form/view type or state to distinguish historical and capture/new forms so that it will dictate visibility of deleted users in pickers. Form can stay the same you can just have some flag or state which define controls population type. That sounds to me as a viable solution to your scenario. Or maybe I'm missing something?