Objective: Users can look for the list of the properties registered for their mobile number in My Properties tab.

The initial view for each property offers the Property Id, Owner Name, Address and status, along with the View Details button. Users can click on this button to look up more details about the registered property. In case the users do not find the property they are looking for, they can click on the Click here to Register New Property option to register the property.

Clicking on the View Details button displays the Property Information page containing the necessary information about the property.

Technical Implementation Details

Click here to fetch the working code for the My Properties and Property Details common Index.

The template for My properties and Property Information page is present inside pt/pages/citizen/MyProperties. The list of properties is retrieved by calling the search API /property-services/property/_search.

This API is called using the React hook present inside the index of My Properties and Property information page. A single property is loaded, bypassing the unique Property Id in the search API.

If the search API result is successful, Assessment Search API is called to know the assessment status. Assessment Search API - /property-services/assessment/_search.

If the assessment object returned fetches assessment array details then the fetch bill API is called to retrieve the payment details for the particular property.

Fetch bill API - /billing-service/bill/v2/_fetchbill

Following is the hook used for the property search API, assessment search and fetch bill.

const { isLoading, isError, error, data } = Digit.Hooks.pt.usePropertySearch(tenantId);
const assessmentData = await Digit.PTService.assessmentSearch({ tenantId, filters: { propertyIds } });
billData = await Digit.PaymentService.fetchBill(tenantId, {
     businessService: "PT",
     consumerCode: propertyIds,
   });

MDMS

No MDMS data is used here. All data is loaded from the Search API.

Localization

The localization keys for My Properties are added to the ‘rainmaker-pt’ locale module. Any changes, updates or addition of a new localization key are done in the same locale module.

Role Action Mapping

Objective: The Quick Pay feature allows a citizen to quickly view or pay all his pending bills for Property Tax (or any other supported business Service) by clicking links directly from the Digit-UI home screen.

Clicking on the Property Tax link in the Quick Pay section, a user is redirected to the My Bills screen. Else, the user has to log in using his mobile number and the OTP is sent to the number. The user is then redirected to the My Bills screen.

On the My Bills screen, the user finds his pending property tax bills (displayed as cards) for registered properties. The user can click on the View Details button of the corresponding card to check the detailed bill summary which takes him to the bill details page. There is also a link for the case when the user is unable to find the property tax bills.

The Bill Details screen shows a list of various categories of applicable taxes. After checking the user can select to pay either the full amount or the custom amount, which cannot be less than ₹100 and not more than the total tax. These restrictions, however, are customizable as per ULB requirement and can be changed in the MDMS.

Clicking on the Proceed To Pay button redirects the user to the Pay screen. The user is asked to select the payment gateway using the radio buttons. On clicking pay, the user is redirected to the bank payment gateway.

After making a successful payment through the bank gateway, the user is redirected to the response screen which shows the details of the payment and other bill details.

In case the payment fails for any reason the response screen shows the message, that the payment transaction has failed.

Use Case: when user wants to pay for property registered to a different mobile number

My Bills page only displays the properties with pending taxes linked to the mobile number used to log in. To search and pay for any other property, users can click on the link below the My Bills screen that redirects the user to the search screen.

On the Search screen, the user can search a property by mobile number, a unique property ID, or an existing property ID. The search parameters redirects the user to the search results screen. Here users can see all the properties with the matching criteria, whether or not they have pending taxes.

Clicking on the View Details buttons redirects the user to the bill details screen.

Technical Details

My Bills Screen

Click here to fetch the My Bills screen starting file

An MDMS call is made to this page to fetch details based on the defined restrictions such as partial payment is allowed or not, advance payment allowed or not, minimum payable amount etc. for the particular business service which is supplied into URL.

The MDMS criteria used here for fetching MDMS details are:

{
  "MdmsCriteria": {
    "tenantId": "pb",
    "moduleDetails": [
      {
        "moduleName": "BillingService",
        "masterDetails": [
          {
            "name": "BusinessService"
          },
          {
            "name": "TaxHeadMaster"
          },
          {
            "name": "TaxPeriod"
          }
        ]
        }
      ]
    }
  }

The pending bills are fetched for the citizen for the specific business service using the custom hook, that fetches bills linked to the logged-in mobile number.

The bill is rendered using a keynoteConfig file which can be located here.

On this page, for each business service, there is a configuration stored to define what part of the bill is to be displayed.

The configuration returns an object of structure.

{
        "my-bill": [
          {
            keyValue: "CS_COMMON_AMOUNT_DUE",
            keyPath: [
              (d) => {
                const overdueBy = new Date().getTime() - new Date(d.billDetails[0]?.toPeriod).getTime();
                const days = Math.floor(overdueBy / (86400 * 1000));
                return (
                  <React.Fragment>
                    {"₹" + d["totalAmount"]}
                    {days >= 0 ? (
                      <span className={"card-label-error"} style={{ fontSize: "16px", fontWeight: "normal" }}>{` ( ${t(
                        "CS_PAYMENT_OVERDUE"
                      )} ${days} ${t(days === 1 ? "CS_COMMON_DAY" : "CS_COMMON_DAYS")})`}</span>
                    ) : null}
                  </React.Fragment>
                );
              },
            ],
            fallback: "N/A",
            noteStyle: { fontWeight: "bold", fontSize: "24px", paddingTop: "5px" },
          },
          {
            keyValue: "PT_PROPERTY_ID",
            keyPath: ["propertyId"],
            fallback: "",
          }
        ]
}

Here my-bill key has config for the my-bills screen. This configuration decides what details to show on the card for each service from the bill object returned by the fetchBill API.

It is an array of objects, where each object puts the bill detail on the My-Bills bill card.

Each object contains 4 properties ie keyValue, keyPath, fallback, noteStyle. The keynote config is added into the Digit component Registry as getBillDetailsConfigWithBusinessService

The implementation of the config can be found here.

Bill Details Screen

The bill details screen can be found here.

It checks for various payment restrictions that are fetched from the MDMS on above mentioned My Bills description. The tax heads that are to be displayed in the summary are also fetched from the same MDMS.

The structure for payment rule response from the MDMS are -

 {
                   "businessService": "PropertyTax",
                    "code": "PT",
                    "collectionModesNotAllowed": [
                        "DD",
                        "OFFLINE_NEFT",
                        "OFFLINE_RTGS",
                        "POSTAL_ORDER"
                    ],
                    "partPaymentAllowed": true,
                    "minAmountPayable": 100,
                    "isAdvanceAllowed": false,
                    "demandUpdateTime": 86400000,
                    "isVoucherCreationEnabled": true,
                    "billGineiURL": "egov-searcher/bill-genie/billswithaddranduser/_g
}

partPaymentAllowed key when true allows payment less than bill details to be paid otherwise the user can pay only the bill Amount.

minAmountPayable is the minimum bill amount a user can pay.

isAdvanceAllowed if the true user can enter the amount more than the specified.

The link for the MDMS can be found here.

Payment Screen

The payment screen fetches the payment gateways from an MDMS call.

{
  "MdmsCriteria": {
    "tenantId": "pb",
    "moduleDetails": [
      {
        "moduleName": "DIGIT-UI",
        "masterDetails": [
          {
            "name": "PaymentGateway"
          }
        ]
      }
    ]
  }
}

The code can be found here.

Response Screen

The response page code can be found here.

Search Screen

The search screen is a part of PT module and its code can be found here.

Search Result Screen

The Search Result screen code can be referred to here.

Adding a new bill detail for the business service

The keynote config is responsible for adding the new bill UI for adding a new bill for a business service.

The whole function is exposed within the component Registry as getBillDetailsConfigWithBusinessService and can be redefined from here.

Role Action Mapping

Objective: The Search and Pay feature enables the user to search the property (with or without login) and pay any pending dues. It provides the user with the option to load all the bills linked to the registered mobile number and pay the bill.

Search Property

Users can search for Property with or without login. Property can be searched either using Property Id or using property details.

Once the user provides certain parameters it calls the search property API and displays the search results accordingly.

Clicking on the View Details button redirects the user to the bill details page. The users can pay the dues from this page.

Users can view the break-up of the total amount due and select full or partial payment as required. They can enter the amount to be paid in case the partial payment option is selected.

Clicking on the Proceed To Pay button redirects the users to the Payer’s Details page.

• For Logged In Users, the below information is captured.

  1. I am making the payment as the owner/ consumer of the service.

  2. I am making the payment on the behalf of the owner/ consumer of the service.

     • In case of option (i) is selected, the owner’s detail is linked with the receipt.

     • In case option (ii) is selected, the user’s profile detail is linked with the receipt.

• For without login users, the below information is captured.

  1. I am making the payment as the owner/ consumer of the service.

  2. I am making the payment on the behalf of the owner/ consumer of the service.

     • In case of option (i) is selected, the owner’s detail is linked with the receipt.

     • In case option (ii) is selected, the user is asked to enter the Name and Mobile No. and the same is linked with the receipt.

Based on the selected option the user is redirected to the total amount page. The flow is same as DIGIT Payments from this screen.

Technical Implementation

The payer information for the payments API is added based on the mentioned criteria.

Role Action Mapping

Objective: The feature allows users to edit the application already created or update the property already registered to their mobile number. After verification, employees can send the application back to the citizen with remarks on required changes. The edit and update feature allows the users to make these changes. It also allows the user to update the details of the property details online as required.

Edit Application

If the property is marked as Send Back to Citizen, the application details page for employees displays the edit option at the bottom of the page.

Update Property

If the property is marked as Verify → Forward → Approved, the Property Details page for the employees displays the Update option at the bottom of the page.

Clicking on the Update button allows users to edit or update property details. The Create Property flow is revisited. The only exception here is the values are pre-populated from the Property object received from Property Search API. On completing the flow the Update API is called and the property is updated successfully.

Technical Implementation Details

The main code contains the functions that transform the property object received in Search API. This includes primarily the Assessment flow units contextualized as per the Create flow since users have to revisit the Create flow with pre-populated details. The data values are updated accordingly. It also contains the routing details for the pages in the Create flow.

MDMS

Localization

The Localization keys for Edit or Update Property are added to the ‘rainmaker-pt’ locale module. Changing, updating, or adding any new localization key is done in the same locale module.

Role Action Mapping

Objective: Provide users with the payment details for properties registered to the given mobile number and facilitating payments.

My Payments

Users can view the list of payments for properties registered to their mobile number in My Payments tab. The initial view displays the Amount Paid, Property Id, Owner Name, Receipt Date and Receipt Number, and the Download Receipt options. Clicking on the Download Receipt button offers a payment receipt details.

Clicking on the Download Receipt button downloads the payment receipt.

Technical Implementation Details

The property search API is called in order to get all the properties linked to the mobile number -https://qa.digit.org/property-services/property/_search?_=1646986118830

Next the payments search API is called to retrieve the payments for each property -

API Hooks used to call APIs are in the index file of My Payments

MDMS

No MDMS data is used here. All data is loaded from the Search API.

Localization

For My Payments the Localization keys are added to the ‘rainmaker-pt’ locale module. Any changes, updates or addition of new localization keys is done in the same locale module.

Role Action Mapping

Objective: To provide employees with the functionality to search properties (either in active or in workflow status) based on locality, owner mobile, or unique Property Id.

The employee also can see the dues for property within the search results and can choose to pay the dues if any, by clicking on collect tax.

Users can also view the current property Details page, to view Property Details, where employees can perform actions like assessment, Updation and Mutation, on an approved active Property.

Technical Details

APIs

The 1st API is used to fetch all the localities, based on the logged in tenant.

The 2nd API is used to fetch the search results of the table data.

The 3rd API is used to fetch the bills showing the taxes due details in search results.

Property Details Page

This page is visible to the employee when they click on the property ID of the property in search.

Here employees can see the latest approved property details. The employee also has the option to start property assessment, transfer ownership, and edit property details.

The employee also has the option to view history - this enables the users to view the owner details within the history of the property.

Payment History

Users can access the payment history of a specific property as well as download the receipt for the same.

Technical Implementation

APIs

Same as in the case of application details. The latest approved data is shown and any data which is not in the workflow is filtered out.

Assessment Popup

The popup is displayed when an employee chooses to assess property from the property details page of active property.

The popup displays the list of financial years to select from:-

A financial year is selected for the assessment of the property.

Technical Details

Assessment Screen

Clicking on the Assess Property button displays the Property Assessment screen.

This screen gives the assessment details of the selected financial year from the popup. It also provides an overview of the property as well as the total calculation details. This value is fetched from the MDMS.

After clicking on Assess Property, the button changes to Proceed To Pay that redirects the employee to the common pay screen.

Technical Details

The following hook is used to retrieve the charge slabs from the MDMS call

API Used

The 1st API is provided with the financial year and property Id as parameters to get the payment estimations for the property.

The 2nd API is used to fetch property details.

The 3rd API is used to create an assessment of the property - this provides the estimated tax value for the property.

Role Action Mapping

Objective: To provide employees with the ability to Edit property Details (except Owner Details).

Edit Application

The Edit form can be used to update the details of an approved property, or whenever an application is in a workflow state that allows/require employees to make changes.

All the updatable Input fields are enabled, and all the fields related to owner details are disabled.

After editing and clicking submit when the user is successful the user is redirected to a success screen similar to that in Employee Create.

Technical details

The implementation details are similar to the create application and uses the same MDMS configurations.

APIs called:1property-services/property/_update

The Update API is supplied with updated property values from the form. All units that are added at the time of creation are set to active : false . The new units are set to active : true. This applies even when no changes are made to the units.

Acknowledgement Screen

If the Property Update is successful. then the employee is directed to the Acknowledgement screen. The screen displays the Acknowledgement Id and the option to download a pdf copy of the acknowledgement containing property details.

Role Action Mapping

Objective: To provide employees with the functionality to search Applications (whether Active or in workflow) based on

1. Application No.

2. Property ID

3. Owner’s Mobile No.

4. Application Type

5. Application Status

6. Create Between Dates

Users can view the application details page by clicking on the application number. The details page allows the employees to initiate and perform different workflow actions.

Technical Details

The below hook is used to call the Property Search API and load the search result:

1const { isLoading, isSuccess, isError, error, data: {Properties: searchReult, Count: count} = {} } = Digit.Hooks.pt.usePropertySearch( 2 { tenantId, 3 filters: payload 4 }, 5 config, 6 );

Role Action Mapping

Objective: To provide user facilities to add a new property, view the property details and the application currently on their number. The feature allows users to update the property or edit the application.

Create Property

Users can add new property using the Create Property button. The workflow captures user inputs through multiple questions and information gathering screens. At the end of the flow, a check page is displayed that enables the user to cross verify the information entered. The application is created on clicking the submit button.

Create Property Flow

Property tax registration information screen is displayed after login. This helps the user identify the required documents to complete the new registration for the property.

Property Details Flow

The users are prompted to enter the details about the property first. The flow chart below illustrates the property details flow.

Assessment Details Flow

The user is next asked to provide the assessment details. This flow captures information related to each floor and the basement.

UI/UX Unit Revamp

Instead of capturing unit data in separate pages the system captures data in one page only. Users can add multiple units by clicking on the Add One More Unit button. The respective unit page loads for each floor and users can add the corresponding units as required.

Address Details Flow

After entering property details, the user is prompted to provide the address of the property. The flow is straightforward, without any conditional routing.

Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, is auto-populated.

Owner Details Flow

Finally, the user is prompted to enter the property owner details. Ownership can be institutional - either Government or Private. Ownership can also be Single or Multiple owners. The system prompts the user to fill in the details accordingly.

In the case of Institutional, the following data is asked in the first screen. The subsequent screen does not change.

In the case of single or multiple owners the following screen is displayed. The rest of the flow remains the same.

Check Page and Acknowledgement Screen

The check page allows users to cross-verify the information furnished across the flows. Users can click on the change button available adjacent to the relevant data to make any change or update the input data. The user is redirected to the relevant page for updates. The subsequent flows are repeated till the user submits the application.

The Create API is called for registration of property. Following is the snippet of the Create API used: 1create: "/property-services/property/_create"

If the API response is successful, then the acknowledgement screen is displayed, else the failed acknowledgement screen is displayed.

Technical Implementation Details

All the screens have been developed using the new-UI structure followed previously in the FSM and PGR module.

The link for the Create Property main index is given below. This provides a better understanding of the starting point of the flow:

https://github.com/egovernments/digit-ui-internals/blob/development/packages/modules/pt/src/pages/citizen/Create/index.js

PT (Property Tax) Module has been segregated into a specified structure. All the screens configuration is available inside the PageComponent Folder. The configuration for routing the pages are mentioned in the config folder common for both citizens and employees. The snippet for the folder structure and routing configuration is given below.

The high-level configuration for controlling the whole flow for citizens and employees is available in the Pages folder. Citizen flows include Create, Edit, My Properties, My Application and Search Property. The search property flow carries the index (the main starting point of the whole flow).

After completing the flow users can download the acknowledgement details of the property created in pdf format. Click here to find the config for the PDF generation.

The Utils folder basically contains all the methods used across the PT module. In case there is a common method that needs to be added, it can be imported into other files.

For creating an application the Create API from Property Tax is called using the React hooks. This hook is declared under hooks or elements of PT as PTService.

MDMS Data

Data across some of the pages are imported from MDMS throughout the flows. The table below lists the pages using MDMS data. In these pages the .js files are found under page components.

Data React hooks are used to call MDMS and these are shared across the module. The code snippet below contains the call used for MDMS.

const { data: OwnerShipCategoryOb } = Digit.Hooks.pt.usePropertyMDMS(stateId, "PropertyTax", "OwnerShipCategory");

Localization

Localization keys are added to the ‘rainmaker-pt’ locale module. In future, if any new labels are implemented in the Property Tax (Citizen) they should also be pushed to the locale DB under rainmaker-pt locale module. Below is an example of few locale labels.

Role Action Mapping

Documents and Resource Links

Objective: To provide the employees involved in PT workflow, the functionalities to create a property Application in create workflow.

Create Application

A counter employee can use create an application form, to register a citizen’s property.

Technical Implementation

The file for create Application form for PT can be found in:-

https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/pt/src/pages/employee/NewApplication/index.js

for creating an application employee enters all the details of the form manually, and Documents are uploaded based on the MDMS configuration found in the file:

https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/Documents.json

MDMS Data

1. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/Floor.json

2. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/OccupancyType.json

3. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/OwnerShipCategory.json

4. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/OwnerType.json

5. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/PropertyType.json

6. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/UsageCategory.json

7. https://github.com/egovernments/egov-mdms-data/blob/DEV/data/pb/PropertyTax/SubOwnerShipCategory.json

The MDMS data for documents is similar to that found in :

**with the noted addition of formDataPath, formArrayAttrPath, in filterCondition and dropdownFilter .

formDataPath path is the form path in form of an array of keys that requires to be followed to a new UI form to check the entered value. similar to jsonPath and parentJsonpath in old UI, While the formArrayAttrPath replaces the arrayAttribute.

The use of the MDMS data within the component can be found in :

https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/pt/src/pageComponents/SelectDocuments.js

After adding all the valid documents and form values in the form, the user is allowed to submit the form

which calls the property create API:1property-services/property/_create

Acknowledgement Screen

If the Property creation is successful. then the employee is directed to this screen that shows Acknowledgement Id and the option to download a hardcopy of the acknowledgement containing property details.

Role Mapping

Objective: To provide citizens with the functionality to apply for Ownership Transfer for an active property.

The Transfer of Ownership Option is provided to citizens on the home screen in the citizen App, under property Tax card.

Upon clicking on “Transfer Property Ownership/Mutation” link, users are taken to property search page just like in case of “search & Pay” option, where he can search for the property he wants to search the property for.

After searching the property the user is shown the property details for the properties based on the search criteria. With Total Dues on top of the card.

If there are dues owed on the property (unpaid taxes), then users are shown a popup stating that the citizen has to clear his dues first. with a proceed to pay button that takes citizens to the common pay page, just like in the case of Search & Pay.

In case of dues cleared the citizen is taken to the Docs required Page, just like in the case of Employee Mutation, where he is shown the list of docs he is supposed to have in order to be able to transfer the property.

on this page after clicking on Transfer of Ownership, the citizen is made to go through the Ownership Transfer flow where he fills in the Ownership details and Mutation Details. After completing the flow citizen is shown with the success screen with his application number and the option to download his acknowledgement as a pdf.

Technical Details

MDMS data

The MDMS data is the same as in the case of employee Mutation Screen.

API used

The citizen mutation calls the property-services/property/_update API to update the property status after that the application is gone through the Employee workflow to complete the transfer.

When Update API is called the documents are updated for the property according to the following snippet:-

        documents: [
          ...originalProperty.documents.map((oldDoc) => {
            if (mutationDocs?.PropertyTax?.MutationDocuments.some((mut) => oldDoc.documentType.includes(mut.code))) {
              return { ...oldDoc, status: "INACTIVE" };
            } else return oldDoc;
          }),
          ...newDocs,
        ],

