With the incoming EU General Data Protection Regulations coming in to force as of May 2018 we're looking at what this entails for our K2 applications especially when considering the "right to be forgotten". (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation)
Most of our application data we're in full control of however when a user interacts with K2 a cached identity is created (I think this is the correct terminology) and stored in the table [K2].[Identity].[Identity]. As we use the user's email address as their identity when interacting with our systems, we're tasked with scrubbing this from the database as it's personally identifiable information.
Can anyone advise on what the right process for doing this is?
One particular scenario is that the user, whilst interacting a Smartmorm, may request their account deletion. We had considered doing this in immediately in real-time (logical deletion of app data and masking of personal information before confirming and logging the user out) however I'm not sure on the impact/user experience if we update the identity table at this point too.
If anyone has looked into this scenario before it would be great to hear how you tackled it or any words of advice or equally caution.
In general direct K2 db manipulation is not supported and dependign on K2 version there is also triggers that stops deletion form the K2 Identity cache. If a users account is deleted from AD, K2 will query that provider and if the user is not found then it will disable the user in the db but not deleted, if for some reason that user is recreated in AD then K2 will enable the cached identity again.
I think given your situation, the best route to take here is to open a K2 Support ticket asking the needed questions.
Thanks Vernon for the response.
Yes, we're using a custom user manager that points back to a backend SQL store so it's something we need to consider.
I'll raise a ticket to see what insight can be provided but I'd be keen to hear if anyone else has looked into this area.