Out Of Office cannot be set or removed

  • 16 February 2021
  • 0 replies
  • 71 views
MillaZ
Userlevel 5
Badge +20
 

Out Of Office cannot be set or removed

kbt132199

PRODUCT
K2 blackpearl 4.7
BASED ON
K2 blackpearl 4.7
TAGS
Destination Users
Workspace
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.
LEGACY/ARCHIVED CONTENT
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

Issue

You may be unable to remove some users from the Out Of Office setting, neither will their Out of Office setting stick when turning the Out Of Office on.

Symptoms

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.

Resolution

 

The issue can be detected by executing the scripts below in sequence. It has been noted that the cause of the issue is 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. After using the scripts below you will need to log a support ticket to obtain an additional script which can then be used to clean these users out. However, you will need to provide the result of the scripts below in this ticket as reference.

The faulty design specified is for example: when a workflow is set up to use a destination user, but the user that was added is not a group or role, but it has been chosen as such inside of the destination user slot.

 

Script Executions to trace this issue

  • This script will return a list of users, the users loaded with [Group] will be the ones you 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 following script returns 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 script 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 script 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


After performing the scripts above in sequence, you should have been able to pinpoint the problematic users. The last step to perform would be to clear these users out, for that you will need to obtain a removal script by logging a support ticket and providing the results of the above as well as this KB as reference. The removal process will the be run through with you by a support engineer via the logged support ticket.

 

 
Please do note that direct K2 database modifications are not directly supported by K2, please reach out to K2 support by logging a support ticket to request the removal scripts mentioned above.
Check out these Nintex University Learning paths: https://community.nintex.com/p/NintexUniversity

0 replies

Be the first to reply!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings