RCF-1277 RCF-1378 Added audit logs

[MadhuMosip]

Summary by CodeRabbit

• Chores
  • Expanded audit logging across authentication, biometrics, demographics, packet lifecycle, sync and validation flows to improve operational tracking.
  • Added numerous new audit event types covering user, packet, sync, registration and biometric actions.
  • Updated audit event codes used for packet approval/rejection and acknowledgement printing.
  • UI flow now emits additional audit entries during biometric capture and operator authentication transitions.

[coderabbitai]

Walkthrough

Adds widespread audit logging: new AuditEvent constants, AuditManagerService wired into DI and service constructors, and audit calls inserted across API, service, batch, and UI layers; no public API removals, only two constructors extended to accept AuditManagerService.

Changes

Cohort / File(s)	Summary
API Services android/app/src/main/java/io/mosip/registration_client/api_services/... (AuthenticationApi.java, BiometricsDetailsApi.java, DemographicsDetailsApi.java, MachineDetailsApi.java, MasterDataSyncApi.java, PacketAuthenticationApi.java, UserDetailsApi.java)	Inserted auditManagerService.audit/auditWithArguments calls at method entry points and key state changes (e.g., FETCH_USR_ROLE, REG_BIO_, SAVE_DETAIL_TO_DTO, FETCH_CNTR_NAME, SYNCJOB_INFO_FETCH, PACKET_). No signature changes.
Batch & Utils android/app/src/main/java/io/mosip/registration_client/utils/BatchJob.java	Added audit calls for sync/upload lifecycle (PACKET_SYNCED_TO_SERVER, PACKET_UPLOAD, PACKET_UPLOADED, PACKET_INTERNAL_ERROR).
DI / Module Wiring android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java	Updated provider methods to accept AuditManagerService and pass it into constructed PacketServiceImpl and PreCheckValidatorServiceImpl.
AuditEvent Constants android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/AuditEvent.java	Added many new AuditEvent enum constants across USER, PACKET, SYNC, REGISTRATION, BIOMETRICS categories (dozens of new literals).
Service Implementations android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/... (PacketServiceImpl.java, PreCheckValidatorServiceImpl.java, RegistrationServiceImpl.java)	Constructors extended to accept AuditManagerService; added audit calls in validation, packet creation/encryption/zip, sync validations, and packet limit checks.
Flutter UI lib/ui/... (approve_packet/widget/template_bottom_sheet.dart, post_registration/acknowledgement_page.dart, process_ui/generic_process.dart, process_ui/widgets_mobile/biometric_capture_scan_block_portrait.dart)	Updated audit event identifiers and added audit log calls for operator auth, acknowledgement printing/preview navigation, and biometric "Next" action. No control-flow changes beyond async handler conversion in one handler.

Sequence Diagram(s)

(Skipped — changes are primarily audit logging insertions and wiring without a new multi-component sequential feature that requires flow visualization.)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

• RCF-1277 Added ARC Audit #667: Overlapping audit-logging additions and AuditEvent enum changes across same APIs and services.

Suggested reviewers

• ase-101

Poem

🐰 Hopping through code with a tiny tap,

I mark each event on every app map.
Packets and biometrics, centers and more,
I log every hop as I bound through the door.
Cheers — concise traces, audited galore!

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 7.41% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title references two ticket numbers (RCF-1277 and RCF-1378) but provides minimal descriptive information. The phrase 'Added audit logs' is vague and generic, failing to specify what audit logs were added or which components were modified.	Replace the generic phrase 'Added audit logs' with specific details about the scope of changes, such as 'Add audit logging to authentication, biometrics, and packet management flows' or similar, to provide meaningful context about the changeset.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/AuditEvent.java (2)

137-140: SYNC event descriptions are unusually verbose compared to the rest of the enum.

Line 137's description ("SyncJobInfo containing the sync control list and yet to export packet count fetched successfully") is much longer than any other event description in this file. Consider trimming to something concise like "Sync job info fetched successfully" for consistency with the rest of the enum. Same applies to Lines 138-139.

---

188-193: Biometrics events are correctly defined; minor whitespace nit.

Lines 191-193 use embedded tab characters between the last comma and the description string literal, while the rest of the file uses spaces. Purely cosmetic.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 8

🤖 Fix all issues with AI agents

In
`@android/app/src/main/java/io/mosip/registration_client/api_services/MasterDataSyncApi.java`:
- Around line 243-244: The audit call for SYNC_DEVICE_DETAILS in
MasterDataSyncApi.syncMasterData() is misleading because this method does not
sync device details; remove the
auditManagerService.audit(AuditEvent.SYNC_DEVICE_DETAILS,
Components.REGISTRATION) invocation or wrap it in a conditional that only runs
when device details are actually synced (e.g., after a device-sync code path or
when a DeviceDetails result/flag is present). Update only the audit call
(located next to auditManagerService.audit(AuditEvent.SYNC_MASTER_DATA,
Components.REGISTRATION)) so the logged events accurately reflect the work done
and remain consistent with the masterSyncJob path.

