Objective
To provide facility to search properties without logging into the application and making payment of pending due amount. This feature is developed only for citizen application.
Implementation Details
This feature has a separate search screen. Citizen can enter the search criteria into the search form and search the properties. The properties obtained by the search operation will be listed in the search table. Below is the details of search criteria.
Field | Input type | Validation rule |
|---|---|---|
ULB | Dropdown | Mandatory |
Locality | Dropdown | Mandatory |
Owner Name | Input text | Optional |
Owner mobile no | Input text | Optional |
Property ID | Input text | Optional |
Atleast one optional field is required along with mandatory inputs to search the properties.
Locality dropdown list depends on the ULB selected.
After successful search, the search results will be displayed in the table as below
URI to access the screen:
URI needs to add in the url after citizen - “/withoutAuth/pt-mutation/public-search“
https://egov-micro-qa.egovernments.org/citizen/withoutAuth/pt-mutation/public-search
PAY option
User can have PAY button in the following scenarios
Property should be ACTIVE
Due amount should be more than 0
If the property is ACTIVE and Advance Payment is enabled then PAY option should present even if the due amount is 0.
On Clicking of PAY button, citizen navigates to common PAY screen. Common PAY screen is existing feature developed and being used across all the module where payment is required. Below is the url to navigate on common pay screen using routing method provided by react. Consumer code and tenant id are dynamic data. Below is the one such example.
/withoutAuth/egov-common/pay?consumerCode=PB-PT-2020-05-30-005181&tenantId=pb.amritsar&businessService=PT
In Public search common pay screen, side bar is hidden since user doesn’t have access to enter other modules without authorization.
Citizen has to pay through payment gateway and all the required service are whitelisted for the payment.
After successful payment, citizen navigates to acknowledgment screen. In this screen, the items which required authorization has been hidden. Here user can generate receipt pdf of the payment done. receipt pdf api is whitelisted.
Technical Implementation Details
Open Search screen is developed as part of property tax module. Below is the search screen configuration file link.
Search screen table, api calls and other utility functions are written in the files under publicSearchResource folder. Below are the file description.
https://github.com/egovernments/frontend/blob/master/web/rainmaker/dev-packages/egov-pt-dev/src/ui-config/screens/specs/pt-mutation/publicSearchResource/search-resources.js - It has the screen configuration like input text, dropdowns, buttons etc.
https://github.com/egovernments/frontend/blob/master/web/rainmaker/dev-packages/egov-pt-dev/src/ui-config/screens/specs/pt-mutation/publicSearchResource/search-methods.js - It has the functions related to search api calls, reset forms etc.
https://github.com/egovernments/frontend/blob/master/web/rainmaker/dev-packages/egov-pt-dev/src/ui-config/screens/specs/pt-mutation/publicSearchResource/publicSearchUtils.js - This file has utility methods supporting api calls, form validation etc.
https://github.com/egovernments/frontend/blob/master/web/rainmaker/dev-packages/egov-pt-dev/src/ui-config/screens/specs/pt-mutation/publicSearchResource/search-table.js - This file has functions that is responsible for making table definitions.
MDMS Call details
We have to make few MDMS calls to get the required configuration related data. Below is the description of MDMS calls used in open search implementation.
MDMS call to get the Tenants data. Tenants data was supplied to ULB dropdown after screen initialization.
API Whitelisting
Since this is open search and citizen can search the properties without logging in the application, certain apis were required to be whitelisted. These apis can return the result without authenticating the user. Below is the list of apis that were whitelisted
"/property-services/property/_search""/billing-service/bill/v2/_search""/egov-location/location/v11/boundarys/_search?hierarchyTypeCode=REVENUE&boundaryType=Locality""pg-service/transaction/v1/_create""pg-service/transaction/v1/_update" + txnQuery"/collection-services/payments/_search""/pdf-service/v1/_create"
API call details
Boundary calls to get the Locality data
Search API Call
URL: "/property-services/property/_search"
method: “post“
QueryParams: [{key:”tenantId”, value:”pb.amritsar”}, {key:”locality”, value:”SUN02”}, {key:”name”, value:”test”}]
3. Search Bill Call
URL: "/billing-service/bill/v2/_search"
method: “post“
QueryParams: [{key:”tenantId”, value:”pb.amritsar”}, {key:”service”, value:”PT”}, {key:“consumerCode“, value:”PT-107-001920,PT-107-000519”}]
Localization Implementation
Search screen locale keys are pushed under rainmaker-pt locale module. Table header locale keys are in rainmaker-common locale module. Localization calls are made before screen initialization and all the locale keys are stored in localStorage.
While selecting the ULB, again a locale call is made for locality dropdown. This call returns the locale keys of every locality dropdown options.
URL: /localization/messages/v1/_search
method: “post“
queryParams: [{key:”module”, value:”rainmaker-common,rainmaker-pt,rainmaker-pgr”}, {key:”locale”, value:”en_IN”}, {key:”tenantId”, value:”pb”}]