Workflow Component
Last updated
Last updated
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
There are two common components for workflow related actions and timeline management.
WorkflowActions - WorkflowActions
WorkflowTimeline - WorkflowTimeline
Both of these components are available on each View Screen. The WorkflowTimeline component is responsible for presenting the workflow history at the bottom of the View Screen. Similarly, the WorkflowActions component renders an action bar at the bottom of the view screens, showcasing pertinent actions based on the logged-in user's role and workflow configuration.
This component is directly integrated with the ApplicationDetailsContent component that renders all the relevant data in view screens. WorkflowTimeline component is called in this component like this:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
applicationNo -> Idgen generated application number
tenantId
timelineStatusPrefix -> prefix used in localisation of every checkpoint in timeline
statusAttribute -> here we can pass the attribute(either status/state) that is the key in the workflow process instance response, whichever we want to show in the checkpoint.
This component internally calls the workflow APIs to fetch the process instance of the application and renders the history accordingly. It also makes a check for the current state of the application. If the current state is not terminated state then it will show an extra checkpoint at the top with statusAttribute as status to show pending states checkpoint. If the current state is terminated state then it will not show pending states.
Refer to the below snapshots, notice they both have 4 checkpoints. Approved refers to terminate state.
This component is rendered on every View component separately to render the action bar with relevant actions.
Sample code Snapshot:
It expects a few props:
BusinessService -> Name of the businessService from workflow configuration
forcedActionPrefix -> for localization
applicationNo -> Idgen generated application number
tenantId
applicationDetails -> same data returned from hook used on view screen
Url -> update API url to hit
setStateChanged -> when update is successful this is called. Hence search apis will be called again and workflow history and workflow actions will be updated without screen refresh
moduleCode
editApplicationNumber -> Used in case of edit/modify action
This component internally calls the update apis and shows a relevant toast on success/failure or a response screen in case of edit action.
A significant part of this component is another component called the WorkflowPopup. This is the popup that renders whenever the user clicks on a specific action. This popup is fully configurable through this configuration file Popup Config. Popup configs are defined in this configuration file which are organised as per the businessService of the workflow configuration. Refer to the configMap object in this file for more details.