Here originalProperty is the property data before mutation, and mutationDocs is the MDMS response for Mutation Docs.

Role Action Mapping

Objective: Users can review the list of applications and their status registered under their mobile number in the My Applications tab.

Initially, only four applications are loaded on the screen. The user can click on the Load More option to view more applications. Each application displays the Application Number, Service Category, Property Id, Application Type and Status details along with the Track option. This enables the user to find more details about the application. If users are unable to find their property details on the system, a new application can be created using the link provided at the bottom of the page.

Once the user clicks on the Track button, the Application Details page is displayed with all the necessary information about the application.

Timeline component: The timeline component is available at the end of the application details. This provides the details on the current status and history of the application passing through various workflows and actions taken.

Technical Implementation Details

Click here to fetch the working code details for My Applications and Application Details common Index.

The template for My Application is present under pt/pages/citizen/PTMyApplications and the Application Details page is present inside pt/pages/citizen named as PTApplicationDetails. The list of applications is retrieved by calling the search API "/property-services/property/_search".

This API is called using the React hook present inside the index of PTMyapplication and PTApplicationDetails page. A single application is loaded bypassing the unique Property Id in the search API.

Following is the hook used for the property search API.

const { isLoading, isError, error, data } = Digit.Hooks.pt.usePropertySearch(tenantId);

Create and Update Util Function

The two main util functions and their objectives are given below:

Create Util Function: While going through the Create flow, all the inputs provided by the user are stored in a different structure. Since the units are not separated in the flow but incorporated into distinct categories, the storing structure is different from the request body of Create API. This function transforms the flow of stored data into the requested body format.

Click here to fetch the code.

Update Util Function: Click here to find detailed information about this function.

MDMS

No MDMS data is used here - all the data is loaded from the Search API.

Localization

For My Applications, the localization keys are added to the ‘rainmaker-pt’ locale module same as in My Properties and Create Property. Any changes, updates or addition of any new localization key is done in the same locale module.

Role Action Mapping

Objective: To Provide employees with functionality to transfer Ownership of an active property.

Documents Required for Mutate Property Page

When a property is in active status and has no dues to pay, the employee has the option to mutate a property on the Property Details page.

The doc required page is shown if the property is paid for otherwise the user is redirected to the payment details page. It shows the employee the list of documents required in order to proceed with the form.

Mutate Property Form

Clicking on the Transfer of Ownership button on the required page redirects the employee to the Transfer of Ownership or Mutation form. Here the Transferor details are displayed and the employee can fill out the transferee details form.

Technical Documentation

MDMS Data Used

APIs Called: 1property-services/property/_update

When update API is called the documents are updated in accordance to the snippet below:-

 documents: [
          ...data.originalData?.documents.filter(
            (oldDoc) => !mutationDocs?.PropertyTax?.MutationDocuments.some((mut) => oldDoc.documentType.includes(mut.code))
          ),
          ...data.documents.documents.map((e) =>
            e.documentType.includes("OWNER.TRANSFERREASONDOCUMENT") ? { ...e, documentType: e.documentType.split(".")[2] } : e
          ),
        ],

Here data.originalData is the property before the update. The data.documents is the documents that were uploaded in the form, and mutationDocs is the MDMS response for Mutation Docs.

Acknowledgement Screen

If the Property Mutation is successful. then the employee is directed to the acknowledgement screen. The screen displays the Acknowledgement Id and the option to download a pdf copy of the acknowledgement containing property details.

Role Action Mapping

Objective: To provide employees with the functionality to search for created applications.

Employee Inbox

The employee inbox screen shows all created applications in workflow and requires action from the logged-in employee.

The employee has the ability to search for specific applications based on application number, property ID, or mobile number. Filters can be applied based on the business service (create, edit, or update), application status, locality, and assigned applications.

Clicking on the application number hyperlink in the inbox redirects the user to the application details page. The user can take the required action on the application to push it forward or backwards in the workflow.

Technical Details

File path for inbox: digit-ui-internals/Inbox.js at main · egovernments/digit-ui-internals

API Used

Below is the API used for searching the inbox:

/inbox/v1/_search

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

Customizations

The 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>
            );
          },
        }
      ]
     },
}

inboxCloumns and searchColumns functions return an array of objects where 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:-

1. Header is the heading that is used in the head of the column (basically name of the column).

2. 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.

