CSC/ECE 517 Spring 2023 -E2339. Reimplement signed up teams controller and sign up topics controller.rb

Introduction

The content of this page provides details on the adjustments needed for the "sign_up_topics controller" and the development of a new "signed_up_teams_controller" in the process of re-implementing the expertiza based open-source software project.

Implemented Work

As a component of program 3, it was agreed to partition the sign-up topic controller in Expertiza into two distinct controllers, namely "sign_up_topics_controller" and "signed_up_teams_controller". The implementation for the former has already been executed.The diagram presented below offers a visual depiction of the previously mentioned details.

Design Improvements for "sign_up_topics controller"

Improvement 1:
We propose to add the filtering functionality to the existing index method of the sign_up_topics. The filter functionality will allow users to retrieve a subset of sign_up_topics based on certain criteria such as assignment ID and topic identifiers. This will improve the usability of the API and provide more flexibility to the user in retrieving data.

Rationale:
The index method currently retrieves all sign_up_topics and returns them in the response. However, in many cases, the user may only want to retrieve a subset of sign_up_topics that meet certain criteria. By adding the filter functionality, users can retrieve the data they need more efficiently and effectively. Additionally, the filter functionality will follow a RESTful approach and be consistent with the existing API design. It will allow users to specify the filtering criteria as query parameters in the URL, which is a common convention in RESTful APIs. By making this decision, we don't have to expose a separate endpoint for the filtering functionality like it is being currently done. Furthermore, the filter functionality will be implemented using a private method get_selected_topics that uses the where method to retrieve the desired sign_up_topics based on the filtering criteria. The resulting data will be returned in the response as a JSON object. Overall, the addition of the filtering functionality to the index method will enhance the usability and flexibility of the API, and will be consistent with RESTful API design principles.

method name	description	improvement
filter	filters topics based on assignment id (required) and topic identifiers (optional)	move to index

Current implementation:

 # GET /sign_up_topics
 def index
   @sign_up_topics = SignUpTopic.all
   render json: @sign_up_topics
 end

 def filter
   get_selected_topics
   render json: {message: 'All selected topics have been loaded successfully.', sign_up_topics: @stopics}, status: 200
 end

 private
 def get_selected_topics
   if params[:assignment_id].nil?
     render json: {message: 'Assignment ID is required!' }, status: :unprocessable_entity
   elsif params[:topic_ids].nil?
     @stopics = SignUpTopic.where(assignment_id: params[:assignment_id])
   else
     @stopics = SignUpTopic.where(assignment_id: params[:assignment_id], topic_identifier: params[:topic_ids])
   end
 end

Improved implementation:
Will be added in the future once we implement it.

Improvement 2:
We also propose to add the filtering functionality for the deleting of topics to the existing destroy method of the sign_up_topics same as for the index method.

Rationale:
The "delete_filter" method and the "destroy" method both perform similar actions, which is to delete a sign up topic. Therefore, it makes sense to combine them into a single method to reduce code duplication and improve the maintainability of the codebase.

By merging the two methods, we can eliminate the need for a separate route and controller action to handle the deletion of sign up topics based on specific criteria. The combined method can handle all types of deletion requests, whether it is deleting a single sign up topic or multiple topics based on specific criteria.

Furthermore, by consolidating the functionality into a single method, we can reduce the complexity of the controller and make it easier to understand and maintain in the future. This simplification can also lead to improved performance and reduced resource consumption, as fewer controller actions need to be executed to achieve the same result.

method name	description	improvement
delete_filter	deletes topics based on assignment id (required) and topic identifiers (optional)	move to destroy

Current implementation:

 def destroy
   if @sign_up_topic.destroy
     render json: {message: "The topic has been deleted successfully. "}, status: 200
   else
     render json: @sign_up_topic.errors, status: :unprocessable_entity
   end
 end

 def delete_filter
   #filters topics based on assignment id (required) and topic identifiers (optional)
   get_selected_topics
   @stopics.each(&:delete)
   render json: {message: 'All selected topics have been deleted successfully.', sign_up_topics: @stopics }, status: 200
 end

Improved implementation:
Will be added in the future once we implement it.

Improvement 3:
Making the tests thorough and robust. Check the changes in data after performing operations and also checking the valid response statuses.

Rationale:
1. The existing tests will need to be modified to reflect the changes mentioned in aforementioned design decisions. That includes getting rid of the tests for filter and delete_filter endpoints. The existing tests for GET and DELETE will be modified accordingly.

2. We will add appropriate response statuses to each test. For e.g., returning '204 No Content' for the delete test when the topic is deleted successfully rather than using '200 OK' status.

3. We will make each test robust by making sure the changes after performing certain operations are getting reflected. For e.g., Testing that the response body does not contain the deleted sign-up topic data after the delete request is successful.

Current implementation:

Current implementation of DELETE test:

Improved implementation:
Will be added in the future once we implement it.

4. The controller name will be changed to signup_topics_controller to ensure it is spelled as a single word to follow proper naming conventions.

Signed Up teams Controller

The signed up teams controller will be having the following functionalities

Index - this will filter the topics based on the team ID.

Create - this will create a sign up team.

Update - this will update the signed up team.

Delete - this will destroy the signed up team.

A basic E/R Diagram for the same is shown :

Future Plan

The proposed implementation approach will prioritize the following hierarchy:

1.The sign up topic controller will be refined to facilitate smooth merging into the code.

2. Development efforts will be directed towards the signed up teams controller, utilizing the aforementioned design as a foundation. While the design may undergo revisions, the core functionalities will remain consistent.

3. Finally, the front-end will be implemented.

Relevant Links (previous implementation)

Github Repository: https://github.com/anuj672/reimplementation-back-end
Pull Request: https://github.com/expertiza/reimplementation-back-end/pull/25
Video1 : https://youtu.be/ZAh80Gj5A5U
Video2: https://youtu.be/1IFXC7DAljI

Group

Mentored by

Krishna Saurabh Vankadaru

Group members

Anuj Naresh Chetwani

Indira Pimpalkhare

Tejas Prabhu