Creating users on DIGIT post installation
This doc provides the steps to create and add users on the DIGIT platform post-installation.
Run the kubectl port-forwarding of the egov-user service from the Kubernetes cluster to your local host. This gives you access to egov-user service, bypassing Zuul auth, and you can now interact with the User API directly.
kubectl port-forward svc/egov-user 8080:8080 -n egov
You will see below text in the Terminal:
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Ensure you have installed the Postman utility to run the following scripts. If not, Install postman on your local machine. Import the collection into Postman. Create an environment variable for “tenantId” and set its value to your tenant.
The collection creates four types of users and also provides a way to refresh the auth token:
Super User
System User
Citizen
Anonymous User
Run all the scripts in order.
The refresh auth token script logs into the server and refreshes the token. A sample script is provided for the employee user. Similar scripts can be copied for the citizen/super user etc..for convenience.
Setting up boundary hierarchies for tenants
The location module serves the boundary hierarchies for a tenant. Location is defined separately for every tenant (mostly ULBs) in DIGIT. Each tenant has a unique tenantId.
The tenantId key can be a combination of state or state.city or state.city.ulb. The hierarchyType can be one of Revenue, Admin or Election. Multiple hierarchy types can be defined for the same city tenant.
The entire hierarchy can be defined in a nested way as children. One sample of location data for the Amritsar ULB is available here.
Location data is stored in GitHub as part of MDMS. The egov-location folder needs to be created inside the city tenant (see Amritsar example above). It is stored in the following format:
Enter the boundary hierarchy data in the <tenant>/egov-location/boundary-data.json file in the appropriate branch of your forked MDMS repository. For example - if you want changes to be visible in the Dev environment, add the data in the DEV branch of the MDMS repository.
Follow the Git flow processes to ensure high-quality data. Make sure the PR requests are raised, verified and merged especially where multiple people are working on the same branch.
Restart the MDMS service in your environment once the new data is available in the desired branch.
Users also need to upsert localisation codes for any new boundary data in MDMS. Else, users see the label names (auto-generated) for the city names in the UI. Check the Localisation Data Setup guide for more information on how to perform localisation.
The localisation code should follow the following format - *tenantId*_*moduleName*_*hierarchyType*_*cityCode*_*zoneCode*_*blockCode*_*areaCode
For example, to find the localisation code for "Ajitnagar area 1", assuming tenantId as "pb" and hierarchyType as "Revenue":
moduleName: EGOV-LOCATION
cityCode: PB.AMRITSAR
zoneCode: Z1
blockCode: B1
areaCode: SUN04
So finally the localisation label code for "Ajitnagar area 1" would be PB_EGOV-LOCATION_REVENUE_PB.AMRITSAR_Z1_B1_SUN04 (visible in the UI if no localisation is present).
Setting up localisation strings
This guide goes through inserting basic localisation for core DIGIT modules post-installation. Currently, localisation is an extra step post-install. We enter localisation data in bulk via REST API calls. Postman collection is available to facilitate this process.
The releasekit repository contains all the localisation strings separated per module.
Base localisation strings are provided in the baseline folder. Localization is done per module per release. New strings in each release are contained in the respective release version folder. Depending on what modules have been installed, the localization strings have to be collated and then seeded using Postman Scripts.
For example, if DIGIT v2.7 with the PGR module has been installed, the localization strings for the PGR module have to be collated in the following order in JSON:
Baseline localization strings
v2.3
v2.4
v2.5
v2.6
v2.7
For convenience, a consolidated JSON file per module is created with each release under the consolidated folder. To add the messages, copy the json string of one module and paste it into the body of the JSON request and hit upsert. Repeat this for each module.
Download the postman collection - Setup an environment in postman and add the following variables:
authToken
tenantId
Login to DIGIT as a citizen user from the browser. To get auth token on your webpage, right-click and go to Inspect > Network > payload > RequestInfo. Here you will find a variable named authToken which will be a 32-bit string. Paste it in the values field of the authToken variable in Postman and click on Save.
Run the Insert Localization script after adding the required localization messages for each module from releasekit consolidated folder in the Postman script body.
Run each module separately. Else, the server will throw a 40x error.
The modules to set up depending on what has been installed as part of DIGIT. For the DIGIT Core, we require localisation to be set up for the user module.
Search endpoint: domain/localization/messages/v1/_search
Upsert endpoint: domain/localization/messages/v1/_upsert
Seeding data in DIGIT post installation
Post the installation of DIGIT, follow the guides below to set up data.
| Module | Localization folder |
|---|---|
egov-user