egovernments / digit-core Goto Github PK

As a front-end user assigned with the admin role to add and manage master data, I must be able to search for master data.

cannot create data in mdmsv2 (mdmsV2 brach) showing error for cannot insert id null.

: the persister file for mdmsV2 has missing field id insert query.

• Get started with it and figure out the approach

Dead letter Q in Kafka and pushing the failure use cases log to Elastic Search

@hena @sathish @gajendran

• [] Will be a sub-task of the open process initiave

https://docs.google.com/document/d/1nDQ55DGdERYbAHGnxkwwHtuS46IUkvApOW1XmRS4PG0/edit#

Description

The DIGIT Design System is the foundational UI framework for a diverse range of digital products and services used by various stakeholders within the Government, Communities, and Citizens, totaling an impressive 200 million users. To ensure consistency, efficiency, and scalability across this vast ecosystem, it is essential to maintain a well-structured and comprehensive library of components. This concept note outlines an initiative to design, build, test, and publish all components, including their variants, within the DIGIT Design System.

The DIGIT Design System follows the principles of atomic design, with components organized into three key categories: atoms, molecules, and organisms. These components are extensively used across numerous products and platforms. Currently, the system comprises over 30 atoms, 20 molecules, and 10 organisms, each with multiple variants, forming the building blocks for various user interfaces.

Goals

• Consistency: Ensuring all products adhere to the DIGIT Design System, maintaining a consistent and cohesive user experience across the entire ecosystem.
• Efficiency: Providing reusable and well-documented components will expedite product development, reducing the need for custom code and development time.
• Scalability: Empowering teams to create new products with ease using pre-built components will enable the DIGIT ecosystem to scale rapidly, in line with the objectives of the DIGIT+ model, which enables building solutions and addressing different use-cases by the ecosystem partners and the community.

Expected Outcome

Availability of all components in a centralized and easily accessible Storybook / DIGIT Library and the DIGIT Design system website, facilitating exposure to the UI Building blocks of DIGIT and an opening to build new solutions on DIGIT.

Acceptance Criteria

• To be defined as per component
• Availability of Documentation
• Publishing component on Storybook/DIGTI Library

Implementation Details

The implementation will consist of the following activities:

1. Component Building:
   Design, Develop, refine, and standardize all atoms, molecules, organisms, and their respective variants as defined in the DIGIT Design System on React and Flutter.
2. Testing: Rigorously test each component for functionality, responsiveness, and accessibility to ensure a user-friendly user interface.
3. Documentation: Create detailed documentation for each component, including usage guidelines, best practices, and code examples.
4. Publication: Publish the components in a centralized and easily accessible Storybook / DIGIT Library and the DIGIT Design system website, facilitating exposure to the UI Building blocks of DIGIT and an opening to build new solutions on DIGIT.

Mockups / Wireframes

N/A

Product Name

