Repository navigation
[DMP 2026]: Track Supervisor ID in Registration Packet Processing #2322
Description
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)
Category
Backend
Metadata
Metadata
Assignees
Type
Fields
Priority
Start Date
End Date
Complexity
Original Estimate
Time Tracking
Resolved By
Story Points
Activity
srinivasr commentedon May 2, 2026
"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 commentedon May 5, 2026
@Varaniya201 Is this issue open for applicants on C4GT-DMP program???
irnahura commentedon May 6, 2026
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:
supervisor_idas a nullable column toregistration_listand wiring it through the sync request DTOThis 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 commentedon May 8, 2026
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 commentedon May 10, 2026
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 commentedon May 10, 2026
hey @Varaniya201 submitted a proposal for this as a part of dmp 2026, looking forward to it!!
Adithkp03 commentedon May 12, 2026
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:
POST /syncV3endpoint alongside the unchanged/syncV2supervisorIdandsourcefields wired through the sync request DTO and persisted toregistration_listas a nullable column (backward compatible with all existing V2 records)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 supervisorIdSupervisorValidationProcessorrefactored to branch onsource— admin packets skip biometric validation, supervisor packets run the existing validator after an ID match check, legacy packets pass throughSyncRegistrationServiceTest,SupervisorValidatorProcessorTest, andRegistrationStatusAndSyncControllerTest, including anArgumentCaptorassertion provingsupervisorIdandsourceactually reach the DAOHappy to walk through any part of the implementation. Looking forward to your feedback!
[-][DMP 2026]: Enhancement: Track Supervisor ID in Registration Packet Processing[/-][+][DMP 2026]: Track Supervisor ID in Registration Packet Processing[/+]codetuscan commentedon Jul 1, 2026
Hello, we are team Vijaya working on this.
Resolves mosip#2322 Track supervisor id, decision and comment in anon…
Resolves mosip#2322 Track supervisor id, decision and comment in anon…
Resolves mosip#2322 Keep tagging the anonymous profile when superviso…
Resolves mosip#2322 Keep tagging the anonymous profile when superviso…
Resolves mosip#2322 Track supervisor id, decision and comment in anon…
ckm007 commentedon Oct 8, 2026
🔗 Linked PR
Resolves mosip#2322 Track supervisor id, decision and comment in anon…
Resolves mosip#2322 Keep tagging the anonymous profile when superviso…
Resolves mosip#2322 Track supervisor id, decision and comment in anon…
Resolves mosip#2322 Address CodeRabbit review on supervisor fields