Overview

This document provides the customisation details for DIGIT UI. Customisation can be classified broadly into two types -

1. Overriding the Component/Hooks/CSS

2. Overwriting the required changes directly into the Micro-ui-internals

Overriding

Overriding involves making all customization changes exclusively within the micro-ui/web directory.

For CSS

Within the custom CSS module, define customized CSS using the same class name or ID. Afterward, publish the changes. Ensure to reference this custom CSS file in the index.html to reflect the modifications on the website.

<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-css@1.5.22/dist/index.css" />
<link rel="stylesheet" href="https://unpkg.com/@egovernments/digit-ui-custom-css@0.2.6/dist/index.css" />// Some code

For Components/Hooks

For overriding any components, re-register the same component in the same name in the customization folder. The latest changes are reflected.

Overwriting Changes

Overwriting involves directly modifying the micro-ui-internals directory. This is slightly more challenging method to incorporate changes. Make sure the docker file is updated as per the code below and includes the install-deps.sh script.

```
dockerfile

RUN cd web/ \
    && node envs.js \
    &&  ./install-deps.sh \
    && yarn install \
    && yarn build 
```

The workspace in the web/package.json should be updated as below:

```json
 "workspaces": [
    "micro-ui-internals/packages/libraries",
    "micro-ui-internals/packages/react-components",
```

Overview

This page explores the steps to publish CSS if there are any CSS Customization/changes. While customising, if any changes are made In the CSS folder it has to be compiled and published to npm.

Steps

Currently, the CSS is published in npm as @egovernments/digit-ui-css

Refer to the NPM link here - .

So any changes to the CSS folder locally must be published in different organisations and in the same or different package name. For example - @xyz/digit-ui-css and version 1.0.0 then the following changes have to be made in the code to reflect in the digit-ui

​ - file location

frontend/micro-ui/web/public/index.html

The style sheet link must be updated as follows,

<link rel="stylesheet" href="https://unpkg.com/@xyz/digit-ui-css@1.0.0/dist/index.css"/>

Use either of the following commands to publish the CSS

• In the frontend/micro-ui/web/micro-ui-internals folder run yarn run publish:css or

• In the frontend/micro-ui/web/micro-ui-internals/packages/css folder run yarn run publish --access public

There are two ways to customize the CSS -

1. Override the required CSS only without changing in the CSS folder and making changes only in the custom CSS folder. Both CSS will be present in the index.html the order of the package mentioned in the HTML determines which CSS needs to be taken ie the box mentioned in the last will have more precedence. example of overriding CSS as follow -

2. Overwrite the complete existing CSS.

Reference doc for publishing any package to npm -

Overview

A new component called KibanaCard.js has been introduced to render Kibana DSS based on the configuration provided in dashboardConfig. This document outlines the steps to integrate the Kibana Dashboard with the DSS module.

Configuration

In the dashboardConfig, a new configuration has been added to render Kibana DSS. The configuration includes details that specify which Kibana dashboards to render.

So here moduleName refers to the module name in uiConstants master and pageName refers to the iframe routes route information.

Rendering KibanaCard

Based on the configuration, we render the KibanaCard component, passing moduleName and pageName as props.

Internal Implementation

Within KibanaCard, we utilize the IFrameInterface component. This component receives the following props passed from KibanaCard.

We can define kibana dashboard URL in common-masters in uiCommonConstants.json config. Below are the examples of the structure

This component calls MDMS-V2 common-masters to fetch the URL of the Kibana dashboard and render it using an iframe.

Additionally, if a date range filter is set by the user, we update the Kibana URL to reflect this. The following logic is applied to construct the contextPath:

File Path

MDMS

Configuration

API to fetch common constants

Payload:

Response:

Overview

This utility is designed to transform the MDMS configuration into FormComposer and InboxFormComposer configurations. Typically, every UI configuration relies on certain parameters. These parameters might include dropdown dependencies or custom classes determined at runtime based on specific logic. However, since the configuration is in JSON format stored within MDMS, direct usage of variables is not feasible. To address this requirement, we've developed a utility capable of converting this JSON into a parameter-based JSON structure.

Steps

This utility serves as an engine that accepts MDMS configurations along with dependent parameters. It then processes this data to generate a parameter-enabled configuration. This resultant configuration can be utilized by FormComposer and InboxFormComposer to render the UI elements accordingly.

Below is the method used to configure the MDMS -

{
             "isMandatory": true,
             "key": "noSubProject_ward",
             "type": "radioordropdown",
             "label": "PDF_STATIC_LABEL_ESTIMATE_WARD",
             "disable": false,
             "preProcess": {
               "updateDependent": [
                 "populators.options"
               ]
             },
             "populators": {
               "name": "noSubProject_ward",
               "optionsKey": "i18nKey",
               "error": "WORKS_REQUIRED_ERR",
               "required": false,
               "optionsCustomStyle": {
                 "top": "2.5rem"
               },
               "options": []
             }
           },

1. Pass the JSON path of the dependent key that requires runtime updates. In the example above, the target is on “populators.options”.

2. Update the options at runtime based on certain logic.

1. Once the configuration is complete, this will be added to MDMS. So, the next thing is to pass this config and its dependencies to the Pre-Process utility. The Namespace to access this utility :

Digit.Utils.preProcessMDMSConfig(t, MDMSObject, dependencyObject);

The dependency Object contains multiple actions which the pre-process function runs for us.

1. Translate - This targets the JSON path and does translation for the passed data.

2. updateDependent - This targets the JSON path and update the dependencies.

3. convertStringToRegex - This targets the JSON path and converts the String RegEx to RegExp based Regex.

Refer to the sample example below -

