Best method for handling resolution of leavers in historical form data?

  • 10 January 2020
  • 5 replies
  • 4 views
N

Hi, 

 

We've had this on our mind for a little while and can't see any clear solutions.

 

Scenario -

 

A form has a lookup field (picker, multi-select, drop-down list) tied to a UMUser call for group members/role members/general name resolution.

The form is in production and a user's name is saved against a field.

The user is then removed from the group/role or active directory as a whole.

The previously saved form is loaded the controls will not resolve the name.

 

I'm concerned that a multi-select or other controls when changed may then save the data back not including the old user. This could be a nightmare for auditing purposes where loading historical forms and executing saves on them inadvertently wipes data with no indication of a problem. 

 

Pickers are less of a problem as it seems if the data doesn't resolve to an item the update still retains the unresolved item (it doesn't display  the resolved value but I think I can use the 'Display Field' to show the stored value). 

 

Has anyone else found a solution for this?

5 replies

B
Badge +15

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.


 

N

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. 

 

 

M
Badge +11

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.

N

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. 

 

M
Badge +11

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?

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings