refactor: update recipient deletion logic in DigiKhata API#553
refactor: update recipient deletion logic in DigiKhata API#553shubhmjain30 merged 4 commits intodevfrom
Conversation
- Refactor the recipient deletion process to use beneficiary_id instead of recipient_id for improved clarity and consistency. - Update the verifyDeleteRecipientOtp function to include recipient_id from the pendingDeleteRecipient state, ensuring accurate OTP verification.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the recipient deletion flow by transitioning from recipient_id to beneficiary_id for OTP requests and introducing a dedicated payload interface for verification. Feedback highlights a critical inconsistency in the onResend logic which still utilizes the old identifier, and suggests using beneficiary_id during the verification step to ensure consistency across the deletion process.
|
|
||
| const handleDeleteRecipient = async (recipient: Recipient) => { | ||
| const res = await sendDeleteRecipientOtp(recipient.recipient_id); | ||
| const res = await sendDeleteRecipientOtp(recipient.beneficiary_id ?? 0); |
There was a problem hiding this comment.
The refactor to use beneficiary_id for recipient deletion is inconsistent with the onResend logic in the OtpModal (line 645), which still passes recipient_id to sendDeleteRecipientOtp. Since the function signature was updated in useDigiKhataApi.ts to expect beneficiaryId and send it as beneficiary_id in the request body, the resend functionality will fail or target the wrong identifier. Please update the onResend handler to use pendingDeleteRecipient.beneficiary_id ?? 0.
| const res = await verifyDeleteRecipientOtp({ | ||
| otp, | ||
| otp_ref_id: deleteOtpRefId, | ||
| recipient_id: pendingDeleteRecipient.recipient_id, |
There was a problem hiding this comment.
This call site should use beneficiary_id to match the intended refactor for the deletion flow, ensuring that the same identifier is used for both the OTP request and the verification step.
| recipient_id: pendingDeleteRecipient.recipient_id, | |
| beneficiary_id: pendingDeleteRecipient.beneficiary_id ?? 0, |
- Changed the recipient ID used in the resend OTP function to utilize beneficiary_id instead of recipient_id. This ensures the correct identifier is used for OTP operations related to recipient deletion.
- Update the RecipientsStep component to only display the delete button if the recipient has a valid beneficiary_id. This change improves the user interface by preventing unnecessary actions on recipients without a beneficiary ID.
…actor/digikhata
1 participant
Description
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
🚨 Checklist:
Further comments
🙏 Thank you!
Thank you for contributing to this project. We appreciate your time and effort. 🎉