Objective: To enable citizens to access contextual help and information with links to various features such as Pay Via WhatsApp.

Help Section

Workflow Details

The feature provides users with tenant-specific data.

Technical Implementation Details

Dynamic Data

The dynamic data are displayed in range cells. We get the dynamic data from the particular service APIs. These APIs enable open search so that citizen users can check these data even if they are not logged in.

MDMS

Static data like Helpline, Service Center, Pay Via WhatsApp link and validity of an application is fetched from the MDMS config.

If we do not want any of the cards to be displayed, this can be removed from MDMS for the particular service.

 "MdmsCriteria": {
        "tenantId": "pb",
        "moduleDetails": [
            {
                "moduleName": "common-masters",
                "masterDetails": [
                    {
                        "name": "StaticData"
                    }
                ]
            }
        ]
    }

Add links to FAQs and How it works for each module:

We can add FAQs and the How it works links in the MDMS for each service.

Navigation URL for FAQs: "/digit-ui/citizen/{module}-faq"

(Replace {module} with moduleCode. For Ex: "/digit-ui/citizen/pt-faq")

Navigation URL for How it works : "/digit-ui/citizen/{module}-how-it-works"

(Replace {module} with moduleCode. For Ex: "/digit-ui/citizen/pt-how-it-works")

Object reference:

{"id": 2331,

"name": "PT_FAQ_S",

"url": "digit-ui-card",

"displayName": "FAQs",

"orderNumber": 1,

"parentModule": "PT",

"enabled": true,

"navigationURL": "/digit-ui/citizen/pt-faq",

"leftIcon": "propertyIcon",

"sidebar": "digit-ui-links",

"sidebarURL": "/digit-ui/citizen/pt-home" }

FAQs

Workflow Details

Users can check for frequently asked / common questions on this page.

We are using a common screen for all module FAQs. Based on the module code, the FAQs are rendered from MDMS.

Technical Implementation Details

Add new FAQs to the list: We can add new FAQs to the list by adding a new object in the MDMS config for the respective service.

Object reference:

"TL" : {

"faqs": [{

"question": "TL_FAQ_QUES_ONE",

"answer": "TL_FAQ_ANS_ONE"}

]}

MDMS

FAQs are added for each service from MDMS Config. More FAQs can be added in the MDMS and those will be shown in the UI.

 "MdmsCriteria": {
        "tenantId": "pb",
        "moduleDetails": [
            {
                "moduleName": "common-masters",
                "masterDetails": [
                    {
                        "name": "faqs"
                    }
                ]
            }
        ]
    }

How It Works Section

Workflow Details

Users can check what they can do or how they can get the benefits of a particular service.

A common screen is used for all the modules in the How it works section. Based on the module code, the cards are rendered from MDMS.

Add a new Card to the list: We can add a new Card to the list by adding a new object in the MDMS config for the respective service.

On Language change, the link to the videos also changes.

Technical Implementation Details

Object reference:

