Expiring the User Cache: Good for Role Membership, Too

 

We have a demo instance and a production instance of a particular workflow. I got a frantic call from one of the business people telling me that she didn’t have access to all of the roles in the demo instance that she does in production.

I verified this and attempted to correct it by assigning her to the various additional roles. When I asked her to close her browser, then re-open it and navigate back to her worklist, no change had been made.

I tried a number of different things — including setting all of the roles to “Dynamic” (and by the way, you have to click SAVE after checking the box)… nothing.

UNTIL I decided to go big and nuke the user cache. Open SQL Server Management Studio, connect to your K2 database, and paste this short script into a new query:


USE K2
GO

UPDATE [Identity].[Identity]
SET [ExpireOn] = GETDATE()
,[Resolved] = 0
,[ContainersResolved] = 0
,[ContainersExpireOn] = GETDATE()
,[MembersResolved] = 0
,[MembersExpireOn] = GETDATE()

GO

All fixed.

I’d previously thought this was for taking care of lag in AD group assignments… turns out it’s for roles, too. You can get fancy and use it on specific roles, too, as this blog suggests.

Expiring the User Cache: Good for Role Membership, Too