Skip to main content


 

Symptoms

 


1. Users during a specific time frame could not view processes (View Flow)
2. Error seen in the logs appears like the following:

"2869454357","2014-12-01 15:52:45","Error","General","1","GeneralErrorMessage","K2Worker.ViewProcessInstance","1 28023 K2:COMPANYusername does not have permissions to view the process","","","xyz:C:Program Files (x86)K2 blackpearlHost ServerBin","2869454357","8c5596fe151645d88c460108dda4be3b",""

3. Build No. 4.6.6
 

 

Diagnoses

 


1. Bad refresh in the Identity Cache

 

 

Resolution

What to look for:
If users are unable to View Flow or Processes consistently (and not intermittently) in Workspace, but are in Groups explicitly given permissions on Workspace, there may be an Identity Cache issue.

What is happening:
The issue occurs when a user’s memberships are refreshed. The Identity Service refreshes by default every 8 hours and sometimes there are bad refreshes the refresh may not resolve the correct users in groups. In other words, there are cases where the user’s memberships are removed from the Identity Service for a group.

Troubleshooting Steps
1. To check if a user is in a group, use the following sample script in SQL on the K2 Server, which will list the user’s Group Memberships
a. Right click the K2HostServer database and click ‘New Query’
b. Paste the following script, replacing the example with the correct user (note, Replace "alyssa" with the user having the issues. Leave the ‘ marks):

Declare
@UserFQN varchar(50)
Set @UserFQN = 'K2:Denallixalyssa'
Select * from bIdentity]. Identity]
where eIdentity]./Identity].eID] in
(Select DIdentity].(IdentityMember].ContainerID
from tIdentity]. IdentityMember]
where MMemberID] = (Select ID from Identity].IIdentity] where FQN = @UserFQN))

c. Click ‘Execute’
d. You may find that the user is not in the group they’re supposed to be in. Make note of this and move on to the next step if this is the case.

2. Use the Force Identity Refresh app.
a. Enter in the user and check Identity, Memberships and Containers. Press ‘Clear Identity Cache.’
b. What this will do is expire the user early so that you don’t have to wait 8 hours for the refresh. By default, every 10 minutes the database resolves expired identities.

3. Instead of waiting 10 minutes for the newly expired identity to be resolved, you can speed this up by doing the following

a. Navigate to the SmartObjects Service Tester (C:Program Files (x86)K2 blackpearlBin)
b. Drill down SmartObject Explorer > All SmartObjects > UMUser
c. Right click UMUser and select ‘Execute SmartObject’
d. Choose the ‘Get User Details’ as the Method to Execute and in the FQN ( Text ) – Required field type in the user info
e. Click ‘Execute’

4. You can now reuse the script from step 1 to check if the user is resolved correctly and is in the proper group. This should fix the issue.

****
5. If you find that you have to do this continually and consistently for this issue, log a new ticket and request the Identity Coldfix for blackpearl 4.6.6.

 

 



 

Can you please send a diagnosis flow step for Appit as well? If customers use Appit, they do not have access to the database.

Thanks. 


Reply