Policy Workflow Wrap Up
Last updated
Last updated
We can then look at the entire process.
We can also look at the code that has been created programmatically from the defined workflow by clicking on the โ<>โ button in the three-button chevron on the right-hand side.
The full coded version of the policy we just demoed is below (Reminder the coded version of this policy is for Guardian verison 1.0.2):
//Policy logic starts with block 1.
{
//blockType - the type of the block:
// "InterfaceContainerBlock" - a block which contains and organizes other blocks.
// First block should always be of the "InterfaceContainerBlock" type.
"blockType": "InterfaceContainerBlock",
//defaultActive shows whether this block is active at this time and whether it needs to be shown.
"defaultActive": true,
//permissions - users with these roles are allowed to interact with the block. Can contain the following values:
// "OWNER" = creator of the Policy.
// "NO_ROLE" = users without a role.
// "ANY_ROLE" = users with any role.
// "INSTALLER" = only users with a particular role (in this case - INSTALLER).
"permissions": [
// As per above, this block is accessible to all users (with any role).
"ANY_ROLE"
],
//uiMetaData - additional options which don't affect the behavior of the block but are needed for rendering.
"uiMetaData": {
//type - block UI behavior, can contain the following values:
// "blank" - does not contain any frame, will render all child elements one after the other.
// "tabs" - a container which has a tab for each of the child element. It will render the first child element as type "blank".
"type": "blank"
},
//children - list of child blocks in a container block.
"children": [
//First policy step - select a role.
{
//"PolicyRolesBlock" - block which determines a role for the user.
"blockType": "PolicyRolesBlock",
//"tag" - a unique (for the Policy) textual tag for the block which can be used in other blocks for linking.
"tag": "choose_role",
//Non ContainerBlock do not contain child elements. They can exist but they are ignored for rendering.
"children": [],
"uiMetaData": {
//html component has title and descriptions, which can be specified in the corresponding elements.
"title": "registration",
"description": "choose a role"
},
"permissions": [
//Only users with no roles assigned can access the block.
"NO_ROLE"
],
//This block is active
"defaultActive": true,
//"roles" - available roles from which the user can choose.
"roles": [
//In this case the user can only be the INSTALLER.
"INSTALLER"
]
},
// After the role is selected the corresponding branch in the policy will become accessible for the user.
{
//"InterfaceStepBlock" - similar to the InterfaceContainerBlock, with the difference that it can only render a single child element.
//Rendered component is determined by the current step.
//An event on a component automatically passes control to the next component.
"blockType": "InterfaceStepBlock",
"defaultActive": true,
"tag": "init_installer_steps",
"permissions": [
//This block is only accessible to users with the INSTALLER role.
"INSTALLER"
],
"uiMetaData": {
//Currently there is only one type - "blank".
//Only 1 active block is rendered.
"type": "blank"
},
"children": [
//First step after the selection of the INSTALLER roles is to fill out the VC form.
{
//"requestVcDocumenBlock" - a type of the block which creates a form from the schema, and sends the document to the server.
"blockType": "requestVcDocumentBlock",
"tag": "add_new_installer_request",
"defaultActive": true,
"permissions": [
"INSTALLER"
],
//"schema" - uuid of the schema, which will be used to build the form.
"schema": "1a5347ba-5e5f-49a7-8734-3dcc953a03ed",
//"idType" - when the documents is saved it would automatically get an ID.
// In this example the document ID would be the DID of the current user.
// Can be one of these values:
// "UUID" - new uuid.
// "DID" - new DID.
// "OWNER" - DID of the current user.
"idType": "OWNER",
"uiMetaData": {
//"type" - style of the render of the form, one of these values:
// "page" - the form is rendered as a page.
// "dialog" - displays a button, which opens a dialogue with the form when clicked.
"type": "page",
// The page contains title and description, as well as the form.
"title": "New Installer",
"description": "Description"
}
},
// Next step is to save it in the DB.
{
//"sendToGuardianBlock" - a type of the block which can save a new or updated document.
//This block does not contain defaultActive and does not render, only relevant on the server side.
"blockType": "sendToGuardianBlock",
"tag": "save_new_approve_document",
//"dataType" - where to save the document, possible values:
// "approve" - approve DB table.
// "vc-documents" - vc-documents DB table.
// "did-documents" - did-documents DB table.
// "hedera" - document would be sent to the corresponding Policy topic in Hedera.
// In this example VC would be stored in a approve table, waiting for approval.
"dataType": "approve",
//"entityType" - mark the document in the DB. Needed for filtering.
"entityType": "Installer",
//"stopPropagation" - end processing here, don't pass control to the next block.
"stopPropagation": false,
"uiMetaData": {}
},
// Notify the user after submitting the request for approval.
{
//"InformationBlock" - block type which can display a notification or a progress bar.
"blockType": "InformationBlock",
"tag": "wait_fo_approve",
"children": [],
"uiMetaData": {
//"type" - notification type, possible values:
// "text" - textual message.
// "loader" - progress bar.
"type": "text",
// Set title and description for the page, only if the "type" is "text".
"title": "Waiting for approval",
"description": "Waiting for approval"
},
"permissions": [
"INSTALLER"