Loading...
Loading...
Loading...
Loading...
Citizen feedback service configuration details
This document is a guide to create a new Survey as well as to create Responses.
To create a new survey, use following _create api:
The ServiceDefinition
object requires following properties:
"tenantId" => Takes tenantid
"code": "PT_PAYMENT" => This shall contain the name of the survey, usually corresponding to the name of the flow for which the survey is being created,
"module": "PT" => This denotes the module name for which the survey is to be created,
"isActive": true => This would tell if the survey is isActive or not,
"attributes " => This would contain multiple objects each of which will be a linked to a Question/ property. This question would be mentioned in the "code"
property.
Currently Surveys have been created for PT module. We have 4 surveys : PT_CREATE, PT_UPDATE, PT_MUTATION, PT_PAYMENT.
To create a survey response(i.e. user response to survey), use following _create api:
The Service
object requires following properties:
"tenantId" => Takes tenantid
"serviceDefId": "7fe72b01-32fc-4baa-8024-166f5367a93a" => This takes the id of the survey for which the response has to be created,
"isActive": true => This would tell if the survey is active or not,
"attributes " => This would contain multiple objects related to the answer to the questions in the survey.
For searching existing surveys or their response use _search APIS from the below collection.
Postman-collection : https://api.postman.com/collections/19481088-f3d5018c-aad2-46de-a5a9-609d2acb1e6e?access_key=PMAT-01GVN63T0S1B6G641TD5DWF12P
Feedback flow for citizens - UI screens and configuration details
Objective: To provide the user facility to submit feedback/ratings at the end of the service.
Users can provide feedback for the following at the end of the flows for create, mutate, update and payment for property tax. If the review is skipped, users can provide their reviews once the property is active on my application details page. The user will receive a pop-up for the feedback.
In the My Application screen, the service search API is called with tenantId and referenceIds (an array of acknowledgement numbers retrieved from property search) in order to get the data of the submitted feedback. The following labels are displayed on the action button:
If the review is done and active: View.
If the review is not done and active: Rate Us.
If the application is in progress: Track.
Inside the Application details page also service search is also called in order to check whether the feedback has been done or not, if it has been done for that particular application popup is not visible otherwise pop-up displays once the application details page opens up.
On this screen, the user is able to give a rating by clicking on the stars (out of 5). Once the stars are clicked, according to the value, “What went wrong?” or “What went good?” comment box is visible, which is a non-mandatory field where the user can add their comment for the review/rating.
Once the user submits the rating, the Search API is called in order to retrieve the service definition for the particular business service, and with that ID the Create API is called for the submission of the review. Based on the success or failure of the call, the screen displays the acknowledgement page. Once the review is submitted, a toast message is displayed providing the status of the submission as a popup.
For Service Create following request object is needed :
Service Create API curl :
The citizen feedback screen and acknowledgement screen can be found inside the core module, path for the same respectively are :
In the Citizen feedback component, the card header, card text and the rating value are fetched from the MDMS file. This is configurable in nature and the following hook is being used to get the MDMS data.
Localization keys are added under the ‘rainmaker-common’ locale module. In future, if any new labels are implemented in the Citizen Feedback (Citizen) they should also be pushed in the locale DB under the rainmaker-common locale module.
UI details for consent forms for citizen users
Objective: This feature allows users to get consent from the citizen during the citizen login. This is needed only on the citizen/architect side of the login. This feature is present on the citizen login page where the user is allowed to make payments without login.
Citizen users must enter their mobile number and tick the check box. Clicking on the Next button enables users to log in.
The next screen is visible as below:
Enter mandatory fields and tick the check box. Clicking on the Next button enables users to proceed to the next step.
Clicking on Privacy Policy opens a popup with the policy content.
Share the HTML file with the DevOps team with the bucket name, they will provide the s3 link for html file.
Here, 1. isCitizenConsentFormEnabled is used to enable the citizen consent form. 2. checkBoxLabels is used to display labels along with the link. 3. link is used to display the link. 4. linkId is used to pass the id to the header to display the header dynamically. 5. en_IN is the language code and is also used to display the content using the s3 link. 6. linkPrefix is used to display the link pre-content. 7. linkPostfix is used to display the link post content. 8. CitizenConsentForm is the mdms config.
Localisation keys are added under the ‘rainmaker-common’ locale module.
API | Action Id | Role |
---|
Using the MDMS, we can enable or disable the feature by setting the param isCitizenConsentFormEnabled
: true or false in the MDMS file ().
Setting it to true indicates the feature is enabled. Setting it to false indicates the feature is disabled (old logic will work as it is).
The first step is to enable the feature in MDMS and add the check box labels checkBoxLabels
in the MDMS file .
File Path:
Component: CitizenConsentForm
(File path: )
The first step is to enable the feature in MDMS and add the check box labels checkBoxLabels
in the MDMS file
File Path:
Component: CitizenConsentForm
(File path: )
Write the documentation then convert it into HTML. (There are multiple conversion tools online like ). Use anyone to convert the document to HTML. Before converting make sure to format the document using the above link.
Take that link and update it in the MDMS file where we configured before . For each instance, we need to create a separate s3 link.
Here, use the language as the key and the URL as the param.
Example: for English, the language key is en_IN
and value is https://qa.digit.org/egov-qa-assets/ProductPrivacypolicy.html
MDMS file:
MDMS: The same file is used in OLD UI also i.e. ( ) File Path: Added one more object in the login form config. ( ) The logic of the Citizen Consent Form is in the below files.
/access/v1/actions/mdms/_get | 870 | CITIZEN |
/egov-mdms-service/v1/_search | 954 | CITIZEN |
/localization/messages/v1/_search | 1531 | CITIZEN |
/service-request/service/definition/v1/_search | CITIZEN |
/service-request/service/v1/_create | CITIZEN |
/service-request/service/v1/_search | CITIZEN |
Service Request Module Configuration
The service request functionality empowers users to define and then create services based on predefined service definitions. These service definitions can be in the form of surveys or checklists that users can refer to. Subsequently, a service created against a service definition can either serve as a response to a survey or represent a completed checklist.
Prior knowledge of Java/J2EE.
Prior knowledge of SpringBoot.
Prior knowledge of PostgreSQL.
Prior knowledge of REST APIs and related concepts like path parameters, headers, JSON etc.
Users can -
Create and search service definitions
Create and search services
/service-request/service/definition/v1/_create - Include the RequestInfo and ServiceDefinition within the request body. The ServiceDefinition encapsulates all the essential parameters linked to the creation of the service definition.
/service-request/service/definition/v1/_search - Allows searching of existing service definitions. Takes RequestInfo, ServiceDefinitionCriteria and Pagination objects in the request body.
/service-request/service/v1/_create - Takes RequestInfo and Service in the request body. Service has all the parameters related to the service being created against a particular ServiceDefinition.
/service-request/service/v1/_search - Allows searching of existing services created against service definitions. Takes RequestInfo, ServiceCriteria and Pagination objects in the request body.
Detailed API payloads for interacting with Service Request for all four endpoints are available in the following collection - Service Request Collection
The link to the swagger documentation can be found here - Service Request Contract