[DMP 2026]: Track Supervisor ID in Registration Packet Processing

[Varaniya201]

Ticket Contents

Description

User Story Statement:
As a country representative, I want supervisor details to be available in the reporting data generated by the Registration Processor so that I can generate reports showing supervisors against approved and rejected registration packets.

As-Is:
Currently, when a supervisor approves or rejects a registration packet, the system captures details such as status (Approved/Rejected), comments, and timestamp. However, the supervisor ID is not captured, making it difficult to track which supervisor performed the action for reporting purposes.

To-Be:
The system should capture and persist the supervisor ID along with approval/rejection details during packet processing. This will enable traceability and reporting (supervisor vs approved/rejected packets). Additionally, supervisor validation should be enforced during processing, and packets uploaded via admin and supervisors should be distinguished and tracked separately.

Goals & Mid-Point Milestone:

Goals:

• Expose supervisor ID as a dedicated reporting field.
• Capture supervisor approval/rejection decision in the anonymous profile.
• Capture supervisor comments in the anonymous profile.
• Enable supervisor-based reporting using the existing reporting framework.
• Maintain complete backward compatibility with existing reports and data.

[Goals Achieved By Mid-point Milestone]

• AnonymousProfileDTO updated with new supervisor fields.
• AnonymousProfileService enhanced to populate supervisor reporting fields.
• WorkflowInternalActionVerticle retrieves supervisor decision and comment from existing registration data.
• Enhanced anonymous profile successfully persisted.

Setup/Installation:

This feature will be implemented as part of the Registration Client. Please refer to the developer guide for further details.

Expected Outcome:

• Anonymous profile contains explicit supervisor information.
• Supervisor approval/rejection reports can be generated directly from Elasticsearch/Kibana.
• Existing reporting pipeline remains unchanged.
• Existing dashboards continue to function without modification.
• Legacy anonymous profiles remain valid.

Acceptance Criteria

• The system shall capture the supervisor details associated with a registration packet for reporting purposes.
• The system shall make the supervisor's approval or rejection decision available in the reporting data.
• The system shall make the supervisor's comments available in the reporting data, where provided.
• The reporting data shall enable identification of the supervisor who approved or rejected a registration packet.
• Authorised users shall be able to generate reports showing supervisor-wise approved and rejected registration packets using the existing reporting framework.
• Existing reports and dashboards that do not use supervisor information shall continue to function without any impact.
• Registration packets that do not contain supervisor information shall continue to be processed and reported without affecting existing functionality.
• Historical registration packets created before this enhancement shall remain accessible through existing reports without requiring any data migration.

Alternate Scenarios

Scenario ID	Scenario	Condition	System Behaviour	User/System Message
AS-01	Supervisor approves a packet	A supervisor successfully approves a registration packet	Supervisor details, approval decision, and comments (if provided) are made available in the reporting data.	Packet approved successfully.
AS-02	Supervisor rejects a packet	A supervisor rejects a registration packet	Supervisor details, rejection decision, and comments are made available in the reporting data.	Packet rejected successfully.
AS-03	Supervisor does not provide comments	A supervisor approves or rejects a packet without entering comments	The packet is processed successfully, and reporting captures the supervisor details and decision. Comments remain empty.	Packet processed successfully.
AS-04	Packet without supervisor information	The packet belongs to a flow where supervisor information is not available	The packet continues to be processed and included in reporting without supervisor details.	Packet processed successfully.
AS-05	Legacy packet	A packet created before this enhancement is processed or reported	Existing packet information continues to be available in reports without supervisor-specific information.	Legacy packet processed successfully.

Error Scenarios

Scenario ID	Scenario	Condition	System Behaviour	User/System Message
ES-01	Supervisor information unavailable	Supervisor details cannot be retrieved while generating reporting data	The system skips capturing supervisor-specific reporting information and records the event for investigation.	Supervisor information could not be captured for reporting.
ES-02	Supervisor decision unavailable	The supervisor's approval or rejection decision is not available	The system generates the report with available information and flags the missing decision for review.	Supervisor decision is unavailable for reporting.
ES-03	Reporting data generation failure	The system encounters an error while generating the reporting data	The system logs the failure and retries or marks the record for later processing based on configured behaviour.	Unable to generate reporting data. Please try again later.
ES-04	Reporting data persistence failure	The reporting data cannot be saved successfully	The system records the failure and prevents incomplete reporting data from being published.	Failed to save reporting information.
ES-05	Reporting publication failure	The reporting data cannot be published to the reporting platform	The system logs the failure and follows the existing retry mechanism for publishing.	Reporting information could not be published.
ES-06	Invalid reporting data	Mandatory reporting information is inconsistent or invalid	The system skips publishing the affected reporting record and records the issue for investigation.	Reporting data validation failed.

Implementation Details

Overview
This enhancement enriches the existing Anonymous Profile generated by the Registration Processor with dedicated supervisor reporting fields.

Rather than introducing new APIs or database changes, the Registration Processor reads existing supervisor information from packet metadata and registration records and stores them as explicit fields in the anonymous profile JSON.
The existing reporting pipeline (Anonymous Profile → Elasticsearch → Kibana) remains unchanged.

Assumptions

• Supervisor ID is already available in packet metadata (operationsData).
• Supervisor decision and comment are already stored in registration_list.
• Anonymous Profile is generated after packet processing is completed.
• Existing reporting infrastructure continues to publish anonymous profiles.

Key Clarifications

• No new Sync API is introduced.
• No Registration Client changes are required.
• No Admin Services changes are required.
• No database schema changes are required.
• Existing assisted[] field remains unchanged.
• The enhancement only adds explicit reporting fields.

Processing Logic