In
`@android/app/src/main/java/io/mosip/registration_client/api_services/PacketAuthenticationApi.java`:
- Line 119: The audit events PACKET_SYNCED_TO_SERVER and PACKET_UPLOADED are
being recorded with Components.REGISTRATION in PacketAuthenticationApi (via
auditManagerService.audit(...)), but BatchJob.java emits the same events with
Components.REG_PACKET_LIST; make them consistent by updating the
auditManagerService.audit calls in PacketAuthenticationApi for
AuditEvent.PACKET_SYNCED_TO_SERVER and AuditEvent.PACKET_UPLOADED to use
Components.REG_PACKET_LIST (so both PacketAuthenticationApi and BatchJob.java
attribute the same component).
- Line 219: Update the misspelled audit enum and its usages: rename the
AuditEvent constant PACKET_RETRIVE to PACKET_RETRIEVE in the AuditEvent enum
(and correct its enum description text from "retrived" to "retrieved"), then
update all references such as the call
auditManagerService.audit(AuditEvent.PACKET_RETRIVE, Components.REGISTRATION) in
PacketAuthenticationApi to use AuditEvent.PACKET_RETRIEVE so compilation and
logs reflect the correct spelling.

In
`@android/app/src/main/java/io/mosip/registration_client/api_services/UserDetailsApi.java`:
- Line 72: The audit event AuditEvent.VALIDATE_USER_CRED is emitted in
validateUser immediately after calling isValidUserId even though no credential
validation occurs; update the audit to accurately reflect the action by either
replacing AuditEvent.VALIDATE_USER_CRED with a more appropriate event like
AuditEvent.VALIDATE_USER_ID (or ADD/CREATE a new enum constant) inside the
validateUser flow, or move the auditManagerService.audit(...) call to the point
where credentials are actually checked—identify and modify the
auditManagerService.audit(...) invocation and the AuditEvent enum to keep event
names consistent with the actual operation.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/AuditEvent.java`:
- Around line 175-179: The AuditEvent enum contains duplicate audit codes:
PACKET_CREATION_SUCCESS, PACKET_ENCRYPTED, PACKET_UPLOADED,
PACKET_SYNCED_TO_SERVER (using REG-EVT-066..069) and REG_BIO_LEFT_SLAP_SCAN /
REG_BIO_SCAN share REG-EVT-030; update these enum constants to use unique,
non-colliding codes (e.g., choose the next unused REG-EVT numbers) in
AuditEvent, confirm no other constants (like APPR_* or NEXT_BUTTON_CLICKED) use
those codes, and adjust any downstream consumers/tests/configs that reference
the old values so analytics and correlation remain correct. Ensure you search
the repo for the old codes before changing and keep the enum names unchanged to
avoid API breaks.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/PacketServiceImpl.java`:
- Line 428: The audit call
auditManagerService.audit(AuditEvent.SYNC_PKT_COUNT_VALIDATE,
Components.REGISTRATION) is invoked before the packet count validation and is
executed inside the same try that can short-circuit validation; move this audit
invocation to after the actual validation logic (so it only logs when validation
ran) and wrap the audit call in its own small try-catch that logs audit failures
but does not rethrow, ensuring packet count validation in the PacketServiceImpl
method always runs even if audit() fails.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java`:
- Line 84: The call to auditManagerService.audit(...) in
PreCheckValidatorServiceImpl may throw and is currently allowed to bubble up and
be re-wrapped as a ClientCheckedException which can incorrectly block
registration; modify the code around the audit call
(auditManagerService.audit(AuditEvent.SYNC_INFO_VALIDATE,
Components.JOB_SERVICE)) to execute it inside its own try-catch, catch and log
any exception (or use auditManagerService-specific error handling) but do not
rethrow or translate it into OPT_TO_REG_TIME_SYNC_EXCEED — treat it as
fire-and-forget so the rest of the validation flow continues even if audit
fails.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java`:
- Around line 308-313: In RegistrationServiceImpl adjust the flow so
auditManagerService.audit(AuditEvent.PACKET_ENCRYPTED, ...) and
AuditEvent.PACKET_INTERNAL_ZIP are only invoked after persistPacket returns a
non-null result: move or wrap those audit calls to occur after the persistPacket
null-check (i.e., after verifying the returned packet != null). Also fix the
containerPath null-check by changing the condition from "containerPath != null
|| !containerPath.trim().isEmpty()" to use logical AND ("containerPath != null
&& !containerPath.trim().isEmpty()") so it doesn't NPE when containerPath is
null.

🧹 Nitpick comments (2)