[Product Name: DIGIT Design System

Project Name

Component Building for the DIGIT Design System

Organization Name:

eGovernments Foundation

Domain

Core Platform: DIGIT

Tech Skills Needed:

React, Flutter, Design on FIGMA

Mentor(s)

@Taherabharmal @andrew

Complexity

Medium

Category

[UI/UX/Design], [Feature], [Documentation], [Deployment], [Test], [Development]

Sub-Category

[Frontend Component Design]

Summary:

The "Open Source GIS Tool for Water Harvesting Planning in Indian Cities" aims to develop a user-friendly and accessible GIS tool to support sustainable water management in urban areas across India. The tool will empower urban planners, engineers, policymakers, and community stakeholders to identify suitable locations for water harvesting and design appropriate structures to harness rainwater effectively. By integrating geospatial data and advanced analytical capabilities, the tool will facilitate informed decision-making, optimize water harvesting strategies, and promote community participation in water conservation initiatives. Emphasizing openness, scalability, and user-centric design, the project seeks to foster collaboration, capacity building, and policy influence to address water scarcity challenges and promote resilience in Indian cities.

Goals

1. Enhancing water management in a city: Develop a tool that aids urban planners, engineers, and policymakers in identifying suitable locations for water harvesting and designing appropriate structures to optimize water resource management in Indian cities. Pick and choose one small city in India to pilot this tool. Gather all the requirements, like data satellite images, existing GIS tools for analysis etc and create a water rejuvenation plan of a city.

2. Increase sustainability in water management: Promote sustainable water management practices by facilitating the implementation of rainwater harvesting systems and other water conservation measures at the local level.

3. Improving accessibility: Ensure the tool is accessible to a wide range of stakeholders, including government agencies, municipal authorities, non-governmental organizations (NGOs), and community groups, regardless of their technical expertise or financial resources.

4. Context invariant and scalable: Design the tool to be scalable and adaptable to different urban contexts, ranging from smaller NACs to larger municipalities and across diverse geographical and climatic conditions in India.

5. User-Centric Design: Designing an intuitive and user-friendly interface that facilitates efficient decision-making and planning processes related to water harvesting.

6. Data Integration: Enable seamless integration of various geospatial datasets, including topography, land use, hydrology, drainage, percolation, lithology, lineament, watershed, slope, rainfall patterns, infrastructure networks, and population density, to provide comprehensive information for water harvesting planning and analysis.

7. GIS tool for governance in increasing the blue infrastructure at a city level. The tool gives a view of all the blue, grey, and green infrastructure, and city administrations or ward level governance can be established by using the tool to identify the appropriate zones, enhance recharging capacity, and incentivize the best locality for doing so.

Outcomes:

1. Identification of Suitable Water Recharging Zones: The GIS tool should enable users to identify potential areas for water harvesting structures/zones based on factors such as land use, terrain, slope, drainage, watershed, lineament, lithology, drainage, public infrastructure, topography, population density, and rainfall intensity, helping prioritize locations for intervention.

2. Optimized Design of Structures: Users will be able to design and optimize the layout and specifications of water harvesting structures, such as rooftop rainwater harvesting systems, check dams, percolation pits, recharge wells, drainage systems, and lakes, to maximize water yield and efficiency.

3. Risk Assessment and Mitigation: The tool will facilitate risk assessment and mitigation strategies for water harvesting projects by analyzing factors such as flood risk, groundwater contamination, and land use conflicts.

4. Decision Support: Provide decision support tools and scenario analysis capabilities to evaluate the effectiveness of different water harvesting strategies, compare alternative scenarios, and make informed decisions on investment priorities and resource allocation.

Acceptance Criteria

1. Functional GIS Tool: The GIS tool should be fully functional and capable of performing key tasks, like identifying suitable water harvesting zones and designing appropriate structures based on user inputs and geospatial data.
2. User Interface: The user interface should be intuitive, user-friendly, and accessible to users with varying levels of technical expertise. It should enable users to interact with the tool efficiently and effectively.
3. Data Integration: Relevant geospatial datasets, such as topography, land use, rainfall patterns, and hydrological data, etc should be successfully integrated into the tool to support analysis and decision-making related to water harvesting planning.
4. Accuracy and Reliability: The tool should produce accurate and reliable results, with minimal errors or discrepancies in the analysis and output generated.
5. Documentation: Comprehensive documentation, including installation instructions, user manuals, technical specifications, and data sources, should be provided to guide users in installing, configuring, and using the GIS tool effectively.
6. Testing: Thorough testing should be conducted to ensure the functionality, reliability, and usability of the GIS tool across different operating environments, datasets, and user scenarios.
7. Performance: The tool should demonstrate satisfactory performance in terms of speed, efficiency, and resource utilization, even when processing large datasets or complex analysis tasks.
8. Feedback Mechanism: Mechanisms for receiving feedback from users and stakeholders should be established to gather input on the tool's performance, usability, and effectiveness for continuous improvement.
9. Documentation of Process: The student should maintain documentation of the development process, including design decisions, challenges faced, solutions implemented, and lessons learned throughout the project.
   Out of Scope
10. Large-Scale Deployment: The project's scope may not include the deployment of the GIS tool on a large scale across multiple cities or regions.
11. Customization for Every City: Customizing the GIS tool for every Indian city or region may be out of scope. The project may focus on developing a generic tool that can be adapted or customized by users based on their specific needs and local conditions.
12. User Training
13. Policy Development: The project may not involve the development of policy frameworks, guidelines, or regulations related to water harvesting in Indian cities.
14. Long-Term Maintenance and Support: While the project may include mechanisms for receiving feedback and making iterative improvements to the GIS tool, long-term maintenance and support beyond the duration of the project may be out of scope. Although online training resources would be provided and online support community would be nurtured

Implementation Details:

1. Requirement Gathering and Analysis:

User Requirements Analysis:

• Scope out the requirements
• Document functional and non-functional requirements.

Data Collection and Analysis:

• Identify relevant geospatial data sources, such as topography, land use, rainfall, watersheds, infrastructure, etc that are relevant for identification of water harvesting zones.
• Assess the quality, availability, and compatibility of data

Design Specification:

• Develop a design specification document outlining system architecture, data models, and user interface design.

2. Development

Prototype Development:

• Develop a prototype of the GIS tool, focusing on core functionalities.
• Implement basic features for data visualization, spatial analysis, and user interaction.

Data Integration:

• Integrate geospatial datasets into the GIS tool using appropriate data formats and protocols.
• Develop data processing pipelines for data cleaning and analysis.

Algorithm Development:

• Develop algorithms for identifying water harvesting zones and designing appropriate structures based on spatial analysis techniques.

3. Testing and Validating:

Unit Testing:

• Conduct unit tests to validate individual components and functionalities of the GIS tool.
• Integration Testing:
• Test the integration of different modules and components to ensure interoperability and consistency.

User Acceptance Testing (UAT):

• Engage stakeholders and end-users to conduct UAT sessions to validate the tool's usability and functionality.

4. Performance evaluation and Analysis report

Performance evaluation:

• Evaluate the performance of the GIS tool in terms of speed, accuracy, and efficiency.
• Benchmark against existing tools or methods for water harvesting planning.

Analysis report

• Analyse and publish the report of identifying water rejuvenation zones in a small city in India

Mockups / Wireframes
……………………………………

Product Name
DIGIT

Project Name
Open source GIS tool for planning of water harvesting zones and appropriate structures in Indian cities

Organization Name:
eGovernments Foundation

Domain
Public Services

Tech Skills Needed:
Creative and Innovative mindset
Proficient knowledge of Geographic Information Systems (GIS)
Programming Languages Python, JavaScript/Java
Spatial Database Management like PostGIS, SQLite etc
Data Integration and Analysis
UI/UX design skills for creating user-friendly interfaces
Documentation, Communication
Scalability and Performance Optimization
Security and Privacy Considerations

Mentor(s)
Aniket Talele

Complexity
High

Category
Feature

Sub Category
API, Frontend, Backend

• List existing and propose a structure
• Go forward strategy to create repo,Naming convension
• Migration strategy fro ext to new

DIGIT is an open source service delivery platform on which several government and private sector organisations build solutions e.g. National Urban Digital Mission leverages DIGIT for National Urban Governance Platform (UPYOG) - 28+ States have signed up to roll out UPYOG to all their urban local bodies. This will help deliver services like Property Tax, Public Grievances, Water Connection, Birth/Death Certificate etc. to all citizens.

DIGIT platform has multiple core microservices, where each microservice provides a specific functionality like authentication, authorisation, encryption, workflow etc. Service delivery applications like property tax, trade license etc. are built on top of this DIGIT platform. They internally call these core microservices to utilise the functionality provided by them. DIGIT uses zuul as the API gateway. All the request coming to the backend server passes through this gateway. It provides a centralised way of authentication and authorisation of API calls. This removes the need for each microservice to implement their own authentication and authorisation mechanism. Currently DIGIT has a stateful authentication mechanism in which the access tokens are generated and stored in Redis database. Whenever authentication request is received by the service, it checks in the Redis DB if the token is available in the Redis database. For any authentication request, a call needs to be made to the authentication server. This will have an impact on the performance and scalability.

JWTs are stateless, meaning that the server doesn't need to store any information about the token itself. This can be an advantage in terms of scalability and performance, as there is no need for the server to maintain any session state for the client. It also provides a decentralized mechanism of authentication and authorization, allowing for the authentication and authorization of requests across different systems and services without requiring a centralized authentication and authorization service.

For further reference to current DIGIT authentication and authorisation service please refer the following documentation:
Authentication
Authorization

Features to be implemented:

1. Integration of JWT-based authentication and authorisation mechanism with the existing DIGIT platform.
2. Development of a scalable and performant JWT token generation and verification mechanism using public and private key encryption.
3. Integration of the new JWT-based authentication and authorisation mechanism with the existing API gateway: Zuul.
4. Development of a client utility which can do authentication and authorisation of the JWT tokens. The utility can be used
   by third party applications to using DIGIT authentication and authorisation.
5. Implementation of multi-factor authentication (MFA) to provide an additional layer of security for user accounts.(Optional)

Learning Path:

1. Understanding the basics of JWT-based authentication and authorisation mechanism and its advantages over stateful authentication mechanisms.
2. Learning how to use open source JWT libraries and tools like JJWT, Nimbus JOSE + JWT, Auth0 JWT, etc. to generate and verify JWT tokens.
3. Understanding the key concepts of public and private key encryption and how to use them to secure JWT tokens.
4. Learning how to integrate JWT-based authentication and authorisation with existing microservices and API gateway using Zuul.
5. Learning how to implement MFA for user accounts using open-source libraries like Google Authenticator. (Optional)

Product Set Up:

1. Setting up a development environment with the required tools and libraries like Java, Spring Boot, Redis, JWT libraries, etc.
2. Setting up the few core services of DIGIT like zuul and egov-user locally for testing and development purposes.
3. Configuring the development environment with appropriate secrets, keys, and environment variables for secure JWT token generation and verification.

Acceptance Criteria:

1. Successful integration of the JWT-based authentication and authorisation mechanism with the DIGIT platform
2. Implementation of a scalable and performant JWT token generation and verification mechanism using public and private key encryption.
3. Development of a client library for user authentication and authorisation
4. Implementation of multi-factor authentication (MFA) for user accounts to provide an additional layer of security. (Not mandatory)

• Enable more focused training content/Course Structure
• Assessment
• Certification
• Internal enablement
• Mandating Partners/External certification

@chandar

• Write up a note (Considerations, How to Contribute, documentation)
• What steps for next 1 years, evangelize (5 step theory), internalize
• Invite Volunteers
• Open up the existing tool stack/session to the intended audience

@gajendran

• Jira => Public => Enable/manage comment, PRD Confluence => GitBook Demo
• POV on Multi=> SingleSource
• Induction to new joiners on the tools

Oct4 Update
Chandar is running it

• 1st round of meeting happened, next level action items will be planned this Week.
• Need to create action items in coming weeks
• End of qtr 3 we should be able to work on parallel/multiple Sprint teams
• From Q4 we'll do the planning as part of the regular engineering process instead of doing it once in qtr.
• Key outcome was to work on capacity building
• Weekly meetings to assess the progress and make it as part of main stream work
• To make the sprint releasable, but we are not there yet.
• We need to Perf as part the release,nightly builds, etc.

https://docs.google.com/document/d/1nDQ55DGdERYbAHGnxkwwHtuS46IUkvApOW1XmRS4PG0/edit#

Discussed in #45

• Anikit to get started with how are we going to do this.

@Anikith

• Implement SMS Delivery and Bounce report.

@chandar

• Create Low/No code framework as part of DIGIT v3.0
• Define low hanging items to start with

@manish

• [x ] To add more notes and strategy

Initial Note on Low Code No Code
https://docs.google.com/document/d/1PKk2hBeyPD0bUqr66Bp3D1iBlw_S3nA2QghKZx-aJbQ/edit?usp=sharing

Initiated, and the initial discussion has happened with shashwat, manish will further update the progress

As a front-end user assigned with the admin role, I must be able to view the master data.

eGov is building an open source Health Campaign Management product that will enable the government to run health campaigns like the distribution of BedNet, vaccines, etc. The health campaign front-line app developed on Flutter is a key component and will be used by healthcare workers to deliver health interventions across the country in remote areas. The app has offline support as it is supposed to work even in areas where there is no mobile connectivity. the health worker is supposed to come to the health Center to pick up the device. They log in and select the area they are assigned to. The required master data is uploaded into the app and stored locally for offline access. The worker goes to remote villages and adds household and individual data. Then captures delivery data e.g. how many BedNet have been given. Even if the user comes into areas with connectivity - data is automatically synched into the backend server.

As this is a critical component and key to the success of campaign delivery - we are calling for volunteers with Flutter expertise to review the code and provide their feedback.

• What is our definition of Privacy? https://core.digit.org/focus-areas/privacy
• Platform Enhancement
• W&S Exemplar
• R&D - Consent Management

Discussed in #161

Background:

A robust and sustainable sanitation system is an essential aspect of urban and development planning. This is why the importance of Sustainable Development Goal 6 (SDG 6), which ensures Clean Water and Sanitation for all, is emphasized: it affects the outcome of other SDGs like eradicating poverty and hunger, ensuring well-being and gender equality, creating sustainable communities, protecting life on land and on water, etc. Inadequate sanitation management creates repercussions for overall social well-being and progress, with  adverse environmental, economic and health impacts. 

Because of this, there are many global strategies and treatment options for wastewater management and solid waste management. However, one waste stream that is not adequately managed in developing countries is faecal sludge (FS) — the by-product of on-site sanitation systems (OSS). OSS systems accumulate and store faecal matter over 3-5 years, as opposed to sewer systems, which allow the continuous transport of faecal matter with used water.  Once the OSS storage is full, the waste is emptied and transported to the treatment plant through vacuum trucks. The end-to-end value chain of safe storage, collection, transport, treatment, and reuse or disposal of faecal matter is called Fecal Sludge and Septage management (FSSM).

India’s FSSM ecosystem is made of highly interdependent parts, across the value chain of generation, containment, transport, treatment, and disposal/reuse. This means that there are different actors at each stage of the value chain whose behaviors and business models affect how well the next stage functions, creating a complex mesh of constraints that affect the effective functioning of sanitation service delivery. 

While the linear value chain gives a lucid frame to understand the ideal flow of faecal sludge, there are various points of friction between stakeholders that currently undermine the effectiveness of the sanitation value chain.

Illegal dumping continues to remain a paramount challenge in regards to the waste value chain. Multiple factors contribute to these which include: 

1. No incentives for Citizens to use digital platforms provided by the government: Desludging is usually performed once is 7 years as per the baseline M&E (Measurement and evaluation) study conducted in Orissa and is requested by the citizen when either the tank overflows or there is leakage. In this scenario, it is usually an activity that needs to be performed on an immediate basis. Co-ordinating with the ULB to request for these service, awaiting the assignment of a vendor and then co-ordination with the vendor for the services is a time consuming process. Hence, citizens usually prefer to reach out to vendors directly. When desludging services are provided outside the system, there is no way to track where collected sludge is being disposed.
   
   

2. No incentive for Vendors to use digital platforms provided by the government:  The usual practice in regards to availing desludging service is to directly contact vendors providing these service. While DIGIT Sanitation is built as a platform to address the challenge of broken custody of waste across various stakeholders, there is no incentive for vendors to use the platform. Hence, a large number of desludging services are provided outside the platform and there is no way to track process compliance or disposal against these services.
   
   

3. Lack of incentives to dispose fecal sludge at the Treatment Plant: Treatment Plants/Decanting stations for fecal sludge are usually located at a significant distance from the ULB/Village. Given that payment is usually collected from the citizen at the point of desludging, Vendors involved in the transportation of Fecal sludge do not have incentives to dispose at the Fecal Sludge Treatment Plant/Septage Treatment Plant.
   
   

4. Profitability of Vendors providing desludging services: Various business models exist for provision of desludging services (collection and transportation of fecal sludge from the point of generation to point of treatment). In some cases, the Urban Local Body owns and operates a list of vehicles for desludging. However, across the globe, the market is largely dominated by private players who own vehicles of various capacities (1000L, 2000L, 5000L etc)  provide desludging services - and also define the pricing for each of these vehicles. Since the volume of transactions is low, and the distance to be travelled to dispose of fecal sludge at a Treatment Plant is high, profitability of vendors is a concern.
   
   

5. No traceability of vehicle trips: Governing bodies, usually have no traceability of vehicle trips due to absence of real-time tracking, both trips happening within the system or outside.  If informed in time about potential illegal dumping, local authorities can take impromptu action to stop the disposal and/or preventive measures to avoid the incidents in future. Transactional data on trips can help governing bodies identify vendors/vehicles participating in illegal dumping and common spots for illegal dumping.
   
   

To address some of these challenges, we are looking to enhance DIGIT Sanitation with the following: 

1. Discovery and Automated assignment of requests

1. Discovery of service vendors within a particular location boundary by citizens/ULB employees basis proximity from current location, availability and size of vehicle

2. Automated assignment of service vendors basis their distance from current location, availability and size of vehicle

3. Rejection and reassignment of requests in case of non-response/feedback from citizen/non-acceptance by vendor.
   
   

2. Define pricing for services

1. Build a pricing model that lets the vendors set the pricing based on all available factors (Factors could be size of vehicle, location of property, time of the day etc)

2. Allow ULB to define floor and ceiling prices.

3. Provide subsidies for particular localities/geographic boundaries/property types, at the admin level. These can be built into the system by availability of rebates/discounts
   
   

OPTIONAL

3.  Dynamic Pricing Calculator

1. Build a pricing model that calculates the price of a transportation service based on different trip related parameters such as distance, waiting time, trip time, surge in demand

2. Allow for governments to provide subsidies for particular localities/geographic boundaries/property types. These can be built into the system by availability of rebates/discounts.
   
   

4. Payment linked to disposal

1. Interface for vendors to collect and record payment from citizen on sludge pickup 

2. Total Payment disbursal (100% of revenue from trips) to be calculated only for trips completed.
   
   

5. Async coordination between parties

1. People requesting services should have the option to add current location or other locations based on the search option from Maps.

2. End location should be auto defined basis plants mapped in the region.

3. Location and route to pick up and disposal should be visible to the vendor.

6. Capturing Vehicle movement

1. Identification of longer waiting time of vehicles away from pick up and disposal sites  - this could be a possible indication of the illegal disposal (define rules). Real-time alerts to vendor/ULB in such cases.

2. The popular open disposal spots to be defined as prohibited zones and any desludging vehicles around those areas are an indication of open disposal. Real-time alerts to vendor/ULB in such cases. (Optional: Overtime, suggestions by the system to identify prohibited zones basis transactional data)

3. Capturing ULB feedback basis alerts to track action against alerts and capture whether the alert is true or false. 

4. Closure of service request only upon entry at Decanting/Treatment site (Geo-fencing)

5. Tracking of trips by citizen, ULB and vendor for ongoing trips of vehicles

6. Track all trucks in fleet for ULB and Vendor (Idle, Collecting, Disposing)

7. Track movement of vehicles even beyond applications being serviced via the platform. 

7. Collection of transportation related data against a vehicle

1. Time for pickup

2. Time for disposal

3. Total time taken

4. Distance travelled

5. Idle times 

The above list is indicative only, and participants may define additional enhancements basis understanding of challenges and potential solutions.

A successful solution would consist of the following: 

Cost:

1. No vendor lock-in

Technology Principles:

1. Built as an enhancement to DIGIT Sanitation

2. The ability to exchange information with  existing digital solutions/DPIs implemented — this should accelerate information sharing and increase visibility. 

3. The solution should adhere to OpenAPI and Open Spec standards. 

4. Ensure data security and privacy

5. Ensure inclusiveness through design (multi-channel availability, language localization, etc)

6. Ensure ease of deployment, development and operations keeping State Capacity in mind 

7. Specific capabilities within the solution should be usable independently

Completeness

1. Demonstrate a working model

Key principles to keep in mind:

2. Comfort of Vendors and Citizens to use using digital applications is low. It is imperative, hence, that it is designed for ease of use, with a need to enter minimum data. 

3. The above is applicable for employees of the Urban Local bodies/panchayat responsible.

4. For governing authorities, it im important that data is presented in a format that is both easily consumable and provides the ability to ask questions and drill down on the data. A visual representation of the data is the best way to drive this. 

5. While the initial inclination is to keep collecting as much information as possible, it is important to distinguish between what is absolutely necessary and what may be good to have. 

Learning Path

2. Digit Flutter Components: Digit Components

3.React Native: https://reactnative.dev/

4. core Services: https://core.digit.org/

Acceptance Criteria :

1. Connectivity

• System should function on low bandwidth internet

2. All information to be collected by use of mobile devices (GPS)

3. Access of information via open APIs

4. Mobile based UI layer for the following:

• Citizen requesting services

• Vendors and drivers performing desludging requests

5. Enhancement of ULB interface to

• governing operations
• Dashboards and Reports
• Interactive dashboards for real-time and trend analysis
• Ability to download data and reports in Excel and pdf format.

6. Application should work on cross platform (Android/IOS)

Support 

Tech : [email protected] , [email protected]

Product:  [email protected]

Description

In light of the digital transformation of public services, this project endeavours to create a UI component tailored for Flutter applications. The main objective is to address the challenge faced by many citizens in completing digital forms by developing a voice-based form-filling solution. This component, when integrated into a Flutter form, will automatically extract existing form elements and conversationally engage users to facilitate form completion. By offering a generic voice-based form-filling capability, the project aims to significantly enhance the user experience of Flutter-based apps. Given the increasing popularity of Flutter for building mobile applications used by citizens and frontline workers, such innovation has the potential to streamline interactions with digital services and improve accessibility for all users.

Goals

Design and develop a voice-based form-filling component specifically tailored for Flutter applications on DIGIT.
Create a conversational interface that engages users to facilitate form completion using voice commands.
The interface should allow the user to hear as well as see the voice prompts and recorded responses.

Expected Outcome

• Design and build UI elements to activate voice based form filling
• Implement logic to extract existing form elements from Flutter forms and dynamically generate conversational prompts for users.
• Design and build of Interface where users can see written versions of the voice prompts and recorded responses. Interface should provide feedback to users during the form-filling process, including confirmation messages, error notifications, and prompts for clarification.
• Design and build of a backend service or API that can process speech input and convert it into text. This could involve utilizing existing speech recognition APIs (must be open source)
• Integration/build of LLM to understand and interpret user’s input -Acceess to Open AI or alternate LLM can be provided
• Thorough testing and debugging to ensure reliability, accuracy, and performance of the component across different devices and platforms.
• Optimization of the frontend code for efficiency, minimizing resource usage and maximizing responsiveness during voice interactions.

Acceptance Criteria

Voice-Based Form-Filling Component Development:

• The voice-based form-filling component must be designed and developed
• The component should work on Flutter applications on DIGIT.
• The component should seamlessly integrate into existing Flutter forms, allowing users to interact with forms using voice commands.
• Users should be able to activate the voice-based form-filling feature through a designated UI element.

Conversational Interface:

• The component must feature a conversational interface that engages users during the form-filling process.
• Users should be provided with clear and concise voice prompts to guide them through the form completion process.
• The interface must allow users to both hear and see the voice prompts and recorded responses.

Form Element Extraction and Dynamic Prompt Generation:

• The component should automatically extract existing form elements from Flutter forms.
• Dynamic conversational prompts must be generated based on the extracted form elements to facilitate user interaction.

User Interface Design:

• A user interface must be designed and built to display written versions of the voice prompts and recorded responses.
• The interface should provide feedback to users during the form-filling process, including confirmation messages, error notifications, and prompts for clarification.

Backend Speech Processing Service:

• A backend service or API must be implemented to process speech input and convert it into text.
• The backend service/API should utilize open-source speech recognition APIs to achieve speech-to-text conversion.

Integration with NLP Service:

• Integration with an NLP service or API is required to understand and interpret user input.
• The NLP service/API must be capable of analyzing user utterances and extracting relevant intents and entities.

Thorough Testing and Debugging:

• Comprehensive testing must be conducted to ensure the reliability, accuracy, and performance of the voice-based form-filling component.
• Testing should cover different devices, platforms, and scenarios to identify and address any issues or bugs.

Frontend Optimization:

• The frontend code must be optimized for efficiency to minimize resource usage and maximize responsiveness during voice interactions.
• Measures should be taken to ensure smooth performance across various devices and screen sizes.

Out of Scope:

• The component should be able to identify the selected language of the user and provide voice prompts accordingly

Implementation Details

• Libraries/3rd Party tools may be used but must be open-source
• DIGIT uses Java Spring Boot in the backend and Flutter for the frontend for mobile applications
• Staging environment of DIGIT will be provided and an existing form from a product may be used.

Mockups / Wireframes

• To be created by the selected contributor with support from DIGIT product manager

Product Name
DIGIT

Project Name
Voice-Based Form Filling Component for Flutter

Organization Name:
eGovernments Foundation

Domain
Public Services

Tech Skills Needed:
Flutter, Java Spring Boot

Mentor(s)
Ramkrishna Sahoo

Complexity
High

Category
Feature

Sub Category
API, Frontend, Backend, LLM

As a front-end user assigned with the admin role to add and manage master data, I must be able to view all the masters that I can add, view and update.

Once there is a update of version kept in MDMS app should force the user to update the latest Version

https://github.com/egovernments/health-campaign-field-worker-app

filters in mdmsv2 search only taking string fields.

suggested edit:-
change the type of filters from Hashmap<String, String> to Hashmap<String, Object>.

DIGIT is an open source service delivery platform on which several government and private sector organisations build solutions e.g. National Urban Digital Mission leverages DIGIT for National Urban Governance Platform (UPYOG) - 28+ States have signed up to roll out UPYOG to all their urban local bodies. This will help deliver services like Property Tax, Public Grievances, Water DIGIT is an open source service delivery platform on which several government and private sector organisations build solutions e.g. National Urban Digital Mission leverages DIGIT for National Urban Governance Platform (UPYOG) - 28+ States have signed up to roll out UPYOG to all their urban local bodies. This will help deliver services like Property Tax, Public Grievances, Water Connection, Birth/Death Certificate etc. to all citizens. Odisha is rolling out Sanitation Services built on DIGIT across all their urban local bodies. Punjab is rolling out Revenue and Expenditure Management System on DIGIT for all rural drinking water projects.

DIGIT Core consists of 25+ microservices. One of the microservices MDMS helps manage master data that are used by services built on DIGIT. Currently the master data is stored as JSON files in GitHub. This makes it difficult for business users to update master data. This project is to design an upgrade for MDMS to make it easily configurable.

Features to be implemented -

1. MDMS management service: _create API.
2. MDMS management service: _search API.
3. MDMS management service: _update API.
4. MDMS management service: _delete API (soft delete).
5. In MDMS we have data with different Master data. Each master will have a specific JSON schema.
6. There will be a schema validator that will validator data in create and update operations based on the Master name.
7. This schema validator should validate based on the Master, if any master data don't have a defined schema, or it want's to skip the validation that can also be possible.
8. There will be one table that will store all MDMS data with the help of jsonb and some other following details -
   . Each record will have three mandatory fields tenantId, moduleName and masterName.
   . For one master there can have multiple records, for different modules and tenants.
9. There will be fallback and other search functionalities same as we have in existing MDMS.
10. All defined schema will be loaded when service initializing.
11. Will use caching or other mechanisms to improve search performance.

Learning path, project setup and development details -

DIGIT Platform - Principles, Architecture, Technology, Specifications etc.
DIGIT Developer's Guide - Local Setup, Project Setup, Integration with Core Services etc.
API Do's and Don'ts

Acceptance Criteria -

All APIs of Performance management service should be functional.
The code should be modular with proper separation of concerns and compliant with the code quality we maintain in DIGIT.
All queries to extract performance metrics should return correct data for the selected timeframe.

@vidya to add a note
@manish will circulate a detailed presentation

Started with it, anikit is working on it, as we progress we'll update the status here

Background

DIGIT has the capability of role-based workflow mapping using which workflows can be defined in the system based on role mapping that controls which users can take which actions based on a role assigned to them. Also, each employee can be mapped to a defined jurisdiction in the system. But while the concept of jurisdiction exists in the system, the system lacks the ability to associate workflow events and role mapping with jurisdiction in tandem. As a result, it is not possible to define automatic workflow events in the system based on jurisdiction. This delays service delivery beyond the desired SLA since time is lost in assigning the right person to deal with the issue. The request keeps sitting in the inbox for many days until someone manually picks up the request relevant to them.

What is the feature
Ability to associate service requests to relevant employees based on jurisdiction

Preliminary Requirements - Open to Inputs
Here is an initial list. Please suggest further requirements in the comments.

1. Route applications based on jurisdiction- Redirect service requests to the relevant employee using the association with jurisdiction.
2. Manual assignment made easy - Show relevant users based on jurisdiction, if someone is doing the assignment manually.
3. Jurisdiction-based access - Permit CRUD on application only for a specific ‘User’ based on the association to a Jurisdiction.
4. Restrict CRUD operations on the applications for other users of the same role - If there are two users of the same role in different jurisdictions - User A in Jurisdiction X and User B in Jurisdiction Y both have the same role Z, they should only have access to applications that are relevant to their jurisdiction.

Detailed description of the problem:
Service delivery is delayed because all assignment currently happens manually. The system lacks the required rules to decide which application belongs to which employee.

Let’s say once a citizen creates an application. Based on the workflow, the application will be made visible to users of a certain role.
This is where the problem happens because all users of a certain role will be looking at all the applications at once. This creates a huge problem in cases where hundreds of applications come in on a daily basis.

The following cases illustrate the problem as experienced in different solutions:

• Case 1 - Public Grievance Redressal: All complaints are directed to one person. This person redirects the complaints manually to the relevant employees. The system currently shows all employees in the drop-down and as the assigner, I have to go through a long list to find the right employee for the application.

• Case 2 - OBPAS, TL: Every application is visible to multiple employees of the same role. These employees have to search for the applications from the common pool rather than the system only showing them the applications relevant to them.

Information for Reference
Here is a quick description of a few terms mentioned in the discussion.

1. Role mapping is a mapping of a role to a set of actions in the system. It helps define and manage user access by associating users with a certain role.

2. Workflow is a state machine that allows the transition of service requests (or any entities in general) from one state to another. A state change could be the assignment of the service request to a particular person or a change of the status of the application from open to closed or from open to rejected.

3. Jurisdiction is a hierarchical data structure that can be defined by master data management. For example, a city can have multiple circles which can have multiple wards. Depending on the city, the terms ‘circle’ and ‘ward’ can have different names. For example - these wards or circles are related to actual areas like Koramangala, Whitefield, and Bellandur as in the case of Bangalore.

Learning Path:

Learning how to integrate workflow configuration for different heirachy. These are general concepts across domains.

Complexity
Medium

Skills Required
Java, Spring Boot, Redis

Name of Mentors:
[email protected]

Project size
8 Weeks

Product Set-Up:

Setting up a development environment with the required tools and libraries like Java, Spring Boot, Redis, etc.
Setting up the few core services of DIGIT like zuul and ego-user locally for testing and development purposes.
Configuring the development environment with appropriate secrets, keys, and environment variables for secure JWT token generation and verification.
Refer : Developer Guide

Acceptance Criteria:

Successful integration of the Jurisdiction based workflow with the DIGIT platform

**For further information: **

• Documentation- Workflow, Access Control

• Code - Workflow, Access Control

• Visit and search: core.digit.org

• Mail - [email protected], [email protected]

Doc Link:

https://core.digit.org/focus-areas/data-security/signed-data-audit

• We need to find to separate the Core from the existing DIGIT stack, Identify the services, etc.
• Prod track for Core and other streams
• [ ]

Primarily Ghanshyam would be working on it with Manish

• #6
• Categorize the Test suites and publish as part of Test coverage for every release
• Create a test framework to Leverage across products and shorter vs big releases

Integration Test Suite

• Security
• Performance
• Functional Automation

What we are toding today:

• DIGIT 40+ APIs
• https://docs.digit.org/configuration/configure-digit/qa-automation/
• v2.5 Just started with the basic perf testing (Shanmugam)

Whats next:

• Automation Documentation @sathishp-eGov
• Defect Analysis Report/Dashboard @sathishp-eGov
• Test Strategy @sathishp-eGov
• Catch up on the Pod/Service level load/perf bench marking @sathishp-eGov

@elzanmathew-eGov

• Fine-tune further
• First time run in v2.5

@egovjojomehra

• Quality of Testing

Yet to start, will continue focusing this week and update further

Hi Team,

We have successfully deployed the Digit platform version 2.4 (pgr) without any errors on the AWS Kubernetes cluster which we have created using the document guide from the docs.digit.org website.

After deploying we could note that most of the services int he egov name space are not in a running state and screenshot of the same is posted below.

Request your help in getting the services up and running.

Overview

DIGIT is a service delivery platform that enables government employees to deliver services to citizens. DIGIT powers 1000+ urban local bodies and is being rolled out to 4300+ urban local bodies as part of National Urban Digital Mission. The objective of this project is to enhance DIGIT to enable data driven performance of government employees. The existing DIGIT platform already has the ability to manage employees, their roles ( system roles - Birth Certificate Creator, Birth Certificate Approver etc.) and their jurisdiction (e.g. Jalandhar, Punjab etc.). This project involves developing a Performance Management service which can be used to set goals (create/search/update/delete) for each employee and generate performance report for a given period from the system.

For each performance cycle, the system should generate the rating based on the service data, allow the employee to give rating and comment, and submit the performance appraisal to the manager. The workflow for performance appraisal should be configurable. Performance management dashboard should be provided to track the performance appraisal process. Appraiser should also be able to suggest training for the appraisee. List of training courses can be maintained in the system.

Features to be implemented -

1. Performance management service: _create API.
2. Performance management service: _search API.
3. Performance management service: _update API.
4. Performance management service: _delete API (soft delete).
5. Integration of performance management service with DIGIT workflow service.
6. Integration of performance management service with DIGIT persister and indexer services to persist performance related data in relational and analytical databases respectively.
7. Configuring a dashboard on top of the data present in analytical database and creating queries to track the following performance metrics -
   a. Number of Services Processed by the Employee.
   b. Number of Services Processed Successful by the Employee.
   c. Number of Services Processed Successful within SLA and outside SLA by the Employee.
   d. Total Revenue Achieved by the Employee (if the service has revenue generation element).
   e. Average Feedback by Citizen for the Process in which the Employee was part of.

Learning path, project setup and development details -

1. DIGIT Platform - Principles, Architecture, Technology, Specifications etc.
2. DIGIT Developer's Guide - Local Setup, Project Setup, Integration with Core Services etc.
3. API Do's and Don'ts

Acceptance Criteria -

1. All APIs of Performance management service should be functional.
2. The code should be modular with proper separation of concerns and compliant with the code quality we maintain in DIGIT.
3. All queries to extract performance metrics should return correct data for the selected timeframe.

Description
The purpose of this requirement document is to outline the specifications and acceptance criteria for building an AI image recognition feature for no. plate of sanitation vehicles on the DIGIT Sanitation platform. The feature aims to enhance the verification process of vehicle number plates entered manually by introducing a photo upload functionality for verification purposes. The AI image recognition algorithm will capture the detected number from the uploaded image, ensuring accurate and reliable verification.

Actors in DIGIT Sanitation FSM:-

1. Citizen: Requests septic tank desludging services and receives notifications related to waste management.
2. Sanitation Worker: Responsible for performing waste management tasks safely and efficiently.
3. ULB Employee: Manages service requests and maintains citizen information for efficient service delivery.
4. Waste Management Vendors/Desludging Operators: Assign tools and services for effective waste management.
5. Feacal Sludge/Co-treatment Plant/Centre Operator: Oversees waste treatment, adherence to schedules, and treatment quality.
6. Administrators: Govern the waste management value chain and monitor compliance.

Goals
DIGIT FSM is an open-source platform designed to digitize waste management operations. The platform facilitates coordination among stakeholders, ensuring transparency and accountability in the waste management value chain. The proposed feature focuses on improving the verification process for vehicles arriving at the Fecal Sludge Treatment Plant (FSTP), particularly against those coming in without corresponding requests.

Actors:

1. Image Recognition Accuracy:
   a. The AI image recognition algorithm should achieve a minimum accuracy rate of 95% in detecting the vehicle number from the uploaded photo.
2. Integration and Data Handling:
   a. The image recognition feature should seamlessly integrate with the existing FSM platform.
   b. Uploaded images should be securely processed and stored, following best practices for data privacy and protection.
3. Performance and Response Time:
   a. The feature should deliver prompt results, providing real-time verification feedback to users.
   b. The system should handle a significant volume of image recognition requests efficiently.
4. Error Handling:
   a. Proper error messages should be displayed if the image recognition process fails or encounters any issues.
   b. Users should be able to retry the verification process if necessary.

Expected Outcome
To address the problem, we propose implementing an AI image recognition feature for vehicle number plate verification. The feature will require users to upload a photo of the vehicle number plate. The system will detect the vehicle number from the uploaded image. The user can edit this if there is a gap.

Acceptance Criteria

1. The AI image recognition algorithm achieves an accuracy rate of at least 95% in detecting vehicle numbers from the uploaded images.
2. The feature integrates seamlessly with the existing FSM platform, ensuring smooth workflow and data handling.
3. The verification process provides real-time results, promptly notifying users of the verification status.

Implementation Details
Currently, vehicles arriving at the FSTP without corresponding applications in the system can enter dummy vehicle numbers to receive payment. There is no robust verification process to ensure the accuracy or existence of the entered vehicle numbers.

Mockups / Wireframes
[Include links to any visual aids, mockups, wireframes, or diagrams that help illustrate what the final product should look like. This is not always necessary, but can be very helpful in many cases.]
[Please note that the below section of the ticket has to be in the format as mentioned as it is key to enabling proper listing of the project. Please only choose the options mentioned under the headings wherever applicable.]

Product Name
DIGIT Sanitation

Project Name
AI Image Recognition for Vehicle Number Plate Verification

Organization Name:
eGov Foundation

Domain
DIGIT Sanitation

Tech Skills Needed:
Python Libraries

Mentor(s)
Tahera

Complexity
[Medium]

Category
[CI/CD], [Integrations], [Performance Improvement], [Security], [UI/UX/Design], [Bug], [Feature], [Documentation], [Deployment], [Test], [PoC]

Sub Category
Pick one or more of [API], [Database], [Analytics], [Refactoring], [Data Science], [Machine Learning], [Accessibility], [Internationalization], [Localization], [Frontend], [Backend], [Mobile], [SEO], [Configuration], [Deprecation], [Breaking Change], [Maintenance], [Support], [Question], [Technical Debt], [Beginner friendly], [Research], [Reproducible], [Needs Reproduction].

https://sanitation.digit.org/products/faecal-sludge-management-fsm/fsm-user-manual/septage-treatment-plant-operator-user-manual
https://sanitation.digit.org/
https://sanitation.digit.org/platform
https://sanitation.digit.org/platform/architecture
https://sanitation.digit.org/products/faecal-sludge-management-fsm/fsm-core-service-configuration/fsm-dss-technical-documentation

Today

• When we are already agile why are we not able to release after every sprint
• 1 Week Planning, Dev 3 Weeks, QA + UAT 4 weeks, 1 Week Documentation

Proposed Approach:

• Need to come up with the Agile process and sprint length that works
• Need to align the process to release after every sprint
• Come up with the work plan

Regroup with the detailed planning and approach (@chandar, @sathish, @manish, @jojo, @gajendran)

This will be tracked as part of the Open Process initiative.

https://docs.google.com/document/d/1nDQ55DGdERYbAHGnxkwwHtuS46IUkvApOW1XmRS4PG0/edit#

• Sarvesh is doing a POC on mapping with the PT and WS.
• Initial POC is done and handed over to the Product and Punjab team.

Build an app using Java ME that works on a feature phone. The app retrieves an ASCII based QR Code by calling a backend service and displays a QR Code on the screen of the feature phone.

Description:

Recognizing the discomfort some users face with digital tools, this project aims to develop a Flutter-based UI component tailored to streamline form submission processes. The core concept involves generating a printable form with a unique QR code assigned to each form instance. Users can then fill out the printed form manually and scan the QR code using the associated Flutter app. Upon scanning, the app automatically retrieves the corresponding form, populates the fields with the user-entered data, and presents it for review and submission. By integrating QR code technology with Flutter-based applications, this component seeks to bridge the gap between traditional paper-based interactions and digital platforms, making form submission more accessible and user-friendly for all individuals.

Goals

• Implement QR code generation functionality so each form can be associated with a unique QR Code
• Automated generation of PDF format of form that may be printed by users. The PDF should contain the unique QR Code.
• Implement QR code scanning capability within the Flutter App
• Integrate QR code scanning with form retrieval and data population.

Expected Outcome

• Design and implement user-friendly screens/end points and interactions within the Flutter framework to scan QR codes. Implement QR code scanning functionality using the device's camera, allowing users to scan printed forms.
• Use DIGIT’s QR Code functionality for generating unique QR codes within the Flutter app.
• Design and build UI components to automatically convert flutter forms into printable PDF Forms. All validations for the fields to be printed as part of the pdf form to guide users to fill the form effectively.
• User should be able to view scanned data in a filled form and make edits where necessary
• Errors should be highlighted once data is scanned
• Develop logic to populate form fields with data retrieved from scanned forms. Implement mechanisms to match filled data to master data in forms. Ensure proper mapping of data to corresponding fields in the form UI.
• Provide clear feedback to users throughout the process, including confirmation of successful QR code scans, data population, and form submission.
• Create APIs to facilitate communication between the Flutter frontend and backend systems.
• Define endpoints for retrieving form data based on QR code scans and submitting completed forms.
• Should support local languages through integration with translation services/inhouse localization capabilities

Acceptance Criteria

• Each form instance must be associated with a unique QR code.
• The QR code generation process should be automated and seamlessly integrated into the Flutter UI component.
• The Flutter UI component should provide functionality to automatically generate a PDF format of the form.
• The generated PDF should include the unique QR code associated with the form.
• The Flutter app must include QR code scanning functionality using the device's camera.
• Users should be able to scan printed forms containing the unique QR code.
• Upon scanning a QR code, the app must retrieve the corresponding form data.
• The scanned data should populate the form fields within the Flutter UI automatically.
• Users should be able to view the scanned data presented in a filled form within the app.
• Mechanisms for editing filled data within the form should be provided where necessary.
• Errors encountered during data scanning, retrieval, or population must be clearly highlighted within the app interface.
• Users should receive prompt feedback on any errors encountered during the process.
• The Flutter app must implement mechanisms to match filled data from scanned forms with master data and Ensure accurate mapping of filled data to corresponding fields in the form UI.
• APIs must be created to facilitate communication between the Flutter frontend and backend systems.

Implementation Details:

• Libraries/3rd Party tools may be used but must be open-source
• DIGIT uses Java Spring Boot in the backend and Flutter for the frontend for mobile applications
• Staging environment of DIGIT will be provided and an existing form from a product may be used.

Mockups / Wireframes
To be created by the selected contributor with support from DIGIT product manager

Product Name
DIGIT

Project Name
QR Code-Enabled Form Submission Component for Flutter: Simplifying Digital Interactions

Organization Name:
eGovernments Foundation

Domain
Public Services

Tech Skills Needed:
Flutter, Java Spring Boot

Mentor(s)
Naveen J

Complexity
High

Category
Feature

Sub Category
API, Frontend, Backend,

• Standardize Telemetry Event that works for all channels as currently web telemetry and whatsapp telemetry is going into different ES collections.
• Telemetry Events needs to be defined and standardized.
• With current events data if user can go from Page 1 to Page 3 and Page 2 to Page 3. while we are able figure out total number of users in Page 3, we are not able to figure out how many came from Page 1 and Page 2.
• Documentation of telemetry? No extensive docs today
• Release gating (to do: Platform docs as part of product and changelog)

-Gaps are identified

• Will relook at the telemetry arch and update

• Analyse VAPT Fixes (Critical)
• Prioritise core lib/component upgrade
• Critical vulnerabilities fixes in the Core services
• - [ ] Critical vulnerabilities fixes in the Municipal services

@gajendran