AMM-1148 | Close call API including reattempt logic based on calltype #164
Conversation
|
Warning Rate limit exceeded@srishtigrp78 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 18 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe changes update the grievance allocation retry configuration from 1 to 3 in multiple environment properties files. A new controller method ( Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant GC as GrievanceController
participant GS as GrievanceDataSyncImpl
participant GR as GrievanceDataRepo
participant DB as Database
C->>GC: POST /completeGrievanceCall (JSON request)
GC->>GS: completeGrievanceCall(request)
GS->>GR: Retrieve call counter & call details
GR-->>GS: Return call details
GS->>GR: Update call counter/retry status as needed
GR-->>GS: Acknowledge update
GS-->>GC: Return success/failure response
GC-->>C: Send response
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (9)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSync.java (1)
15-15: Consider enhancing the method signature with better types and documentationThe new method
completeGrievanceCallhas been added to the interface. Consider these improvements:
- Add JavaDoc comments to describe the method's purpose and parameters
- Consider using a more specific exception type rather than the generic
Exception- If possible, use a strongly-typed request object rather than a String parameter
+/** + * Complete a grievance call with retry logic based on call type + * + * @param request JSON string containing the grievance call details + * @return Response with the status of the call completion + * @throws IEMRException If there is an issue processing the request + */ -public String completeGrievanceCall(String request) throws Exception; +public String completeGrievanceCall(String request) throws IEMRException;src/main/java/com/iemr/common/data/grievance/GrievanceCallRequest.java (1)
1-17: New model class for representing grievance call requestsThe new
GrievanceCallRequestclass provides a clean structure for handling grievance call completion requests. The use of Lombok's@Dataannotation reduces boilerplate code.Consider adding validation constraints (such as
@NotNullfor required fields) to ensure data integrity at the model level. This would provide early validation before the request reaches the service layer.src/main/java/com/iemr/common/repository/callhandling/IEMRCalltypeRepositoryImplCustom.java (1)
91-93: New repository method to retrieve call detailsThe new method
getCallDetailsallows retrieval of call type and group type information based on call type ID, which is essential for implementing the call type-based reattempt logic mentioned in the PR.Consider expanding the returned fields to include the
maxRedialattribute, which would be directly relevant for reattempt logic implementation. This would avoid the need to make multiple database calls to retrieve related information.src/main/java/com/iemr/common/controller/grievance/GrievanceController.java (1)
182-208: New controller method for grievance call completion with reattempt logicThe new
completeGrievanceCallmethod correctly implements the endpoint for handling grievance call completion, properly documenting the expected request parameters in the Swagger annotations.Some improvements to consider:
- Add more specific error handling to differentiate between different types of failures that might occur during call completion
- Include HTTP status code differentiation in the response for different error scenarios
- Consider adding validation for the incoming request parameters
src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java (3)
75-85: Consider combining or differentiating the twoupdateComplaintResolutionmethods.
Currently, there are two methods namedupdateComplaintResolutionwith slightly different parameters. This can cause confusion for maintainers and possibly lead to unintended usage. Consider either unifying them into a single method (making some parameters optional) or clearly differentiating their names/roles.
98-100: Use typed projections or DTOs instead ofArrayList<Object[]>.
Returning raw arrays forgetCallCountercomplicates maintainability and readability. A typed projection or a dedicated DTO would improve clarity, reduce type conversion errors, and help catch potential mismatches in column order.
113-123: Confirm uniqueness constraints forupdateCallCounter.
This update query matches on multiple fields (complaintID,beneficiaryRegID,providerServiceMapID,userID). Ensure these fields, taken together, represent a unique row to avoid unintended multi-row updates. Also verify the return value to see if any rows were actually updated.src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (2)
9-9: Remove unused import if not required.
TheHashSetimport at line 9 should be removed if not actually needed elsewhere. Unused imports can clutter the codebase.
41-41: Validate custom repository usage.
Check thatIEMRCalltypeRepositoryImplCustomis operational and thoroughly tested, as it introduces a custom data access pattern not enforced by Spring Data JPA’s standard interfaces.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/main/environment/common_ci.properties(1 hunks)src/main/environment/common_dev.properties(1 hunks)src/main/environment/common_example.properties(1 hunks)src/main/environment/common_test.properties(1 hunks)src/main/environment/common_uat.properties(1 hunks)src/main/java/com/iemr/common/controller/grievance/GrievanceController.java(1 hunks)src/main/java/com/iemr/common/data/grievance/GrievanceCallRequest.java(1 hunks)src/main/java/com/iemr/common/repository/callhandling/IEMRCalltypeRepositoryImplCustom.java(1 hunks)src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java(3 hunks)src/main/java/com/iemr/common/service/grievance/GrievanceDataSync.java(1 hunks)src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: style-check / checkstyle
- GitHub Check: Package-test
- GitHub Check: Build
- GitHub Check: Analyze (java)
🔇 Additional comments (8)
src/main/environment/common_dev.properties (1)
189-189: Configuration updated to increase retry attemptsThe configuration value for
grievanceAllocationRetryConfigurationhas been set to 3, which increases the retry attempts for grievance allocation. This change is consistent across all environment property files.src/main/environment/common_ci.properties (1)
163-163: Configuration updated to increase retry attemptsThe configuration value for
grievanceAllocationRetryConfigurationhas been set to 3, which increases the retry attempts for grievance allocation. This change is consistent across all environment property files.src/main/environment/common_uat.properties (1)
162-162: Configuration updated to increase retry attemptsThe configuration value for
grievanceAllocationRetryConfigurationhas been set to 3, which increases the retry attempts for grievance allocation. This change is consistent across all environment property files.src/main/environment/common_test.properties (1)
191-191: Configuration updated to increase retry attemptsThe configuration value for
grievanceAllocationRetryConfigurationhas been set to 3, which increases the retry attempts for grievance allocation. This change is consistent across all environment property files.src/main/environment/common_example.properties (1)
189-189: Updated grievance allocation retry configurationThe configuration parameter for grievance allocation retries has been increased from 1 to 3, which aligns with the reattempt logic implementation mentioned in the PR. This change will allow the system to make more retry attempts before considering the operation as failed.
src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java (1)
88-97: Verify that the secondupdateComplaintResolutionmethod handles remarks consistently.
Unlike the first method, this one does not accept or update theremarksfield. If this is intentional, ensure that it’s clearly documented to avoid confusion about missing remarks handling. Otherwise, consider updating the query to maintain consistency with the first method.src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (2)
36-38: Ensure new imports are all in use.
The newly added imports (CallType,EverwellDetails,GrievanceCallRequest) seem relevant, but confirm each one is actually required. If any are unused, consider removing them.
103-105: Review the injectedgrievanceAllocationRetryConfiguration.
Consider validating or constraining the injected value (e.g., ensure it is non-negative) to protect against misconfiguration in production.
| @Query("UPDATE GrievanceDetails g SET g.isCompleted = :isCompleted " | ||
| + "WHERE g.complaintID = :complaintID AND g.userID = :userID AND g.beneficiaryRegID = :beneficiaryRegID " | ||
| + "AND g.providerServiceMapID = :providerServiceMapID") | ||
| @Transactional | ||
| public int updateCompletedStatusInCall(@Param("isCompleted") Boolean isCompleted, | ||
| @Param("complaintID") String complaintID, | ||
| @Param("userID") Integer userID, | ||
| @Param("beneficiaryRegID") Long beneficiaryRegID, | ||
| @Param("providerServiceMapID") Integer providerServiceMapID); |
There was a problem hiding this comment.
Missing @Modifying annotation on this update method.
For Spring Data JPA, an update query requires both @Transactional and @Modifying. Without @Modifying, the query may not execute as expected. Add @Modifying above @Transactional to ensure correct updating of records for updateCompletedStatusInCall.
+ @Modifying
@Query("UPDATE GrievanceDetails g SET g.isCompleted = :isCompleted "
...📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Query("UPDATE GrievanceDetails g SET g.isCompleted = :isCompleted " | |
| + "WHERE g.complaintID = :complaintID AND g.userID = :userID AND g.beneficiaryRegID = :beneficiaryRegID " | |
| + "AND g.providerServiceMapID = :providerServiceMapID") | |
| @Transactional | |
| public int updateCompletedStatusInCall(@Param("isCompleted") Boolean isCompleted, | |
| @Param("complaintID") String complaintID, | |
| @Param("userID") Integer userID, | |
| @Param("beneficiaryRegID") Long beneficiaryRegID, | |
| @Param("providerServiceMapID") Integer providerServiceMapID); | |
| @Modifying | |
| @Query("UPDATE GrievanceDetails g SET g.isCompleted = :isCompleted " | |
| + "WHERE g.complaintID = :complaintID AND g.userID = :userID AND g.beneficiaryRegID = :beneficiaryRegID " | |
| + "AND g.providerServiceMapID = :providerServiceMapID") | |
| @Transactional | |
| public int updateCompletedStatusInCall(@Param("isCompleted") Boolean isCompleted, | |
| @Param("complaintID") String complaintID, | |
| @Param("userID") Integer userID, | |
| @Param("beneficiaryRegID") Long beneficiaryRegID, | |
| @Param("providerServiceMapID") Integer providerServiceMapID); |
There was a problem hiding this comment.
@srishtigrp78 Great! Thank you for adding the @Modifying annotation to the update method. This ensures the query will execute correctly when modifying records.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| callTypeObj.setCallGroupType((String) object[0]); | ||
| callTypeObj.setCallType((String) object[0]); |
There was a problem hiding this comment.
Confirm correct indexing for call group/type retrieval.
Both callGroupType and callType are set using the same index (object[0]). Verify whether object[1] should be used for the call type. Using the same index could introduce incorrect data if the second column differs.
There was a problem hiding this comment.
@srishtigrp78 Thank you for confirming the fix! That ensures the correct values will be assigned to both the call group type and call type properties.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| @Transactional | ||
| public String completeGrievanceCall(String request) throws Exception { | ||
|
|
||
| GrievanceCallRequest grievanceCallRequest = InputMapper.gson().fromJson(request, GrievanceCallRequest.class); | ||
| String complaintID = grievanceCallRequest.getComplaintID(); | ||
| Integer userID = grievanceCallRequest.getUserID(); | ||
| Boolean isCompleted = grievanceCallRequest.getIsCompleted(); | ||
| Long beneficiaryRegID = grievanceCallRequest.getBeneficiaryRegID(); | ||
| Integer callTypeID = grievanceCallRequest.getCallTypeID(); | ||
| Integer providerServiceMapId = grievanceCallRequest.getProviderServiceMapId(); | ||
| // String createdBy = grievanceCallRequest.getCreatedBy(); | ||
|
|
||
| GrievanceDetails grievanceDetails = new GrievanceDetails(); | ||
| CallType callTypeObj = new CallType(); | ||
| String response = "failure"; | ||
| int updateCount = 0; | ||
| int updateCallCounter = 0; | ||
| int callCounter = 0; | ||
| try { | ||
|
|
||
| // GrievanceDetails grievanceCallStatus = grievanceDataRepo.getCallCounter(complaintID); | ||
| GrievanceDetails grievanceCallStatus = new GrievanceDetails(); | ||
|
|
||
| // List<GrievanceDetails> outboundCallRequests = new ArrayList<GrievanceDetails>(); | ||
| ArrayList<Object[]> lists = grievanceDataRepo.getCallCounter(complaintID); | ||
| for (Object[] objects : lists) { | ||
| if (objects != null && objects.length >= 2) { | ||
| grievanceCallStatus.setCallCounter((Integer) objects[0]); | ||
| grievanceCallStatus.setRetryNeeded((Boolean)objects[1]); | ||
| } | ||
| } | ||
|
|
||
| // Fetching CallDetails using BenCallID and CallTypeID | ||
| Set<Object[]> callTypesArray = new HashSet<Object[]>(); | ||
| callTypesArray = iEMRCalltypeRepositoryImplCustom.getCallDetails(callTypeID); | ||
| for (Object[] object : callTypesArray) | ||
| { | ||
| if (object != null && object.length >= 2) | ||
| { | ||
| callTypeObj.setCallGroupType((String) object[0]); | ||
| callTypeObj.setCallType((String) object[0]); | ||
|
|
||
| } | ||
|
|
||
| } | ||
|
|
||
| String callGroupType = callTypeObj.getCallGroupType(); | ||
| String callType = callTypeObj.getCallType(); | ||
|
|
||
|
|
||
| // Logic for reattempt based on state and call type | ||
| // boolean isRetryNeeded = false; | ||
|
|
||
| boolean isRetryNeeded = grievanceCallStatus.getRetryNeeded(); | ||
| if (callGroupType.equals("Valid")) { | ||
| // Conditions when no reattempt is needed | ||
| if (callType.equals("Valid") || callType.equals("Wrong Number") || callType.equals("Test Call")) { | ||
| isRetryNeeded = false; | ||
| } else if (callType.equals("Disconnected Call") || callType.equals("Serviced Call") || | ||
| callType.equals("Silent Call") || callType.equals("Call Back")) { | ||
| // Reattempt is needed for these call subtypes | ||
| isRetryNeeded = true; | ||
| } | ||
| } | ||
|
|
||
| // Check if max attempts (3) are reached | ||
| if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) { | ||
| // Increment the call counter for reattempt | ||
| grievanceDetails.setCallCounter(grievanceDetails.getCallCounter() + 1); | ||
| // Update the retryNeeded flag | ||
| grievanceDetails.setRetryNeeded(true); | ||
| updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceDetails.getCallCounter(),grievanceDetails.getRetryNeeded(), grievanceCallRequest.getComplaintID(), | ||
| grievanceCallRequest.getBeneficiaryRegID(), grievanceCallRequest.getProviderServiceMapId(), | ||
| grievanceCallRequest.getUserID()); | ||
| // response = "Successfully closing call."; // Return success when reattempt logic is applied successfully. The grievance call needs to be retried, and a reattempt is performed. | ||
| if (updateCallCounter > 0) | ||
| response = "Successfully closing call"; | ||
| else { | ||
| response = "failure"; | ||
| } | ||
| } else if (callCounter == grievanceAllocationRetryConfiguration) { | ||
| // Max attempts reached, no further reattempt | ||
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | ||
| grievanceDetails.setRetryNeeded(false); | ||
| response = "max_attempts_reached"; // Indicate that max attempts are reached | ||
|
|
||
|
|
||
| } else { | ||
|
|
||
| response = "no_reattempt_needed"; // No reattempt needed | ||
| } | ||
|
|
||
|
|
||
|
|
||
| } | ||
| catch (Exception e) { | ||
| response = "error: " + e.getMessage(); | ||
| } | ||
|
|
||
| return response; // Return the response (either success or error message) | ||
| } | ||
|
|
There was a problem hiding this comment.
Resolve potential logic mismatch when incrementing the call counter.
Within completeGrievanceCall, the code reads the current counter into grievanceCallStatus (lines 510–516), yet increments grievanceDetails (a fresh object at line 498) instead. This likely overwrites the existing counter value with zero before incrementing, causing lost data if the call was retried multiple times. Instead, increment grievanceCallStatus, then use it for the update query to maintain accurate retry counts.
- grievanceDetails.setCallCounter(grievanceDetails.getCallCounter() + 1);
- updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceDetails.getCallCounter(), ...
+ int currentCount = grievanceCallStatus.getCallCounter();
+ grievanceCallStatus.setCallCounter(currentCount + 1);
+ updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceCallStatus.getCallCounter(), ...📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Transactional | |
| public String completeGrievanceCall(String request) throws Exception { | |
| GrievanceCallRequest grievanceCallRequest = InputMapper.gson().fromJson(request, GrievanceCallRequest.class); | |
| String complaintID = grievanceCallRequest.getComplaintID(); | |
| Integer userID = grievanceCallRequest.getUserID(); | |
| Boolean isCompleted = grievanceCallRequest.getIsCompleted(); | |
| Long beneficiaryRegID = grievanceCallRequest.getBeneficiaryRegID(); | |
| Integer callTypeID = grievanceCallRequest.getCallTypeID(); | |
| Integer providerServiceMapId = grievanceCallRequest.getProviderServiceMapId(); | |
| // String createdBy = grievanceCallRequest.getCreatedBy(); | |
| GrievanceDetails grievanceDetails = new GrievanceDetails(); | |
| CallType callTypeObj = new CallType(); | |
| String response = "failure"; | |
| int updateCount = 0; | |
| int updateCallCounter = 0; | |
| int callCounter = 0; | |
| try { | |
| // GrievanceDetails grievanceCallStatus = grievanceDataRepo.getCallCounter(complaintID); | |
| GrievanceDetails grievanceCallStatus = new GrievanceDetails(); | |
| // List<GrievanceDetails> outboundCallRequests = new ArrayList<GrievanceDetails>(); | |
| ArrayList<Object[]> lists = grievanceDataRepo.getCallCounter(complaintID); | |
| for (Object[] objects : lists) { | |
| if (objects != null && objects.length >= 2) { | |
| grievanceCallStatus.setCallCounter((Integer) objects[0]); | |
| grievanceCallStatus.setRetryNeeded((Boolean)objects[1]); | |
| } | |
| } | |
| // Fetching CallDetails using BenCallID and CallTypeID | |
| Set<Object[]> callTypesArray = new HashSet<Object[]>(); | |
| callTypesArray = iEMRCalltypeRepositoryImplCustom.getCallDetails(callTypeID); | |
| for (Object[] object : callTypesArray) | |
| { | |
| if (object != null && object.length >= 2) | |
| { | |
| callTypeObj.setCallGroupType((String) object[0]); | |
| callTypeObj.setCallType((String) object[0]); | |
| } | |
| } | |
| String callGroupType = callTypeObj.getCallGroupType(); | |
| String callType = callTypeObj.getCallType(); | |
| // Logic for reattempt based on state and call type | |
| // boolean isRetryNeeded = false; | |
| boolean isRetryNeeded = grievanceCallStatus.getRetryNeeded(); | |
| if (callGroupType.equals("Valid")) { | |
| // Conditions when no reattempt is needed | |
| if (callType.equals("Valid") || callType.equals("Wrong Number") || callType.equals("Test Call")) { | |
| isRetryNeeded = false; | |
| } else if (callType.equals("Disconnected Call") || callType.equals("Serviced Call") || | |
| callType.equals("Silent Call") || callType.equals("Call Back")) { | |
| // Reattempt is needed for these call subtypes | |
| isRetryNeeded = true; | |
| } | |
| } | |
| // Check if max attempts (3) are reached | |
| if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) { | |
| // Increment the call counter for reattempt | |
| grievanceDetails.setCallCounter(grievanceDetails.getCallCounter() + 1); | |
| // Update the retryNeeded flag | |
| grievanceDetails.setRetryNeeded(true); | |
| updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceDetails.getCallCounter(),grievanceDetails.getRetryNeeded(), grievanceCallRequest.getComplaintID(), | |
| grievanceCallRequest.getBeneficiaryRegID(), grievanceCallRequest.getProviderServiceMapId(), | |
| grievanceCallRequest.getUserID()); | |
| // response = "Successfully closing call."; // Return success when reattempt logic is applied successfully. The grievance call needs to be retried, and a reattempt is performed. | |
| if (updateCallCounter > 0) | |
| response = "Successfully closing call"; | |
| else { | |
| response = "failure"; | |
| } | |
| } else if (callCounter == grievanceAllocationRetryConfiguration) { | |
| // Max attempts reached, no further reattempt | |
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | |
| grievanceDetails.setRetryNeeded(false); | |
| response = "max_attempts_reached"; // Indicate that max attempts are reached | |
| } else { | |
| response = "no_reattempt_needed"; // No reattempt needed | |
| } | |
| } | |
| catch (Exception e) { | |
| response = "error: " + e.getMessage(); | |
| } | |
| return response; // Return the response (either success or error message) | |
| } | |
| @Transactional | |
| public String completeGrievanceCall(String request) throws Exception { | |
| GrievanceCallRequest grievanceCallRequest = InputMapper.gson().fromJson(request, GrievanceCallRequest.class); | |
| String complaintID = grievanceCallRequest.getComplaintID(); | |
| Integer userID = grievanceCallRequest.getUserID(); | |
| Boolean isCompleted = grievanceCallRequest.getIsCompleted(); | |
| Long beneficiaryRegID = grievanceCallRequest.getBeneficiaryRegID(); | |
| Integer callTypeID = grievanceCallRequest.getCallTypeID(); | |
| Integer providerServiceMapId = grievanceCallRequest.getProviderServiceMapId(); | |
| // String createdBy = grievanceCallRequest.getCreatedBy(); | |
| GrievanceDetails grievanceDetails = new GrievanceDetails(); | |
| CallType callTypeObj = new CallType(); | |
| String response = "failure"; | |
| int updateCount = 0; | |
| int updateCallCounter = 0; | |
| int callCounter = 0; | |
| try { | |
| // GrievanceDetails grievanceCallStatus = grievanceDataRepo.getCallCounter(complaintID); | |
| GrievanceDetails grievanceCallStatus = new GrievanceDetails(); | |
| // List<GrievanceDetails> outboundCallRequests = new ArrayList<GrievanceDetails>(); | |
| ArrayList<Object[]> lists = grievanceDataRepo.getCallCounter(complaintID); | |
| for (Object[] objects : lists) { | |
| if (objects != null && objects.length >= 2) { | |
| grievanceCallStatus.setCallCounter((Integer) objects[0]); | |
| grievanceCallStatus.setRetryNeeded((Boolean)objects[1]); | |
| } | |
| } | |
| // Fetching CallDetails using BenCallID and CallTypeID | |
| Set<Object[]> callTypesArray = new HashSet<Object[]>(); | |
| callTypesArray = iEMRCalltypeRepositoryImplCustom.getCallDetails(callTypeID); | |
| for (Object[] object : callTypesArray) | |
| { | |
| if (object != null && object.length >= 2) | |
| { | |
| callTypeObj.setCallGroupType((String) object[0]); | |
| callTypeObj.setCallType((String) object[0]); | |
| } | |
| } | |
| String callGroupType = callTypeObj.getCallGroupType(); | |
| String callType = callTypeObj.getCallType(); | |
| // Logic for reattempt based on state and call type | |
| // boolean isRetryNeeded = false; | |
| boolean isRetryNeeded = grievanceCallStatus.getRetryNeeded(); | |
| if (callGroupType.equals("Valid")) { | |
| // Conditions when no reattempt is needed | |
| if (callType.equals("Valid") || callType.equals("Wrong Number") || callType.equals("Test Call")) { | |
| isRetryNeeded = false; | |
| } else if (callType.equals("Disconnected Call") || callType.equals("Serviced Call") || | |
| callType.equals("Silent Call") || callType.equals("Call Back")) { | |
| // Reattempt is needed for these call subtypes | |
| isRetryNeeded = true; | |
| } | |
| } | |
| // Check if max attempts (3) are reached | |
| if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) { | |
| // Increment the call counter for reattempt | |
| int currentCount = grievanceCallStatus.getCallCounter(); | |
| grievanceCallStatus.setCallCounter(currentCount + 1); | |
| // Update the retryNeeded flag | |
| grievanceDetails.setRetryNeeded(true); | |
| updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceCallStatus.getCallCounter(), grievanceCallRequest.getComplaintID(), | |
| grievanceCallRequest.getBeneficiaryRegID(), grievanceCallRequest.getProviderServiceMapId(), | |
| grievanceCallRequest.getUserID()); | |
| // response = "Successfully closing call."; // Return success when reattempt logic is applied successfully. The grievance call needs to be retried, and a reattempt is performed. | |
| if (updateCallCounter > 0) | |
| response = "Successfully closing call"; | |
| else { | |
| response = "failure"; | |
| } | |
| } else if (callCounter == grievanceAllocationRetryConfiguration) { | |
| // Max attempts reached, no further reattempt | |
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | |
| grievanceDetails.setRetryNeeded(false); | |
| response = "max_attempts_reached"; // Indicate that max attempts are reached | |
| } else { | |
| response = "no_reattempt_needed"; // No reattempt needed | |
| } | |
| } | |
| catch (Exception e) { | |
| response = "error: " + e.getMessage(); | |
| } | |
| return response; // Return the response (either success or error message) | |
| } |
There was a problem hiding this comment.
@srishtigrp78 Thank you for confirming the fix! This will help ensure accurate call counter tracking in the grievance system.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (9)
src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java (3)
88-90: Clarify usage of second 'updateComplaintResolution'.
Similar to the first method, ensure that both overloaded methods are actually needed. If only one set of parameters is used, consider removing the other to avoid confusion.
98-101: Use a projection or DTO class for better maintainability.
Passing around rawObject[]can be error-prone and less readable. A projection or small DTO can help ensure stronger types and clearer code.- @Query(" Select grievance.callCounter, grievance.retryNeeded FROM GrievanceDetails grievance where complaintID = :complaintID") - public List<Object[]> getCallCounter(@Param("complaintID") String complaintID); + @Query("SELECT new com.iemr.common.dto.CallCounterDTO(grievance.callCounter, grievance.retryNeeded) " + + "FROM GrievanceDetails grievance WHERE grievance.complaintID = :complaintID") + public List<CallCounterDTO> getCallCounter(@Param("complaintID") String complaintID);
114-124: Consider descriptive naming for 'updateCallCounter'.
The method updates bothcallCounterandretryNeeded, so a method name likeupdateCallStatusor similar may be more intuitive.src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (6)
103-105: Use final or configurable approach for 'grievanceAllocationRetryConfiguration'.
Loading this integer from properties is good practice. Marking itfinalor providing a setter can clarify it is externally configured.
497-501: Consolidate temporary variables.
response,updateCount,updateCallCounter, andcallCounterare scattered. Consider grouping them or initializing them closer to usage for better readability.
536-545: Avoid nesting call-type checks too deeply.
The logic forisRetryNeededcould be refactored into a small helper method for readability and to reduce nested conditionals.
548-562: Check for concurrency issues when updating counters.
Multiple threads callingcompleteGrievanceCallconcurrently can lead to race conditions. Consider versioning or row-level locks if concurrent updates are expected.
563-569: Consider returning more descriptive statuses.
“max_attempts_reached” is helpful, but additional detail in the response could inform the caller how to proceed.
574-579: Log errors more contextually.
In the catch block, include relevant fields (e.g.,complaintID,userID) in the log message for troubleshooting.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java(3 hunks)src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Analyze (java)
🔇 Additional comments (5)
src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java (2)
75-77: Ensure consistency in naming and method overloading.
There are two methods namedupdateComplaintResolution. The parameter lists differ, which can be intentional overloading. If this is expected, it’s fine—otherwise, consider renaming one for clarity.
102-111: Validate query parameters before updating.
Some parameters (e.g.,userID,beneficiaryRegID) may benull. Validate them to prevent potential runtime errors.src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (3)
9-9: Imports and declarations appear valid.
The new imports forHashSet,CallType,EverwellDetails, andGrievanceCallRequestare functional and relevant. No concerns here.Also applies to: 36-38, 41-41, 49-50, 72-72, 77-77, 82-82
486-489: Validate input for 'request' before parsing.
Ifrequestis null or malformed,fromJsoncan fail. A quick null or empty check can safeguard against exceptions.
503-512: Guard against empty list ingetCallCounter.
Iflistsis empty, callingfor (Object[] objects : lists)silently skips the logic. Ensure this scenario is handled gracefully.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (5)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (5)
515-526: Ensure fetched call types are not empty before accessing.The code doesn't validate whether any call types were actually returned from the repository before attempting to use them.
Set<Object[]> callTypesArray = new HashSet<Object[]>(); callTypesArray = iEMRCalltypeRepositoryImplCustom.getCallDetails(callTypeID); +if (callTypesArray == null || callTypesArray.isEmpty()) { + logger.error("No call details found for callTypeID: {}", callTypeID); + return "error: Call details not found"; +} for (Object[] object : callTypesArray)
576-578: Improve exception handling.The current exception handling only returns the error message. Consider logging the full exception for troubleshooting purposes.
catch (Exception e) { + logger.error("Error completing grievance call for complaintID: " + complaintID, e); response = "error: " + e.getMessage(); }
498-501: Remove unused variable.The
callCountervariable is initialized but never updated or used correctly in the method.String response = "failure"; int updateCount = 0; int updateCallCounter = 0; - int callCounter = 0;
489-491: Add input validation.Consider adding validation for the incoming request data to prevent potential null pointer exceptions.
GrievanceCallRequest grievanceCallRequest = InputMapper.gson().fromJson(request, GrievanceCallRequest.class); + if (grievanceCallRequest == null || grievanceCallRequest.getComplaintID() == null) { + logger.error("Invalid request data: {}", request); + return "error: Invalid request data"; + } String complaintID = grievanceCallRequest.getComplaintID();
556-560: Provide more context in failure response.When the update operation fails, consider providing more context about why it failed.
if (updateCallCounter > 0) response = "Successfully closing call"; else { - response = "failure"; + response = "failure: Unable to update call counter in database"; + logger.error("Failed to update call counter for complaintID: {}", complaintID); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Build
- GitHub Check: Analyze (java)
- GitHub Check: Package-test
🔇 Additional comments (2)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (2)
103-104: Configuration variable correctly defined.The grievance allocation retry configuration value is properly defined with its annotation. This will allow for consistent retry attempts across the application.
485-496: Method signature and request parsing look good.The method signature includes proper annotations for transactional support, and the request parsing extracts all necessary parameters from the JSON request.
| if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) { | ||
| // Increment the call counter for reattempt |
There was a problem hiding this comment.
Fix the call counter comparison logic.
The current code compares the local variable callCounter (initialized to 0 and never updated) instead of using the actual counter from grievanceCallStatus.
- if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) {
+ if (isRetryNeeded == true && grievanceCallStatus.getCallCounter() < grievanceAllocationRetryConfiguration) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (isRetryNeeded == true && callCounter < grievanceAllocationRetryConfiguration) { | |
| // Increment the call counter for reattempt | |
| if (isRetryNeeded == true && grievanceCallStatus.getCallCounter() < grievanceAllocationRetryConfiguration) { | |
| // Increment the call counter for reattempt |
There was a problem hiding this comment.
@srishtigrp78 Understood. I'll close this comment without the suggested change.
| } else if (callCounter == grievanceAllocationRetryConfiguration) { | ||
| // Max attempts reached, no further reattempt | ||
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | ||
| grievanceCallStatus.setRetryNeeded(false); | ||
| response = "max_attempts_reached"; // Indicate that max attempts are reached | ||
|
|
||
|
|
There was a problem hiding this comment.
Fix the max attempts condition.
Similar to the previous issue, the condition is checking callCounter instead of the actual value from grievanceCallStatus. Additionally, you're setting grievanceCallStatus.setRetryNeeded(false) but not using this updated value.
- } else if (callCounter == grievanceAllocationRetryConfiguration) {
+ } else if (grievanceCallStatus.getCallCounter() == grievanceAllocationRetryConfiguration) {
// Max attempts reached, no further reattempt
updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId);
- grievanceCallStatus.setRetryNeeded(false);
+ // Update the retry status in the database
+ updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceCallStatus.getCallCounter(), false, complaintID,
+ beneficiaryRegID, providerServiceMapId, userID);
response = "max_attempts_reached"; // Indicate that max attempts are reached📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| } else if (callCounter == grievanceAllocationRetryConfiguration) { | |
| // Max attempts reached, no further reattempt | |
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | |
| grievanceCallStatus.setRetryNeeded(false); | |
| response = "max_attempts_reached"; // Indicate that max attempts are reached | |
| } else if (grievanceCallStatus.getCallCounter() == grievanceAllocationRetryConfiguration) { | |
| // Max attempts reached, no further reattempt | |
| updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, complaintID, userID, beneficiaryRegID, providerServiceMapId); | |
| // Update the retry status in the database | |
| updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceCallStatus.getCallCounter(), false, complaintID, | |
| beneficiaryRegID, providerServiceMapId, userID); | |
| response = "max_attempts_reached"; // Indicate that max attempts are reached |
There was a problem hiding this comment.
🧩 Analysis chain
@srishtigrp78 I'll check if the issue has been fixed in the code. Let me verify the current implementation.
🏁 Script executed:
#!/bin/bash
# Check the current implementation of the completeGrievanceCall method
grep -A 10 "else if.*callCounter.*grievanceAllocationRetryConfiguration" src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java
Length of output: 149
@srishtigrp78 Let me try a broader search to find the current implementation.
🏁 Script executed:
#!/bin/bash
# Let's try a broader search for the condition
grep -A 20 "else if" src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java | grep -A 15 "grievanceAllocationRetryConfiguration"
Length of output: 1930
@srishtigrp78 I've verified the code and can confirm that the issue has been properly fixed! You've made the following corrections:
- Changed the condition to use
grievanceCallStatus.getCallCounter()instead ofcallCounter - Set
grievanceCallStatus.setRetryNeeded(false)correctly - Passed the retry status to the
updateCompletedStatusInCallmethod
Your implementation is actually more efficient than what was suggested, as it updates both the completion status and retry status in a single database call. Great work!
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (2)
501-502:⚠️ Potential issueRemove unused variable.
The variable
callCounteris initialized but never updated, yet it's used in comparisons later.- int callCounter = 0;This variable should be removed as it causes logical errors in the retry logic. Instead, always use
grievanceCallStatus.getCallCounter()for comparisons.
561-568:⚠️ Potential issueFix the max attempts condition and update logic.
The condition checks
grievanceCallStatus.getCallCounter()against the configuration value, but the retry status is not properly updated in the database.- } else if (grievanceCallStatus.getCallCounter()== grievanceAllocationRetryConfiguration) { + } else if (grievanceCallStatus.getCallCounter() >= grievanceAllocationRetryConfiguration) { // Max attempts reached, no further reattempt grievanceCallStatus.setRetryNeeded(false); - updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, grievanceCallStatus.getRetryNeeded(), complaintID, userID, beneficiaryRegID, providerServiceMapId); + updateCount = grievanceDataRepo.updateCompletedStatusInCall(isCompleted, false, complaintID, userID, beneficiaryRegID, providerServiceMapId); + // Also update the call counter + updateCallCounter = grievanceDataRepo.updateCallCounter(grievanceCallStatus.getCallCounter(), false, complaintID, + beneficiaryRegID, providerServiceMapId, userID); response = "max_attempts_reached"; // Indicate that max attempts are reached
🧹 Nitpick comments (4)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (4)
485-487: Transaction management could be improved.The method is correctly annotated with @transactional, but there's no explicit transaction rollback strategy if operations fail.
Consider adding specific transaction handling for error cases, such as using
@Transactional(rollbackFor = Exception.class)to ensure transactions roll back on any exception.
521-523: Add null check before accessing CallType properties.There's no validation that the call type data was successfully retrieved before accessing its properties.
- callTypeObj.setCallGroupType((String) object[0]); - callTypeObj.setCallType((String) object[1]); + if (object[0] != null) { + callTypeObj.setCallGroupType((String) object[0]); + } + if (object[1] != null) { + callTypeObj.setCallType((String) object[1]); + }
576-578: Improve exception handling.The exception handling could be more robust with proper logging and specific handling for different types of exceptions.
- catch (Exception e) { - response = "error: " + e.getMessage(); - } + catch (Exception e) { + logger.error("Error completing grievance call: " + e.getMessage(), e); + response = "error: " + e.getMessage(); + // Consider adding specific handling for different exception types + }
485-581: Consider using constants for response messages.The method uses hardcoded strings like "max_attempts_reached", "no_reattempt_needed", which should be constants for maintainability.
Define constants at the class level for these response messages:
private static final String RESPONSE_SUCCESS = "Successfully closing call"; private static final String RESPONSE_FAILURE = "failure"; private static final String RESPONSE_MAX_ATTEMPTS = "max_attempts_reached"; private static final String RESPONSE_NO_RETRY = "no_reattempt_needed";Then use these constants throughout the method.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/main/java/com/iemr/common/data/grievance/.gitignore(1 hunks)src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java(3 hunks)src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java(5 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/main/java/com/iemr/common/data/grievance/.gitignore
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/com/iemr/common/repository/grievance/GrievanceDataRepo.java
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Package-test
- GitHub Check: Analyze (java)
- GitHub Check: Build
🔇 Additional comments (6)
src/main/java/com/iemr/common/service/grievance/GrievanceDataSyncImpl.java (6)
9-9: Ensure imports are appropriate for the new functionality.The new imports correctly support the added functionality for handling grievance calls. The imports include necessary classes like
HashSet,CallType,EverwellDetails, andGrievanceCallRequest.Also applies to: 36-41
71-82: Constructor dependency injection is properly implemented.The IEMRCalltypeRepositoryImplCustom is correctly injected as a dependency via constructor injection, following good practices.
103-104: Configuration value added for retry logic.The grievanceAllocationRetryConfiguration is correctly injected from application properties to control the maximum number of retry attempts.
534-543: Logic for determining retry needs is appropriate.The implementation correctly determines when a call requires retrying based on the call group type and specific call type.
547-548: Fix the call counter comparison logic.The current code compares the local variable
callCounter(initialized to 0 and never updated) instead of using the actual counter fromgrievanceCallStatus.
549-560: Good implementation of counter increment and update logic.The counter increment and database update logic is properly implemented with appropriate error handling.
|
* adding changes related to encryption and decryption * making final field static * making enclosing method static * adding beneficiaryConsent param to createFeedback API * Update src/main/java/com/iemr/common/data/feedback/FeedbackDetails.java Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * adding beneficiary consent param feedbacklist response * adding space * adding code for schedule for grievance data sync * adding code rabbit code suggestions * adding code rabbit suggestions * code rabbit suggested changes to Model classes * adding sonar quality changes * adding sonar quality code suggestions * adding sonar quality check suggestions * adding code rabbit suggestions * adding constant instead of duplicate literals * adding cod changs to fetch unallocated grievance count * adding changes suggested by sonar quality check * adding code rabbit suggested changes * fixing config file * fixing space * fixing space issue * adding package for PrimaryDBConfig * adding code changes for allocate API for allocating grievance to agents * removing space * adding language related changes * add language related changes * adding name convention related changes * adding code rabbit changes * adding sonar quality check suggested changes * removing unused imports * adding properties related to Grievance in properties file * placing the placeholder for jwt secret key * Update package.yml updating upload artifact version to v4 * removing grievanc related properties from application properties file * adding space * removing extra space * adding code for API that fetches grievance outbound worklist * adding code rabbit suggested changes * another addition of code rabbit suggested changes * fixing row no * adding code for API to save complaint resolution and remarks in the db * adding code rabbit suggested changes * removing lastModDate as it will update automatically in db * changing variable name of assignedUserID to userID * fixing remarks * removing full stop * adding code for API to close call and make reattempts if needed * adding code changes suggested by code rabbit * adding code rabbit suggested changes * adding code rabbit fixes * adding code rabbit fixes * Delete src/main/java/com/iemr/common/data/grievance/.gitignore * AMM-1148 | Close call API including reattempt logic based on calltype (#164) * adding code for API to close call and make reattempts if needed * adding code changes suggested by code rabbit * adding code rabbit suggested changes * adding code rabbit fixes * adding code rabbit fixes * Delete src/main/java/com/iemr/common/data/grievance/.gitignore --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * removing unused literal in repo class * changing logic of Close call after discussion * adding changes related to invalid and wrong number call type * adding code for API to push back grievance data to GR team * removed unnecessary conditions * adding code rabbit changes * adding code rabbit suggestions * adding required null checks * adding code rabbit suggested changes * removing unnecessary Exception * AMM-1149 | API to push back Grievance data to the GR team (#166) * adding code for API to push back grievance data to GR team * removed unnecessary conditions * adding code rabbit changes * adding code rabbit suggestions * adding required null checks * adding code rabbit suggested changes * removing unnecessary Exception --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * adding code changes for variable name change of lang * adding code changes for grievance issues * adding code changes for grievance issues (#168) Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * adding fixes related to grievance related APIs * fixing code rabbit issues * adding code fixes related to scheduler --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: SR20290919 <SR20290919@192.168.1.34> Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B.wipro.com>
…tion (#190) * adding changes related to encryption and decryption * making final field static * making enclosing method static * adding beneficiaryConsent param to createFeedback API * Update src/main/java/com/iemr/common/data/feedback/FeedbackDetails.java Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * adding beneficiary consent param feedbacklist response * adding space * adding code for schedule for grievance data sync * adding code rabbit code suggestions * adding code rabbit suggestions * code rabbit suggested changes to Model classes * adding sonar quality changes * adding sonar quality code suggestions * adding sonar quality check suggestions * adding code rabbit suggestions * adding constant instead of duplicate literals * adding cod changs to fetch unallocated grievance count * adding changes suggested by sonar quality check * adding code rabbit suggested changes * fixing config file * fixing space * fixing space issue * adding package for PrimaryDBConfig * adding code changes for allocate API for allocating grievance to agents * removing space * adding language related changes * add language related changes * adding name convention related changes * adding code rabbit changes * adding sonar quality check suggested changes * removing unused imports * adding properties related to Grievance in properties file * placing the placeholder for jwt secret key * Update package.yml updating upload artifact version to v4 * removing grievanc related properties from application properties file * adding space * removing extra space * adding code for API that fetches grievance outbound worklist * adding code rabbit suggested changes * another addition of code rabbit suggested changes * fixing row no * adding code for API to save complaint resolution and remarks in the db * adding code rabbit suggested changes * removing lastModDate as it will update automatically in db * changing variable name of assignedUserID to userID * fixing remarks * removing full stop * adding code for API to close call and make reattempts if needed * adding code changes suggested by code rabbit * adding code rabbit suggested changes * adding code rabbit fixes * adding code rabbit fixes * Delete src/main/java/com/iemr/common/data/grievance/.gitignore * AMM-1148 | Close call API including reattempt logic based on calltype (#164) * adding code for API to close call and make reattempts if needed * adding code changes suggested by code rabbit * adding code rabbit suggested changes * adding code rabbit fixes * adding code rabbit fixes * Delete src/main/java/com/iemr/common/data/grievance/.gitignore --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * removing unused literal in repo class * changing logic of Close call after discussion * adding changes related to invalid and wrong number call type * adding code for API to push back grievance data to GR team * removed unnecessary conditions * adding code rabbit changes * adding code rabbit suggestions * adding required null checks * adding code rabbit suggested changes * removing unnecessary Exception * AMM-1149 | API to push back Grievance data to the GR team (#166) * adding code for API to push back grievance data to GR team * removed unnecessary conditions * adding code rabbit changes * adding code rabbit suggestions * adding required null checks * adding code rabbit suggested changes * removing unnecessary Exception --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * adding code changes for variable name change of lang * adding code changes for grievance issues * adding code changes for grievance issues (#168) Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> * adding fixes related to grievance related APIs * fixing code rabbit issues * adding code fixes related to scheduler * Scheduler changes * adding import * adding grievance sms template changes * removing space --------- Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: SR20290919 <SR20290919@192.168.1.34> Co-authored-by: SR20290919 <SR20290919@APL-PG02PW8B.wipro.com> Co-authored-by: Ravi Shanigarapu <ravi.shanigarapu@wipro.com>
📋 Description
JIRA ID: 1148
Close call API including reattempt logic based on calltype
Please provide a summary of the change and the motivation behind it. Include relevant context and details.
✅ Type of Change
ℹ️ Additional Information
Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.
Summary by CodeRabbit