Refactor ResponseMaps: Centralize Submission Handling, Automate Feedback Emails, and Model Enhancements

[konetichandrakant]

PR Description:

Overview:

This PR enhances the response_maps_controller.rb, feedback_response_map_controller.rb, response.rb, and response_map.rb to establish a centralized system for handling response submissions and feedback notifications. Instead of separately managing submission logic in different controllers, response_maps_controller.rb now acts as the unified controller, ensuring consistent behavior when a response is created, updated, or submitted. This required careful coordination with the response.rb and response_map.rb models to maintain correct associations, handle submission flags, and automate email notifications reliably. Additionally, the FeedbackEmailService was moved into the mailers directory and the new FeedbackEmailMailer was introduced to handle email composition and delivery separately.

Key Changes:

• Updated response_maps_controller.rb:

  • Centralized submission handling and feedback email triggering across both normal responses and feedback responses.
  • Integrated FeedbackEmailMailer to trigger email after a response is marked as submitted.
  • Exposed the is_submitted flag to allow marking submissions during create/update.
  • Extracted save and email logic into persist_and_respond and handle_submission helper methods to improve code reusability.

• Updated feedback_response_maps_controller.rb:

  • Simplified logic by relying on the centralized handling from response_maps_controller.rb to send feedback emails upon response submission.

• Updated response Model:

  • Delegated reviewee and reviewer retrieval to the associated response_map to ensure a consistent access pattern.
  • Participated in the new submission flow triggered from the centralized controller.

• Updated response_map Model:

  • Permitted :type in strong parameters to support Single Table Inheritance (STI) for different types of response maps.
  • Ensured reviewer, reviewee, and assignment associations remained intact to support clean email generation and response tracking.

Testing Challenges:

The transition to centralized submission handling highlighted testing difficulties because of the strong interdependencies between database models. Here’s why:

• Complex Database Relationships:

  • Submissions rely on connections between ResponseMap, Response, Participant, and Assignment, making unit isolation challenging without proper setup.

• Authentication and Validation Constraints:

  • Existing authentication filters had to be bypassed to prevent 401 errors during request specs.
  • Validation rules in models like ResponseMap and Response enforced constraints that complicated direct mocking in unit tests.

Conclusion:

This PR significantly improves the system’s maintainability, scalability, and consistency by introducing a centralized mechanism for managing response submissions and feedback email notifications. Changes to response.rb and response_map.rb were essential to support this new centralized flow—ensuring that all related entities (reviewer, reviewee, assignment) could be accurately accessed through delegation and that responses could correctly participate in submission and notification logic across different types of maps. With these improvements, the system is now more modular, easier to test, and ready for future extensions.