3. Cell is a function returning a valid JSX. In case some complex component requires to be rendered, the function is supplied an object with row property. Each row contains property details, with row.original being the actual data for the property row. The searchData contains search-related results associated with the property, while workflowData contains workflow related data associated with property.

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

Application Details Page

This page is where the employee is redirected after clicking on the application number in the inbox. The user finds the Take Action button at the bottom of the screen and performs actions based on the employee's role and the state of the application in the workflow. Users can also view the timeline where they can see the updates by other employees and the actions taken on the application so far.

The employee views details like owner details, address along with the documents attached at the time of creation. In the case of mutation applications, the employee can see transferer and transferee details.

While performing the action users can upload docs, add comments for the next employee in workflow, or they can assign them to a specific employees 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

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 processed through the process instance.

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 existing process instance. This is then filtered through as per the actions performable by the employee’s role.

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

Role Action Mapping

Objective: Provide employees with the options to view the assigned, escalated applications and the applications that are pending for action.

Route - mSeva

Technical Implementation Details

Inbox screen can be divided into 4 sub components as listed below:

1. Sidebar

2. Quick action button

3. Service List

4. Inbox worklist

Sidebar

Action Menu is the component that shows the menu items in the sidebar based on the response from the access/v1/actions/mdms/_get API .

Quick action

Quick Action button which shows the menu based on the response from the access/v1/actions/mdms/_get API.

Service List

Service List is the component that shows the menu based on the response from the access/v1/actions/mdms/_get API.

Inbox Worklist

Inbox worklist is the component that shows the records based on the response from the /egov-workflow-v2/egov-wf/process/_search API.

Inbox worklist contains options to filter and search the records based on the options.

Fetching all the records from the process instance is not made in a single call since we might fetch a lot of records. So we make a call to get the total count from egov-workflow-v2/egov-wf/process/_count API. After that, we load the initial records for all business services.

Once all the records are fetched the system loads the locality of the records based on the locality search provided by the service (BUSINESS SERVICE).

Assigned To Me Tab

The Assigned To Me Tab displays all assigned applications for the logged-in user.

All records are fetched from the process instance response that filters the records based on the following condition:

1get(item, 'assignes[0].uuid')=== uuid;

Here, the UUID is the logged-in Employees User id and the item is the total records.

SLA

SLA of the Application is based on the businesssServiceSla and it is converted using the following conversion:

item.businesssServiceSla / (1000 * 60 * 60 * 24)

Nearing Escalation And Escalated

Nearing Escalation and Escalated is identified based on the businesssServiceSla present in that record and the configured MDMS data wfSlaConfig

It contains the slot colour and percentage.

Pagination

Pagination is configured in the MDMS to hold default records and default options to show rows per page.

Table and Table pagination can be accessed from this file link below.

MDMS config

{
    "tenantId": "pb",
    "moduleName": "common-masters",
    "TablePaginationOptions": [
        {
            "rowsPerPageOptions": [25, 50, 100],
            "defaultValue": 100
        }
    ]
}

Application Redirection

In every row, there is an option to view or perform an action on the record and this redirects users to the relevant module.

Refer to the Config below.

 "tenantId": "pb",
    "moduleName": "common-masters",
    "CommonInboxConfig": [{
            "moduleName": "PT",
            "BusinessService": "PT.CREATE",
            "roles": ["PT_CEMP", "PT_DOC_VERIFIER","PT_FIELD_INSPECTOR","PT_APPROVER"],
            "active": false,
            "locality":false,
            "localityModule":"property-services",
            "redirectConfig": {
                "INITIATED": "/employee/property-tax/application-preview?applicationNumber=^WFBID^&tenantId=^WFTNID^&type=property",
                "DEFAULT": "/employee/property-tax/application-preview?applicationNumber=^WFBID^&tenantId=^WFTNID^&type=property"
              }
        },

Redirection for every module should be configured in redirectConfigand similarly for any other config like active, locality, and locality modules.

Escalated Tab

Here in Escalated tab, it makes an escalation search, using egov-workflow-v2/egov-wf/escalate/_search.The object structure is similar to the process search.

On View History - It shows which state has it got escalated using flag. isEscalatedApplicationbased on it it shows a red mark for the corresponding state.

Filter Options

Here all the filter options are derived from the records that we receive through the process instances. It is not from any MDMS data.

Role Action Mapping