Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Every plant operator created will be linked to one or more plants under an urban local body (ULB).
When a plant operator logs in to the system, the top bar is populated with a dropdown which shows a list of plants this user (plant operator) is linked to.
By default, the option "All Plants" is selected.
When a user selects a plant, lets say, plant A, all the data of plant A will be shown in the app, whether it's inbox, view past results page, home page, etc.
Whenever a change in a plant is detected through the dropdown, the app is redirected to the landing screen.
A plant operator is a sanitation worker; while creating a sanitation worker, you can link the sanitation worker to one or multiple plants.
Data such as a list of the current user's plants and active plant is stored in session storage, and is available to use within the app.
Whenever a plant operator logs in, he/she can make a call to this API endpoint "/pqm-service/plant/user/v1/_search" to get a list of the plants that the user is linked to .
Sample payload:
Send the user's individual id/uuid in the request object.
Curl for the above API call:
You will get a list of plants in the response which is used to populate the dropdown.
By default, the "All Plants" option is selected which is the default behaviour.
When a user selects a particular plant, it becomes active and one can filter the data (all tests shown in the app) by that plant's code in the UI.
UI for the top bar:
TQM UI Tech Documentation
TQM is an independent UI module which only depends on the core UI libraries.
Here are the articles in this section:
Logging in with the plant operator role will take the user to the landing page.
The landing page has a list of cards which includes the TQM card.
The landing page shows a pending tasks card at the bottom of the page.
The pending tasks card lists tests pending to be updated by this user.
The tasks which are overdue will show up first in the pending tasks card.
There is an option to view all the pending tasks which takes the user to TQM inbox page.
Clicking on the Treatment Quality Monitoring (TQM) card will take the user to the TQM home page.
The TQM home page shows a TQM card with the links to Inbox, View Past Tests.
It also shows 2 cards below which are -> Your performance, Alerts card.
The "Your Performance" card shows relevant metrics such as test compliance and the percentage of tests that passed which shows the efficiency of the plant(s) linked to the logged in user.
The 'Alerts' card shows a count of the different types of alerts that were raised by the system. This data comes from the anomaly finder.
Enabling TQM module in DIGIT-UI
To access the TQM module in DIGIT-UI, enable it from MDMS and add TQM specific roles for the user to access TQM UI.
Add the following configuration in citymodule.json under this path in MDMS. The reference file is given below.
Add TQM to these files in DIGIT-UI codebase. Add it in enabledModules Array.
Note: The name "TQM" should match the name "Tqm" added in mdms(citymodule). However, uppercase or lowercase does not matter.
frontend\micro-ui\web\micro-ui-internals\example\src\index.js
frontend\micro-ui\web\src\App.js
Files for reference:
Sample object:
PQM_TP_OPERATOR -> This role is for Plant Operator user
PQM_ADMIN -> This role is for ULB Admin user
Note: One user cannot have both these roles because flows and UI is different for these users. These roles are added in the mdms. The reference file is given below
Enhancements were made to the core module version to support some of the features in TQM UI such as help section and notification card in ULB admin's home page
The recommended core version for TQM UI is the following:
From the TQM card in the home screen, there is a link to the inbox.
Tests are created through the cronjob scheduler at the backend.
These tests created have a two-step workflow: Scheduled (initial state) -> Select Lab -> Pending Results -> Submitted (final state).
By default, tests which are in the workflow, will show up in the inbox of a plant operator. The inbox shows a list of cards corresponding to each test.
Each card contains data relevant to the test such as Test ID, Treatment Process, Stage, Output, Status, etc.
There is a dynamic action button in each card. According to the current workflow status, it will show either update status (scheduled state) or update results.
Clicking on the update status opens an update test screen which shows data about the test and a dropdown which has a list of labs configured in MDMS. A user can select one of the labs and update the test.
Clicking on update results opens an update test screen, which also shows the same test details, but the bottom card shows a list of benchmarks to be tested in that test. A user can enter these benchmarks and update the test. There is an option to upload a document as well, and at least one benchmark is mandatory to enter.
A success/failure toast is shown once the test is updated.
Filter and sort options are available in the inbox.
A user can filter by -> Treatment Process, Output Type, Date Range, Workflow Status.
A user can sort by date (latest first/latest last).
Use the pqm-service.
URL for inbox "/pqm-service/v1/_update".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_update" endpoint for a plant operator user role, that is:
Use the inbox-v2 API.
URL for inbox "/inbox/v2/_search".
Sample request object:
Role action mapping is done for the "/inbox/v2/_search" endpoint for a plant operator user role, that is:
This screen is similar to the View Past Test Results screen for a plant operator.
Refer the following page
UI for reference:
From the TQM card in the home screen, there is a link to the Inbox.
The inbox will show a list of tests that are in workflow.
Filters and search options are available such as Treatment process, Stage, Output, Status, Test Id and Plant name.
Clicking on a test will take the user to the test details screen.
Note: Unlike the plant operator inbox, this inbox is only for visibility purposes. A ULB admin cannot take any action in the tests that are in the inbox.
The test detail screen will show all the details about the test and status of the test.
When tests are in the submitted status, it's status will show as PASS or FAIL depending on the values of the benchmark.
If tests are in the workflow, it's status will show as pending.
Use inbox-v2 API.
URL for inbox "/inbox/v2/_search".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_search" and "/inbox/v2/_search" endpoint for a ULB admin user role, that is:
Use pqm-service.
URL for search "/pqm-service/v1/_search".
Sample request object:
Logging in with ULB admin role takes the user to the home page of DIGIT-UI.
If a ULB admin user is logged in, he/she will have access to TQM, and a TQM card will be visible on this screen.
Links such as Inbox, View Past Tests, and create test are available on this card.
A notification card is available on the bottom, which is specific to TQM. All the TQM-related notifications configured will show up here. Currently, it shows notifications for tests whose results are not updated on time (crossed scheduled date).
Use the egov-user-event service.
Sample request object:
The API returns a list of notifications relevant to the logged in user.
Sample curl for notifications:
The role-action mapping for /egov-user-event/v1/events/_search is added for this user that is, the ULB admin whose role code is PQM_ADMIN.
Every page in the plant operator's screen has a help button on the top right.
Clicking on it takes the user to the help screen which shows a list of videos. Each video has a title and a description.
Clicking on a video runs it in a media player.
Flows in the app can be stored in a video and it can be shown in this screen.
This page is fully configurable through MDMS.
Refer to the following MDMS file to configure the list of videos:
Multiple languages can be configured. Currently, English and Hindi are the two options available.
Sample configuration object:
The above configuration object is used to render the screen. It has a video level header and description along with URLs for Hindi and English videos. The page level header is also present.
The module name can be configured. For example, here we have added the module name as TQM.
ULB admins have an option to create a test. This is an adhoc test which does not have any workflow involved. By default, it will be in the submitted state when created.
From the home screen, click on the Add Test Result link.
The user is redirected to Create Test screen. This page has two form cards. One is for entering Plant Name, Treatment Process, Stage and output type. The other card has a list of benchmarks according to the selection of the above form.
Note: After filling the first form, only the list of benchmarks will show up.
If any quality criteria is not found for the selection of parameters, an error is shown and user has to select another criteria.
After filling the forms, click on submit to create a test.
After a successful creation, the system automatically redirects to the view test details screen of the newly-created test.
Use pqm-service.
URL for inbox "/pqm-service/v1/_create".
Sample request object:
Role-action mapping is done for the "/pqm-service/v1/_create" and "/pqm-service/v1/search" endpoint for a ULB admin user role, that is:
From the TQM card in the home screen, there is a link to "View Past Tests".
The view past tests screen will show the tests whose workflow is completed, that is, they are in the submitted status.
The screen shows a list of cards, each card corresponding to a test, and shows test details similar to inbox.
Filters and sort options are available.
User can filter by Treatment process, Output Type, Test Type and the date range.
Sort is similar to inbox.
Use the pqm-service.
URL for search "/pqm-service/v1/_search".
Sample request object:
Role-action mapping is done for the search endpoint for a plant operator user role, that is:
| Text | Type | Estimation( in hrs) | Assignee | Comments | Status | Gaps (if any) | Reviewed by Andrew |
|---|
Attribute
Type
Mandatory
Comments
Validation Required?
Treatment Process ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a process flow
N, this value should be system generated
Process Name
Text
Y
This is the commonly used identifier for the process flow
Max characters - 256
Status
Array
Y
Status of the process flow
Active/Inactive, Single Select
Treatment Process Type
Array
Y
The dropdown will be auto populated basis the list of waste maintained in the MDMS
Single Select
Treatment Process Subtype
Array
Y
The dropdown will be auto populated basis the list of waste maintained in the MDMS
Single Select
Attribute
Type
Mandatory
Comments
Validation Required?
Plant ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a plan.
Auto-generated
Plant Name
Text
Y
This is the commonly used identifier for the plant
Maximum charatcters - 128
Plant Type
Array
Y
Single select only, faecal sludge, solid waste, co-treatment
Tenant Id
Text
Y
Status
Array
Y
Status of the plant
Active/inactive, single select
Geolocation
Latitude-Longitude
Y
Capture the exact latitude-longitude
Attribute
Type
Mandatory
Comments
Validation Required?
Stage ID
Numeric
Y
Auto-generated numeric value which will act as a unique identifier for a Job ID
Auto-generated
Stage Name
Text
Y
This is the commonly-used identifier for the Job
Maximum characters - 128
Minimum xharacters - NA
Status
Boolean
Y
Status of the stage
Active/inactive, single select
Input Quality Measurement Required
Boolean
Y
This selection will allow the user to set up if the input quality for the particular input type needs to be monitored. A user should be able to enable and disable input quality measurement requirement independently for each type
Yes/no, single select
Output Type
Array
Y
The dropdown will be auto-populated basis the list of output types
Multi-select
Output Quality Measurement Required
Boolean
Y
This selection will allow the user to set up if the output quality for the particular job needs to be monitored. A user should be able to enable and disable the output quality measurement requirement independently for each type
Yes/no, single select
Attribute
Type
Mandatory
Validation
Quality Parameter
Array
Y
Selecting from the predefined of the above-mentioned quality parameters and standards.
single select
Quality Parameter Unit of Measurement
Array
Y
Selection of the unit of measurement (mg/L, Absolute value etc). Single select
Benchmark Rule
Array
Y
Options include X>=,<=R, =<Y and >=Z, single select
Benchmark Value
Numeric
Y
Entered by user, numeric only
Testing Frequency - Manual (Days)
Numeric
Y
Selecting a custom frequency range for laboratory testing based on consent to operate, numeric only
Monitoring Frequency - Quality Sensor (Days)
Numeric
N
Selecting a custom frequency
Note: Should be optional if the ULB/state choses not to have sensor-based monitoring. Numeric only
Attribute
Type
Required?
Comments
Configuration Date
Datetime
Y
Device Type
Text
Y
Selection from the device master data
[“GPS Sensor”, “pH Sensor”, “Accelerometer”, “Light Sensor”]
Plant
Text
Y
Treatment Process
Text
Y
Stage
Text
Y
Output Type
Text
Y
Parameters
Array
Y
The parameters are monitored by the device
Monitoring Frequency
Numeric
Y
Custom frequency for the device
Calibration Date
Datetime
Y
Input from the user about any change in the calibration/maintenance of the device
Calibration Accuracy
Array
Y
Range to indicate the permissible deviation in the accuracy
IsConnected?
Boolean
Y
To indicate the connectivity of the device
Connectivity History
?
Y
Date-wise device audit log to know the connectivity status
Verification History
?
Date-wise device verification log to know the days when device input was verified with laboratory results
Attribute
Type
Mandataroy
Validation
Test ID
Alphanumeric
View only
Auto-generated on the creation of schedule
Plant Name
Text
View only
Auto-populated on the creation of schedule
Treatment Process
Text
View only
Auto-populated on the creation of schedule
Treatment Process Type
Text
View only
Auto-populated on the creation of schedule
Stage
Text
View only
Auto-populated on the creation of schedule
Output Type
Text
View only
Auto-populated on the creation of schedule
Test Type
Array
Lab/IoT, auto-selected to Lab
Parameter 1…n
Text
View only
Auto-populated on the creation of schedule
Testing Date
Date
View only
Date calculated through the predefined laboratory testing schedule
SLA
Numeric
View only
Difference between the current date and testing date: The compliance to a testing schedule can be checked through this field. However, the actions based on failed/successful compliance falls under vendor management, which is not in scope currently and will be taken up separately under vendor management
Status
Text
View only
Status to be auto set to ‘Scheduled’
Attribute
Type
Required?
Comments
Test ID
Numeric
Y
Auto-generated by system
Plant Name
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Treatment Process
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Treatment Process Type
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Stage
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Output Type
Array
View only
Auto-populated on the creation of schedule, single select for on-demand test
Test Type
Array
Lab/IoT, auto-selected to lab for on demand
Lab Submitted to
Text
Y
This will not be required in case test type = IoT
Quality Parameter 1
Numeric
Y
Validation to be applied at impel
Quality Parameter 2
Numeric
Y
Validation to be applied at impel
Quality Parameter 3
Numeric
Y
Validation to be applied at impel
Quality Parameter n
Numeric
Y
Validation to be applied at impel
Collection Time
Date
Y
This is the date-time during which the user updates status to pending Results. for IoT, this is the time sensor records reading
Attachment
Document
Y
For a given collection location, photo or PDF proof of laboratory result mentioning the information of above-mentioned parameters
Attribute
Type
Required?
Comments
Alert DateTime
Datetime
Y
Auto-captured based on date-time
Alert Type
Text
Y
Auto-captured
Lab test results not as per the benchmark
Plant Name
Text
Y
Process Name
Text
Y
Process Type
Text
Y
Parameter 1…n
Text
Y
UoM
Text
Y
Benchmark
Number
Y
Results
Number
Y
Test Type
Text
Y
Auto-selected to lab/IoT, or both
Attribute
Type
Required?
Comments
Alert DateTime
Datetime
Y
Auto captured based on date-time
Alert Type
Text
Y
Auto captured
No reading received from the device
Plant Name
Text
Y
Process Name
Text
Y
Process Type
Text
Y
Device ID
Numeric
Y
Check left padding for all forms | Improvement | 1 | Done | Y |
Border colour of the view test screen | Improvement | 0.5 | Done | Y |
Result summary bold in view test screen | Improvement | 0.1 | Done | Y |
Back button and help label spacing in the help screen | Improvement | 0.1 | Done | Y |
Powered by DIGIT in sidebar at the bottom | Improvement | 0.1 | Done | Y |
Truck icon change | Improvement | 0.5 | Done | Y |
Role details: Remove colon, and values should not be bold | Improvement | 0.1 | Done | Y |
Pending tasks text color change | Improvement | 0.1 | Done | Y |
Left and right spacing of the notification cards to be equal | Improvement | 0.1 | Done | Y |
The font size for notification subheads to be checked | Improvement | 0.1 | Done | Y |
Empty state for notifications should be according to Figma | Improvement | 0.5 | Done | Y |
Once notifications are cleared for the user, it should not appear when the page is refreshed | Improvement | Backend changes required. Will be done in patch. |
View past test results to be left aligned to the icon | Improvement | 0.1 | Done | Y |
On refreshing the page, the input filtered view should remain intact | Improvement | Done | Y |
All cards and table to have 4px radius | Improvement | 0.5 | Done | Y |
Spacing between the quality testing icon and text | Improvement | 0.1 | Done | Y |
Improvement | 0.1 | Done | Y |
In some test results, the timeline connecting line is missing | Improvement | 1 | Done | Y |
Notifications cards to be responsive | Improvement | 1 | Done | Y |
Submit CTA does not work | Improvement | 1 | Done | Y |
No toast validations on submitting | Improvement | 0.5 | Done | Y |
The placement of the logout popup should be higher | Improvement | 0.5 | Done | Y |
Test date localisation missing | Improvement | 0.1 | Done | Y |
Background image to be changed | Improvement | 0.5 |
In plants dropdown, the hover states should extend to the edges | Improvement | 0.5 | Done | Y |
Inbox rows are not actionable | Improvement | 1 | Done | Y |
Alerts - heading alignment | Improvement | 0.5 | Done | Y |
Inner padding of cards | Improvement | 0.5 | Done | Y |
Share dropdown should close on clicking outside | Improvement | 0.5 | Done | Y |
Size and alignment of buttons to be fixed | Improvement | 1 | Done | Y |
Localisation missing for CTAs | Improvement | 0.5 | Done | Y |
Once filters are applied, the filters should be retained while re-opening filters as well | Enhancement | Need enhancement in core components. Will be done in patch. | TODO | Need enhancement in core components. |
Sort filters should be retained | Enhancement | Need enhancement in core components. Will be done in patch. | TODO | Need enhancement in core components. |
On sorting the date column, the filters should also change | Enhancement | Need enhancement in core components. Will be done in patch. | TODO | Need enhancement in core components. |
Filter card on the side should be sort | Enhancement | Need enhancement in core components. Will be done in patch. | TODO | Need enhancement in core components. |
Width of the column to be increased and the proportion of row height should match Figma
