Configuring workflow validation and revokation in process attached forms

In the beqom Web Application, process forms configured with a workflow can be validated or revoked according to the workflow specifications. Due to the complexity of their implementation, the activation of the validation and revocation features must be manually configured.

This is an note/information message.

Process validation and form validation are two disparate actions.

The following article details the required configuration to enable the validation and revocation features in a process form for users with the correct permissions granted to their profile.

Enabling Validation or Revocation

By default, the validate and invalidate rights are denied and must be enabled via the method below whereas the edit and read permissions are automatically granted with the role assigned to the user's profile (Viewer, Manager or Designer) via the bqm_object_access table.

The state of the Submit and Revoke buttons in attached forms is enabled via the configuration of the DenyValidate and DenyInvalidate parameters, as shown in the following stored procedure:

CREATE PROC [dbo].[Kernel_SP_Object_AccessOverride]

@uidObject UNIQUEIDENTIFIER,

@uidProfile UNIQUEIDENTIFIER,

@uidUser UNIQUEIDENTIFIER,

@idStep int,

@idTree int,

@idTreeSecurity int

AS

Declare @DenyRead bit = 0;

Declare @DenyEdit bit = 0;

Declare @DenyValidate bit = 1;

Declare @DenyInvalidate bit = 1;

-- Custom Logic

select @DenyRead as DenyRead, @DenyEdit as DenyEdit, @DenyValidate as DenyValidate, @DenyInvalidate as DenyInvalidate

The following table gives additional information on the parameters used in the above method:

Parameter	Description	Location
uidObject	Attached form's UID	Method parameter
uidProfile	User's active profile UID loaded from user context	Session
uidUser	User's UID loaded from user context	Session
idStep	Step ID of the selected employee in the process grid	Process token
idTree	Selected hierarchy ID	Process token
idTreeSecurity	If the hierarchy security is enabled, k_tree_security unique ID	Process token
DenyValidate	0 = validation allowed 1 = validation denied	-
DenyInvalidate	0 = revocation allowed 1 = revocation denied	-

Refer to the following diagram to better understand the concept:

Forms Permissions Logic

Configuring a Custom Error Message

Depending on the requirements, the logic when users submit or revoke a form is configurable. For instance, you can configure the display of an error message when the form requirements are not respected.

The following stored procedure enables to create this custom logic:

CREATE PROC [dbo].[Kernel_SP_Object_PreValidate]

@uidObject UNIQUEIDENTIFIER,

@uidProfile UNIQUEIDENTIFIER,

@uidUser UNIQUEIDENTIFIER,

@idStep int,

@idTree int,

@idTreeSecurity int,

@isValidation bit

AS

Declare @SuccessFlag bit = 1;

Declare @ErrorMessage nvarchar(max) = '';

-- Custom Logic

select @SuccessFlag as SuccessFlag, @ErrorMessage as ErrorMessage

The following table gives more information about the requested parameters:

Parameter	Description	Location
uidObject	Attached form's unique ID	Method parameter
uidProfile	Logged in user's active profile UID loaded from user context	Session
uidUser	Logged in user UID loaded from user context	Session
idStep	Step ID of the selected employee in the process grid	Process token
idTree	Selected hierarchy ID	Process token
idTreeSecurity	If the hierarchy security is enabled, k_tree_security unique ID	Process token
isValidation	TRUE = validation (submit) FALSE = invalidation (revoke)	-
SuccessFlag	0 = an error occurred 1 = the validation/revocation is successful	-
ErrorMessage	If SuccessFlag is 0 = the configured error message is returned	-

Understanding Form Statuses

When a form is created and assigned to a process grid, you might be tasked to review it depending on your role and eventually validate or invalidate its status. The statuses of the form follow a specific logic which allows to perform different actions.

Not Submitted Forms

When a form has not been submitted yet, users can edit its content and save the modifications at any time. The Save and Submit buttons are thus enabled. When sharing that state, the form permission parameters are the following:

access: {

read: true;

edit: true,

validate: true;

invalidate: false;

}

It is possible to save a form containing an error (the application will return an warning message) whereas its submission is only possible when all the requirements are met.

Submitted Forms

At the moment the form is submitted, its validation flag is changed to "validated" if all the requirements are respected. The Save and Submit buttons are thus disabled and users cannot edit its content anymore. Only the Revoke button is accessible. When sharing that state, the form permission parameters are the following:

access: {

read: true;

edit: false,

validate: false;

invalidate: true;

}

Revoking a form will change its state to "invalided".