android/app/src/main/java/io/mosip/registration_client/api_services/DemographicsDetailsApi.java (1)

49-49: All four demographic mutation methods use the same SAVE_DETAIL_TO_DTO event.

Consider whether the audit trail needs to distinguish between addDemographicField, addSimpleTypeDemographicField, setDateField, and setConsentField. Currently, all four emit the identical event, so any downstream audit analysis cannot differentiate the operation type. If this is intentional (coarse-grained auditing for demographics), no action is needed.

Also applies to: 87-87, 123-123, 142-142

android/app/src/main/java/io/mosip/registration_client/api_services/UserDetailsApi.java (1)

51-52: USER_STATUS_FETCH and FETCH_USR_DET are logged before any input validation.

Both events will be recorded even when username is empty/null and the method returns early with REG_USER_EMPTY. This is fine if the intent is to track all validation attempts, but if you only want to audit successful lookups, move these after the input checks.

[coderabbitai]

Actionable comments posted: 4

🤖 Fix all issues with AI agents

In
`@android/app/src/main/java/io/mosip/registration_client/api_services/MasterDataSyncApi.java`:
- Line 438: The unguarded call to
auditManagerService.audit(AuditEvent.SYNCJOB_INFO_FETCH, Components.JOB_SERVICE)
inside getActiveSyncJobs can throw and block returning results; wrap that audit
invocation in its own try-catch so any exceptions are swallowed or logged (do
not rethrow) to preserve the method's normal return path. Specifically, locate
the audit call in getActiveSyncJobs, surround auditManagerService.audit(...)
with try { ... } catch (Exception e) { /* log audit failure via logger or
auditManagerService.log/error but do not throw */ }, and ensure the catch only
records the failure without impacting the method's result.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/AuditEvent.java`:
- Around line 176-179: Fix the typos in the audit event description strings for
PACKET_CREATION_SUCCESS, PACKET_ENCRYPTED, and PACKET_SYNCED_TO_SERVER in the
AuditEvent enum: change "Packet Succesfully Created", "Packet Encrypted
Sucessfully", and "Packet Synced to Server Sucesfully" to use the correct
spelling "Successfully" (e.g., "Packet Successfully Created", "Packet Encrypted
Successfully", "Packet Synced to Server Successfully") so persisted audit logs
use the corrected text.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java`:
- Around line 296-297: The audit call
auditManagerService.audit(AuditEvent.SYNC_GEO_VALIDATE, Components.REGISTRATION)
in validateCenterToMachineDistance is unguarded and can throw
non-NumberFormatException errors that will block registration; wrap that single
audit call in its own try-catch that catches Exception (or Throwable) and logs
the failure via the existing logger (e.g., logger.error(..., e)) without
rethrowing, mirroring the handling used for SYNC_INFO_VALIDATE so the audit
remains fire-and-forget.

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java`:
- Around line 342-344: persistPacket can return a null/empty containerPath but
the code still calls insertRegistration and emits
auditManagerService.audit(AuditEvent.PACKET_CREATION_SUCCESS,
Components.REGISTRATION); — change the flow in RegistrationServiceImpl so you
check the result of persistPacket (containerPath) immediately: if containerPath
is null/empty, log/audit a failure and return or throw (so insertRegistration is
not called), otherwise proceed to call insertRegistration and then emit
PACKET_CREATION_SUCCESS; reference the persistPacket call site,
insertRegistration(...) invocation, and the auditManagerService.audit(...) call
when making the change.

🧹 Nitpick comments (1)

android/app/src/main/java/io/mosip/registration_client/api_services/PacketAuthenticationApi.java (1)

194-197: Inconsistent Components value in upload error path.

PACKET_INTERNAL_ERROR uses Components.REGISTRATION while all other audit calls in uploadPacketAll use Components.REG_PACKET_LIST. This will make error events harder to correlate with the corresponding upload flow in audit queries.

-                auditManagerService.audit(AuditEvent.PACKET_INTERNAL_ERROR, Components.REGISTRATION);
+                auditManagerService.audit(AuditEvent.PACKET_INTERNAL_ERROR, Components.REG_PACKET_LIST);

[ase-101]

Why are we not passing the exception or error to the audit method?

[ase-101]

What are the other packetclient status we maintain?
If it’s only 2, do we need if-else if block here just for audit?

[ase-101]

What are the other packetclient status we maintain?
If it’s only 2, do we need if-else if block here just for audit?

[ase-101]

Why are we creating 2 different audits for the same action?

[ase-101]

Why is the error object not passed to audit method?

[ase-101]

We should handle all the exception inside the audit method instead of writing try-catch block in the caller method.

[ase-101]

We should handle all the exception inside the audit method instead of writing try-catch block in the caller method.

[ase-101]

We should handle all the exception inside the audit method instead of writing try-catch block in the caller method.

[ase-101]

Check comments