This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice This article is not considered official documentation for K2 software and is provided “as is” with no warranties.
For some users you will be unable to remove them from the Out Of Office setting, neither will their Out of Office setting stick when turning the Out Of Office on.
When attempting to remove or add out of office settings for a user the setting is not committed, and the users out of office can also not be removed from the out of office list.
After executing the below scripts in order, the issue had been fixed however the cause of the issue have been noted as a possible design fault in one of the workflows which would require that you navigate through your workflows in order to rectify the faulty design to eliminate the cause.
The faulty design specified is for example: when a workflow is setup to use a destination user but the user that was added is not a group or role however it had been chosen as such inside of the destination user slot.
Script Executions to trace and fix this issue:
- This script will return a list of users, the users loaded with [Group] will be the ones we need to look at:
Select [A1].ActionerName as OOFUser, [A1].ActionerType as ActionerTypeID,
CASE WHEN [A1].ActionerType = 1 THEN '[User]' ELSE '[Group]' END as ActionerType, CASE WHEN [A1].Status = 1 THEN '[OUT of Office]' ELSE '[IN Office]' END as Status, [A2].ActionerName as OOFDestination, [A2].ActionerType as ActionerTypeID, CASE WHEN [A2].ActionerType = 1 THEN '[User]' ELSE '[Group]' END as DestActionerType From [Server].[Actioner] [A1] Join [Server].[ActionerShare] [AS] On [AS].ActionerID = [A1].[ID] Join [Server].[ActionerShareWorktype] [ASWT] On [ASWT].ActionerShareID = [AS].[ID] Join [Server].[Worktype] [WT] On [WT].[ID] = [ASWT].WorktypeID Join [Server].[WorktypeShare] [WTS] On [WTS].WorktypeID = [WT].[ID] Join [Server].[Actioner] [A2] On [A2].[ID] = [WTS].ActionerID
- This will return a list of all the processes in which the problematic users are participating - if there are some then you can pinpoint the activity and workflow which contains the faulty design however if there are none then continue to the next script execution:
SELECT Server.ProcSet.Name AS ProcessName, Server.ProcSet.FullName as ProcessFullName, Server.Act.Name AS ActivityName, Server.Actioner.ActionerName AS Actioner, Server.Actioner.ActionerType FROM Server.ActionActInstRights INNER JOIN Server.Actioner ON Server.ActionActInstRights.ActionerID = Server.Actioner.ID INNER JOIN Server.ProcInst ON Server.ActionActInstRights.ProcInstID = Server.ProcInst.ID INNER JOIN Server.[Proc] ON Server.ProcInst.ProcID = Server.[Proc].ID INNER JOIN Server.ProcSet ON Server.[Proc].ProcSetID = Server.ProcSet.ID INNER JOIN Server.Act ON Server.ActionActInstRights.ActID = Server.Act.ID where Server.Actioner.ActionerType <> 1
- This will find the problematic users from the out of office settings:
SELECT * FROM [Server].[ActionerShare] S JOIN [Server].[Actioner] A ON A.ID = S.ActionerID WHERE ActionerType <> 1
- This will find the users that is causing the issue from the actioner table (please add your details where specified - YOUR DB NAME, THE USERNAME):
SELECT * FROM [YOUR DB NAME].[Server].[Actioner] where ActionerName like '%THE USERNAME%' and ActionerType <> 1
- This will be the last step to perform, please read the note below:
At this stage there will be a removal process to follow in order to clean this users out, however please do note that direct K2 database modifications are not directly supported by K2 therefore please reach out to K2 support requesting the remainder of this script ?