Employee - Inbox & Application Details

Objective: To provide the employee with the functionality to search the created Applications.

Employee Inbox

The employee inbox screen shows all the created applications which are in the workflow and requires action from that particular employee.

The employee has the ability to search any application based on Application no, Property Id, or mobile number, or he can apply filters, based on the business service (create, edit, or update), application status, locality, and application assigned specifically to him.

By clicking on the /application no in the inbox user goes to the application details page. where he can take action on the application to push it forward or backwards in the workflow.

Technical Details

The file path for inbox can be found in:

digit-ui-internals/Inbox.js at main · egovernments/digit-ui-internals

API Used

The API used for searching the Inbox is

/inbox/v1/_search

The above API is used to fetch the Inbox results based on filters and search criteria.

Customizations

Inbox Screen offers customization for the fields in the inbox table. The fields inside the inbox table are exposed in the component registry service as in the file:

digit-ui-internals/inbox-table-config.js at main · egovernments/digit-ui-internals

It is exposed as PTInboxTableConfig key in component registry service, and can be redefined to reset the columns.

the function returns an object of the following structure:-

{
     PT: {
      inboxColumns: (props) => [
        {
           Header: t("ES_INBOX_UNIQUE_PROPERTY_ID"),
           Cell: ({ row }) => {
             return (
               <div>
                 <span className="link">
                   <Link to={`${props.parentRoute}/application-details/` + row.original?.searchData?.["propertyId"]}>
                     {row.original?.searchData?.["propertyId"]}
                   </Link>
                 </span>
               </div>
             );
           },
         },
       ],
       searchColumns: (props) => [
        {
          Header: t("ES_INBOX_UNIQUE_PROPERTY_ID"),
          accessor: "searchData.propertyId",
          Cell: ({ row }) => {
            return (
              <div>
                <span className="link">
                  <Link to={`${props.parentRoute}/property-details/` + row.original?.searchData?.["propertyId"]}>
                    {row.original?.searchData?.["propertyId"]}
                  </Link>
                </span>
              </div>
            );
          },
        }
      ]
     },
}

the object.PT contains 2 keys inboxCloumns and searchColumns , which are yet again functions.

These functions are provided with props as an argument, which are props supplied to the component called DesktopInbox as can be seen in the following file:-

inboxCloumns and searchColumns functions return an array of objects, each object represents a column.

The inboxCloumns is used for setting columns in the Inbox, while searchColumns is used for setting columns

every column has the following properties:-

Header is the head that is used in thead of the column (basically name of the column).
accessor is . separated string value that specifies the path within each row to be followed in order to display the value of the column. The structure of the row object is similar to row.original explained below.
Cell is function returning a valid JSX, in case some complex component is needed to be rendered. The function is supplied an object with row property, each row containing property details , with row.original being the actual data for the property row which is of the form. The searchData contains search related result associated with the property, while workflowData contains workflow related data associated with property

{
  searchData : {...},
  workflowData : {...}
}

Application Details Page

This page is where the Employee visits after clicking on desired Application No. in the inbox. The user can find a “take action” button at the bottom of the screen and can perform actions, based on the role the employee profile has and the state of the application in the workflow. He can also view the timeline in which he can see which employee made what update in the workflow.

The employee can see details like owner details, address etc, along with the documents attached at the time of creation, and while action performing by any other employee in the workflow. In the case of mutation Application, the employee can see transferer and transferee details.

While performing the action user can upload docs, comments for the next employee in workflow, or they can assign them to a specific employee in the action resultant workflow.

If a particular workflow is completed then, the application is said to be completed and the status of property changes to ACTIVE .

Technical Details

The code for the application details can be found in

APIs Called

The application details page calls the following APIs.

egov-workflow-v2/egov-wf/process/_search?tenantId=pb.amritsar&history=true
/property-services/property/_search
/egov-workflow-v2/egov-wf/businessservice/_search
/filestore/v1/files/url

the 1st API is called to fetch the timeline, through which the Process Instance has gone through.

The 2nd API is called to fetch address, owner-details, and document fileStoreId for all the documents associated with the property.

The 3rd API is called to get current performable actions based on the current state of the process Instance, which is then filtered through according to actions performable by the employee’s role.

The 4th API is called to fetch all the documents for the file store ids.