const config = useMemo(
     () => Digit.Utils.preProcessMDMSConfig(t, createProjectConfig, {
       updateDependent : [
         {
           key : 'withSubProject_project_subScheme',
           value : [withSubProjectSubSchemeOptions]
         },
         {
           key : 'noSubProject_subScheme',
           value : [noSubProjectSubSchemeOptions]
         },
         {
           key : 'noSubProject_subTypeOfProject',
           value : [subTypeOfProjectOptions]
         },
         {
           key : 'noSubProject_ulb',
           value : [ULBOptions]
         },
         {
           key : 'noSubProject_ward',
           value : [wardsAndLocalities?.wards]
         },
         {
           key : 'noSubProject_locality',
           value : [filteredLocalities]
         },
         {
           key : "citizenInfoLabel",
           value : [showInfoLabel ? 'project-banner' : 'project-banner display-none']
         },
         {
           key : "noSubProject_endDate",
           value : [!isEndDateValid ? (() => isEndDateValid) : (()=>{})]
         },
         {
           key : "basicDetails_dateOfProposal",
           value : [new Date().toISOString().split("T")[0]]
         },
         {
           key : "basicDetails_projectID",
           value : [!isModify ? "none" : "flex"]
         }
       ]
     }),
     [withSubProjectSubSchemeOptions, noSubProjectSubSchemeOptions,
      subTypeOfProjectOptions, ULBOptions, wardsAndLocalities, filteredLocalities, showInfoLabel, isEndDateValid]); 

In the example above, we are using the action “updatedependent” from pre-process utility.

• “Key” targets the input key name. This will help preprocess to target the right input field.

• “Value” - Each input within the configuration is associated with a JSON path, with each path targeting a dependent object. As previously demonstrated, we passed the JSON in a specific order within an array. Similarly, we must pass the corresponding dependent values in the same order to ensure alignment with the correct targets.

A similar utility is also developed for InboxSearchComposer. Refer to this same document for both utilities.

Overview

A new feature, the Privacy Component, has been added to the login screen to enhance user transparency. This component displays privacy policy information based on the login configuration. Follow the steps below to configure this component on the login screen.

Steps

Integrate With Login Configuration

To render the Privacy Component, you must include specific configurations in the MDMS :

• Master Name: commonUiConfig

• Module Name: LoginConfig

If these configurations are not present, the default login configuration will be rendered instead.

Filter Privacy Data

The content displayed within the Privacy Component's pop-up will be filtered according to the module code specified in the schema.

Customise Login Fields

The fields on the login screen are fully configurable. Users can add or remove fields according to their specific requirements.

Set Login Button

To ensure all mandatory fields are completed, the login button will be disabled until all required fields are filled. This ensures that users provide all necessary information before proceeding.

Example Configurations

Here are some examples of different configurations for the login screen and their corresponding displays:

These configs will help to enable/disable the privacy declaration, at an instance level.

"inputs": [
                  {
                      "label": "CORE_LOGIN_USERNAME",
                      "type": "text",
                      "key": "username",
                      "isMandatory": true,
                      "populators": {
                          "name": "username",
                          "validation": {
                              "required": true
                          },
                          "error": "ERR_USERNAME_REQUIRED"
                      }
                  },
                  {
                      "label": "CORE_LOGIN_PASSWORD",
                      "type": "password",
                      "key": "password",
                      "populators": {
                          "name": "password",
                          "validation": {
                              "required": true
                          },
                          "error": "ERR_PASSWORD_REQUIRED"
                      },
                      "isMandatory": true
                  }
              ]

[
                  {
                      "label": "CORE_LOGIN_USERNAME",
                      "type": "text",
                      "key": "username",
                      "isMandatory": true,
                      "populators": {
                          "name": "username",
                          "validation": {
                              "required": true
                          },
                          "error": "ERR_USERNAME_REQUIRED"
                      }
                  },
                  {
                      "label": "CORE_LOGIN_PASSWORD",
                      "type": "password",
                      "key": "password",
                      "populators": {
                          "name": "password",
                          "validation": {
                              "required": true
                          },
                          "error": "ERR_PASSWORD_REQUIRED"
                      },
                      "isMandatory": true
                  },
                  {
                      "isMandatory": false,
                      "key": "check",
                      "type": "component",
                      "component": "PrivacyComponent",
                      "withoutLabel": true,
                      "disable": false,
                      "customProps": {
                          "module": "HCM"
                      },
                      "populators": {
                          "name": "check"
                      }
                  }
              ]

Default Screen :

Data Customisation: The data can be modified through MDMS and localization updates. MDMS Path: Login Configuration Privacy policy schema Click here to access the privacy component file.

Localisation modules used:

digit-privacy-policy

rainmaker-common

Overview

This document provides the steps on how to integrate another UI into the DIGIT UI using iframe.

Steps

1. Enable the Utilities module.

   • Add these MDMS configurations to enable the Utilities module.

   • Add the mentioned changes in your web/src/App.js and web/package.json to enable the module in the Build.

2. Once the Utilities module is enabled, add the following changes to the master (file path given below).

Reference Master details: data/pg/commonmasters/uiCommonConstants.json

  "uiCommonConstants": [
      {
         "shg": {
            "iframe-routes": {
               "home": {
                  "routePath": "/works-shg-app/",
                  "isOrigin": true
               }
            }
         }
      }
   ]

Here -

• shg is the path name to access inside digit-ui;

• home is the route to access it;

• whatever is mentioned inside routePath should be the Application/Pod name that is expected to be shown inside the digit-ui;

1. Once the MDMS changes are applied, access the new application using the following route - <SERVER_URL>/digit-ui/employee/utilities/iframe/<PATH_NAME>/<ROUTE_NAME>

Examples: New Web Application (UI - any framework)

DIGIT UI