Objective: To enable citizens to access contextual help and information with links to various features such as Pay Via WhatsApp.
The feature provides users with tenant-specific 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.
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.
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" }
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.
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"}
]}
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.
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.
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"}
How it works properties and video links are added for each service from MDMS Config.
Service
Navigation Screen URL
API
Payload Params
1
PT
digit-ui/citizen/pt-home
property-services/property/_search
{
tenantId : ""
fromDate :
toDate :
status : "ACTIVE"
}
2
TL
digit-ui/citizen/tl-home
tl-services/v1/_search
{
tenantId : ""
}
3
WS
digit-ui/citizen/ws-home
inbox/v1/dss/_search
{
module: "WS"
tenantId: ""
}
4
PGR
digit-ui/citizen/pgr-home
pgr-services/v2/request/_search
{
tenantId : ""
}
5
BPA
digit-ui/citizen/obps-home
inbox/v1/dss/_search
{
module: "BPA"
tenantId: ""
}
6
MCOLLECT
digit-ui/citizen/mcollect-home
echallan-services/eChallan/v1/_search
{
tenantId : ""
}
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.
Prior Knowledge of Java/J2EE.
Prior Knowledge of SpringBoot.
Prior Knowledge of PostgresSQL.
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior Knowledge of JSONQuery in Postgres. (Similar to PostgresSQL with a few aggregate functions.)
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 - egov-mdms-data/DocumentUploader.json at DEV · egovernments/egov-mdms-data
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 -
ULB
Document name
Document category
Links
Attachments
Upon deleting any document, that document is soft deleted from the records i.e. that document’s active field is set to false.
/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.
/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.
/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.
/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.
Detailed API payloads for interacting with document service for all four endpoints can be found in the following collection - https://www.getpostman.com/collections/c0774674d0c8c05181a7
The link to the swagger documentation can be found below -
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.
Prior knowledge of Java/J2EE.
Prior knowledge of SpringBoot.
Prior knowledge of PostgresSQL.
Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Prior knowledge of JSONQuery in Postgres. (Similar to PostgresSQL with a few aggregate functions.)
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 -
short answer type
long answer type
multiple answers type
checkbox answer type
date answer type
time answer type
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 -
tenantIds - To search surveys based on multiple ULBs
title - To search surveys based on survey names
postedBy - To search surveys based on employees who created the survey
status - To search surveys based on status
Also, if any created survey needs to be updated -
Before the survey becomes active, users can edit all the fields.
While editing, we can add, delete, and modify questions.
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.
NOTE: 1. In search of a survey we display only questions which are in active status 2. While editing, if a question of a survey is deleted, then we mark the question as inactive in db
The link to the swagger documentation can be found below -
APIs for interacting with survey service can be found in this collection
Survey persister