{"moduleCode" : "PT",

"videosJson": [{

"headerLabel": "ADD_PROPERTY",

"description": "ADD_PROPERTY_VIDEO_DESC",

"en_IN": "http://media.w3.org/2010/05/sintel/trailer.mp4",

"hi_IN": "http://media.w3.org/2010/05/sintel/trailer.mp4"},

"pdfHeader": "CITIZEN_CHARTER_DOCUMENT",

"pdfDesc": "CITIZEN_CHARTER_DOC_DESC"}

MDMS

How it works properties and video links are added for each service from MDMS Config.

 "MdmsCriteria": {
        "tenantId": "pb",
        "moduleDetails": [
            {
                "moduleName": "common-masters",
                "masterDetails": [
                    {
                        "name": "howItWorks"
                    }
                ]
            }
        ]
    }

API Calls To Fetch Dynamic Data

Overview

Surveys are an important way to close the feedback loop on the services that are delivered by ULBs. Without proper surveys, ULB employees will never know how happy the citizens are, about the services they consume and what the areas of improvement are.

The surveys section will be used by ULB employees to create citizen surveys to make better-informed decisions while issuing new policies/ feedback on existing services.

Pre-requisites

1. Prior knowledge of Java/J2EE.

2. Prior knowledge of SpringBoot.

3. Prior knowledge of PostgresSQL.

4. Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

5. Prior knowledge of JSONQuery in Postgres. (Similar to PostgresSQL with a few aggregate functions.)

Key Functionalities

This service allows -

• Employees - to create, edit, delete surveys

• Employees - to share survey results with other employees/citizens

• Citizens - to fill out surveys

Each survey entity will have questions associated with it. Questions can be of -

1. short answer type

2. long answer type

3. multiple answers type

4. checkbox answer type

5. date answer type

6. time answer type

Configuration Details

Survey entities will have a collectCitizenInfo flag associated with them, if that flag is set to true, the mobile number and email address of the citizens responding to the survey will be captured. If it is set to false, responding to the survey will be completely anonymous.

Surveys will have a startDate and endDate associated with them. Within that period, those surveys will be shown in the active section. However, in case the survey has been manually marked inactive by the employee during its active period, that survey will be shown under the inactive surveys section. Citizens can look at active survey entities and submit their responses for that survey.

Once a survey is created, it can be searched with the following parameters -

1. tenantIds - To search surveys based on multiple ULBs

2. title - To search surveys based on survey names

3. postedBy - To search surveys based on employees who created the survey

4. status - To search surveys based on status

Also, if any created survey needs to be updated -

1. Before the survey becomes active, users can edit all the fields.

2. While editing, we can add, delete, and modify questions.

3. Once the survey becomes live user can only change

a. Survey Description

b.End date and time of the survey

In case of deletion of a survey, the survey will be soft deleted i.e. the ‘active’ boolean field will be set to false and it will not appear in search results.

Swagger Documentation

The link to the swagger documentation can be found below -

API Details

APIs for interacting with survey service can be found in this collection

Survey persister

Overview

Document uploader will be used by ULB employees to upload the document which will then be visible to the citizens. In an effort to increase the engagement of citizens with mSeva platform, mSeva is providing this service to enable the citizens to view important documents related to their ULB such as acts, circulars, citizen charters etc.

Pre-requisites

1. Prior Knowledge of Java/J2EE.

2. Prior Knowledge of SpringBoot.

3. Prior Knowledge of PostgresSQL.

4. Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.

5. Prior Knowledge of JSONQuery in Postgres. (Similar to PostgresSQL with a few aggregate functions.)

Key Functionalities And Configurations

Employees can perform all four operations i.e. creating, searching, updating and deleting the documents whereas the citizens can only search for the created documents. For creating documents in a particular ULB, the document category that needs to be provided in the create API cURL has to be present in the document category MDMS file for the tenantId for which the document is getting uploaded.

A sample MDMS document category configuration file can be viewed here -

In this MDMS configuration file, ULB key can be added and the allowed category types can be added in categoryList key.

Once a document is created in any ULB, the following attributes can be updated for that document -

1. ULB

2. Document name

3. Document category

4. Links

5. Attachments

Upon deleting any document, that document is soft deleted from the records i.e. that document’s active field is set to false.

API Details

1. /egov-document-uploader/egov-du/document/_create - Takes RequestInfo and DocumentEntity in request body. Document entity has all the parameters related to the document being inserted.

2. /egov-document-uploader/egov-du/document/_update - Allows editing of attributes related to an already existing document. Searches document based on its uuid and updates attributes.

3. /egov-document-uploader/egov-du/document/_search - Allows searching existing documents in the database. Takes search parameters in the url and RequestInfo in request body. For looking at documents that have been created/updated in a given time range, fromDate and toDate parameters can be used which accept epoch values.

   For looking at documents that have been deleted, viewDeletedDocuments parameter should be used with “true” as the parameter value.

4. /egov-document-uploader/egov-du/document/_delete - Soft deletes an existing document from the database i.e. it makes the document inactive. It takes the DocumentEntity that needs to be deleted in the request body along with RequestInfo object.

Swagger Documentation

The link to the swagger documentation can be found below -