• Packet processing completes.
• Registration Processor retrieves:
• supervisorId from packet metadata.
• supervisorDecision from registration data.
• supervisorComment from registration data.
• AnonymousProfileDTO is enriched with the three new fields.
• Enhanced anonymous profile is persisted.
• Existing reporting pipeline publishes the profile to Elasticsearch.
• Kibana dashboards can use the new fields for reporting.

Backward Compatibility

• Existing anonymous profiles remain unchanged.
• Existing dashboards using assisted[] continue to work.
• New reporting fields are nullable.
• No migration of historical data is required.
• Existing APIs and integrations remain unaffected.

Design Document:

Supervisor-ID-AnonProfile-Design.md

Mockups/Wireframes

NA

Product Name

MOSIP

Organisation Name

RCTS-IIITH

Domain

Open Source Library

Tech Skills Needed

Java

Mentor(s)

@dhanendra06 @Varaniya

Category

Backend

[srinivasr]

"Hi @ashok-ksharma, @Varaniya,

I am a C4GT 2026 Dedicated Mentoring Program participant and I would like to take up this task. I have analyzed the ticket requirements and the Validation Decision Tree, and I am confident in implementing the transition to Sync V3.

My approach will focus on three critical areas:

Logic Implementation: Handling the conditional supervisor validation within the Registration Processor, ensuring Admin-uploaded packets correctly use the adminId as a supervisorId while bypassing biometric checks.

Schema & Persistence: Updating the registration_list table with the nullable supervisor_id field, ensuring we maintain strict backward compatibility for legacy packets and V2 sync requests.

Validation Rigor: Implementing the logic to cross-reference supervisorId between the packet metadata and the sync request to prevent mismatches, as outlined in the error scenarios.

I have a strong background in developing system-level tools and working with robust backend frameworks (including FastAPI and Java). You can review my work on GitHub under srinivasr, where I maintain several open-source projects focused on UI/UX configurations and system-level tools.

I’m ready to begin drafting the implementation design for the Sync V3 endpoint immediately. Could you please assign this to me?"

[IITI-tushar]

@Varaniya201 Is this issue open for applicants on C4GT-DMP program???

[irnahura]

Hi @ashok-ksharma @Varaniya,

I'd love to take up this issue! I have hands-on experience with Java backend development and have worked on similar registration/workflow systems during my internship, where I handled API validation, database persistence, and transaction management — all of which align closely with what this feature demands.

I've already pulled the repo and gone through the codebase. While exploring, I also noticed a couple of other areas that could use some attention (happy to open separate issues for those). The existing sync flow and DB layer gave me a solid understanding of how this fits in.

For this specific feature, I already have a rough solution in mind:

• Adding supervisor_id as a nullable column to registration_list and wiring it through the sync request DTO
• Implementing the V3 endpoint with the validation decision tree (admin vs supervisor flow, mismatch checks, backward compatibility for V2)
• Using a flag/marker to distinguish admin-uploaded packets from supervisor-uploaded ones at the processing stage

This looks like a great opportunity to contribute meaningfully, and I'm confident I can deliver a clean, well-tested implementation. Would be glad to work with you on this!

[bkrajak523]

Hi @Varaniya201,

I’d like to take up this issue under the C4GT DMP 2026 program.

I have gone through the requirement and started exploring the registration-processor codebase to understand how supervisor-level actions and packet status updates are currently handled. I am currently tracing the Sync V3 flow inside the registration-status-service-impl module to identify the exact service and persistence layer involved.

From my understanding, the enhancement will involve extending the Sync V3 request to carry supervisorId, enforcing validation for supervisor vs admin uploads, and persisting this field for traceability while maintaining backward compatibility for V2 flows.

I am in the process of mapping the exact DTOs, service methods, and repository layer interactions before finalizing a detailed design approach aligned with the existing MOSIP architecture.

Could you please assign this issue to me? I’m happy to share a detailed design once the exact flow mapping is complete.

[ASK3002]

Hi @Varaniya201,
I’ve submitted a proposal for this issue under C4GT DMP 2026. I analyzed the existing implementation and workflow instead of directly modifying the fork.

To better understand and validate a potential direction, I also created a small demo/prototype application that mimics a possible solution approach for the issue. I’ve kept it public on my GitHub for reference. My proposal includes research, observations, diagrams, and implementation insights.

Looking forward to it. Thanks!

[Sandipmandal25]

hey @Varaniya201 submitted a proposal for this as a part of dmp 2026, looking forward to it!!

[Adithkp03]

Hi @ashok-ksharma @Varaniya201

I'd like to take up this issue. After pulling the repo and going through the existing sync flow, DB layer, and supervisor validation stage, I have a clear picture of where this fits and what it needs.

I've already implemented an MVP — PR #2344 is up for review. It covers:

• New POST /syncV3 endpoint alongside the unchanged /syncV2
• supervisorId and source fields wired through the sync request DTO and persisted to registration_list as a nullable column (backward compatible with all existing V2 records)
• Full validation decision tree in SyncRegistrationServiceImpl.syncV3(): supervisor upload path with metadata cross-check, admin upload path with validation skip, and legacy pass-through for packets with no source or supervisorId
• SupervisorValidationProcessor refactored to branch on source — admin packets skip biometric validation, supervisor packets run the existing validator after an ID match check, legacy packets pass through
• DB upgrade and rollback scripts, a partial index for reporting queries, and a working SQL query that directly answers the user story (supervisor vs approved/rejected packet counts)
• Test coverage across SyncRegistrationServiceTest, SupervisorValidatorProcessorTest, and RegistrationStatusAndSyncControllerTest, including an ArgumentCaptor assertion proving supervisorId and source actually reach the DAO

Happy to walk through any part of the implementation. Looking forward to your feedback!

[codetuscan]

Hello, we are team Vijaya working on this.