Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2026

2026-03-25T18:52:35Z

Kgudipe:

* [[CSC/ECE 517 Spring 2026 - E2602. Reimplement student task view]]
* [[CSC/ECE 517 Spring 2026 - E2604. Finish Password Resets]]

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb

2024-04-30T17:02:41Z

Kgudipe: /* "Assignment of a particular Participant Method" Commit */

__TOC__

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] stands out as an open-source initiative rooted in the Ruby on Rails framework, brought to life through the collective efforts of NC State's faculty and students. This web application supports instructors in creating tailored assignments that can either be new or build upon existing ones. Moreover, it allows for the organization of topics into a roster for student selection. Expertiza offers students the chance to team up for joint projects and assignments, promoting collaborative learning. A key feature of this platform is enabling students to peer-review their colleagues' work.

With its capability to handle a wide variety of document types, Expertiza accepts submissions in formats ranging from URLs to wiki pages. As an open-source learning management system crafted with Ruby on Rails, it boasts a broad range of features that facilitate the submission and peer review of diverse learning materials, including articles, code, and websites. Instructors and teaching assistants can easily monitor and evaluate these submissions, making Expertiza a valuable tool for managing course assignments.

==Introduction==
To develop the backend functionality for the participants controller of Expertiza, ensuring seamless integration with the enhanced user interface for participants. This involves setting up API endpoints for CRUD (Create, Read, Update, Delete) operations, integrating with the database, and ensuring data integrity and security. Our focus includes thorough rswag testing of the participants_controller method and demonstrating Swagger UI integration.

==Problem Statement==
The reimplementation project entails:
#CRUD Operations: Setting up CRUD (Create, Read, Update, Delete) functionalities in the controller to streamline data handling.
#Routes: Establishing pathways for accessing actions within the participants controller.
#Database: Maintaining a database for participant information, including their connections to "Assignment".
#Adherence to DRY Principle: Adhering to the Don't Repeat Yourself (DRY) principle to minimize redundancy and enhance coding efficiency.
#Testing with RSwag: Developing detailed tests using RSwag for every controller action, ensuring their performance and compatibility with Swagger UI. This includes a video tutorial to illustrate the integration with Swagger UI and the operational efficiency of the revamped controller.

== Design ==
[[File:Design_img.jpg|1000px]]

=Implementation of Participants Controller=

The Participants Controller is designed to handle various interactions with participant data within an application, providing a range of RESTful actions. This controller facilitates operations such as listing all participants, retrieving specific participant details, and creating, updating, or deleting participant records, all through JSON responses suitable for API usage. It includes actions that are traditionally used in view-based controllers (such as new and edit) to instantiate and prepare participants for creation or editing. Additionally, the controller offers a specialized action to fetch and render a participant's assignment, enhancing its functionality by addressing specific data retrieval needs. It also implements global error handling for missing records, ensuring that all actions gracefully handle cases where participants are not found. This comprehensive approach makes the controller a central part of the participant management system in the application, equipped to handle both standard CRUD operations and specific relational data accesses in a structured and efficient manner.

==Implemented methods==

===="Create Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def create
@participant = Participant.new(participant_params)
if @participant.save
render json: @participant, status: :created
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>create</code> action will handle the addition of new participants. It will take participant information, conducts security validations, ensures data integrity, and inserts the new record into the database, responding with the participant's details in JSON format or an error message if the process fails.

===="Read Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def index
@participants = Participant.all
render json: { participants: @participants }, status: :ok
end

<code>index</code> action will accept a participant ID, retrieves the corresponding data from the database, and returns it as a JSON object. If the participant does not exist, it will send an error message.

===="Update Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def update
@participant = Participant.find(params[:id])
if @participant.update(participant_params)
render json: { participant: @participant }, status: :ok
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>update</code> action will require a participant ID and the new data to be provided. The method will update the relevant record after security and data validation checks and returns the updated information in JSON format.

===="Delete Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def destroy
@participant = Participant.find(params[:id])
@participant.destroy
render json: { message: "Participant was successfully destroyed." }, status: :ok
end

<code>delete</code> action will remove a participant's record using their ID, ensuring that the request is authenticated and the user is authorized to perform the deletion. Upon successful deletion, it will confirm the action with a success response; otherwise, it returns an error.

===="Participants of a particular assignment Method" [https://github.com/expertiza/reimplementation-back-end/commit/b3647df49ee0a2863d9afe23b6711680650e9e25 Commit]====

def fetch_participants_for_assignment
participants = Participant.where(assignment_id: params[:assignment_id])
render json: participants, status: :ok
end

The <code>fetch_participants_for_assignment</code> method will receive an assignment ID, this method will join the pertinent records from the participants and assignments tables, retrieving a comprehensive dataset that is then converted into a JSON array. This method will be instrumental for scenarios where a holistic view of assignment participation is required.

===="Assignment of a particular Participant Method" [https://github.com/expertiza/reimplementation-back-end/commit/dda3fba2d9ae2dacf1d5ad638d57e2189b17e781 Commit]====

def fetch_assignment_for_participant
participant = Participant.find(params[:participant_id])
assignment = participant.assignment

render json: assignment, status: :ok
rescue ActiveRecord::RecordNotFound
render json: { error: "Participant not found" }, status: :not_found
end

The <code>fetch_assignment_for_participant</code> method is designed to retrieve the assignment associated with a specific participant. It takes a participant ID from the request parameters, finds the corresponding participant record, and accesses its associated assignment. The assignment data is then rendered as a JSON object.

== Design Principles ==

==== Single Responsibility Principle (SRP): ====
*Every function within the ParticipantsController will handle a distinct aspect of participant management.
*The functions will undergo restructuring to delineate responsibilities like fetching data, performing calculations, and presenting views.
*As an illustration, the view function will be dedicated to acquiring participant information.

==== Don't Repeat Yourself (DRY) Principle: ====
*Redundant code within the ParticipantsController will be reduced by moving shared functionalities into auxiliary methods or modules.

==== Encapsulation: ====
*The ParticipantsController will organize data and functionality into suitable methods and classes to reduce dependencies.
*The scope of access to instance variables and controller actions will be restricted to foster encapsulation and ensure a clear division of responsibilities.

=Testing Plan=
We employ a combination of manual testing with tools like Postman, automated testing through RSpec, and API documentation and testing using Swagger. This comprehensive approach allows us to validate our API's functionality, security, and usability across various scenarios.

==Manual testing with Postman==

We are using Postman to test our APIs during the development process.
Below are few examples:

*GET /api/v1/participants: Endpoint to test the fetching of all Participants.

[[File:GET.png|500px]]

Fig 5.1.1 Postman UI displaying API testing to fetch all Participant.

*POST /api/v1/participants: Endpoint to test the creation of a Participant.

[[File:POST.png|500px]]

Fig 5.1.2 Postman UI displaying API testing to create a Partcipant.

*PATCH api/v1/participants/4: Endpoint to test the functionality of updating Participant using its ID.

[[File:PATCH.png|500px]]

Fig 5.1.3 Postman UI displaying API testing to update a Participant using its ID.

*DELETE api/v1/participants/4: Endpoint to test the functionality of deleting a Participant with participant id.

[[File:DELETE.png|500px]]

Fig 5.1.4 Postman UI displaying API testing to delete a Participant using its ID.

*GET api/v1/assignments/1/participants: Endpoint to test the functionality of fetching a participant using assignment Id.

[[File:Assignment Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch a participant using assignment Id.

*GET api/v1/participants/1/assignment: Endpoint to test the functionality of fetching an assignment using participant Id.

[[File:Participant Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch an assignment using participant Id.

==Automated Testing with Rspec==
====Scenario 1: Creating a New Participant====
Validates the creation of a new Participant with appropriate parameters.

Expectation: Expects a 201 Created status and a JSON response with the created participant details.

describe "POST #create" do
context "with valid parameters" do
it "creates a new participant" do
expect {
post :create, params: { participant: attributes_for(:participant) }
}.to change(Participant, :count).by(1)
expect(response).to have_http_status(:created)
end
end
end

====Scenario 2: Handling Invalid Participant Creation====
Tests the creation process with invalid parameters to ensure robust error handling.

Expectation: Expects a 400 Bad Request status and an error message detailing the invalid parameters.

context "with invalid parameters" do
it "does not create a new participant" do
expect {
post :create, params: { participant: { user_id: nil } }
}.to change(Participant, :count).by(0)
expect(response).to have_http_status(:unprocessable_entity)
end
end

====Scenario 3: Fetch a Participant who is not in the database====
Checks the behaviour when attempting to fetch a Participant not present in the database.

Expectation: Expects a not found status

context "when the participant does not exist" do
it "returns a not found status" do
get :show, params: { id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 4: Fetching an Assignment of a particular Participant====
Validates the functionality for fetching an Assignment of a particular Participant Id
Expectation: Expects a 200 Ok status with the assignment of the participant.

describe "#participant_assignment" do
context "when participant exists" do
it "returns the assignment of the participant" do
get :participant_assignment, params: { participant_id: participant.id }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 5: Fetching an Assignment of an invalid Participant====
Validates the functionality for fetching an Assignment of an Invalid Participant Id

Expectation: Expects a not found status status.

context "when participant does not exist" do
it "returns not found status" do
get :participant_assignment, params: { participant_id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 6: Updating a Participant====
Ensures that an existing participant can be updated with valid parameters.

Expectation: Expects a 200 OK status and the updated participant details in the response.

describe "PATCH/PUT #update" do
context "with valid parameters" do
it "updates the participant" do
patch :update, params: { id: participant.id, participant: { type: "NewType" } }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 7: Updating a Participant====
Checks the behavior when attempting to update a participant with invalid parameters.

Expectation: Expects a 422 Unprocessable Entity status and an error message detailing the issue.

context "with invalid parameters" do
it "does not update the participant" do
patch :update, params: { id: participant.id, participant: { user_id: nil } }
expect(response).to have_http_status(:unprocessable_entity)
end
end

==API Documentation and Testing with Swagger==
To provide clear, interactive API documentation, facilitating easy understanding and testing of API endpoints.

Setup: Integrate Swagger with Rails application using gems like rswag.

Documentation: Annotate the API code to generate Swagger documentation automatically. Ensure that each endpoint is clearly described, with information on parameters, request bodies, and response schemas.
Interactive Testing: Use the Swagger UI to interactively test API endpoints directly from the browser, providing an easy way for non-developers to understand and verify API functionality.

                                                                 [[File:SWAGGER.png|750px]]

                                                                       Fig 5.3 Swagger UI displaying API documentation and interactive testing interface for Participants endpoints.

=Relevant Links=
* '''Github Repository:''' https://github.com/achitti2812/expertiza_project4
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/105
* '''Test Video Link:''' https://youtu.be/hwGuzbqcyjQ

==Team==
=====Mentor=====
*Chunduru Chetana

=====Members=====
*Akhilsai Chittipolu
*Koushik Gudipelly
*Sri Vaishnavi Mylavarapu

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb

2024-04-30T17:02:13Z

Kgudipe: /* "Participants of a particular assignment Method" Commit */

__TOC__

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] stands out as an open-source initiative rooted in the Ruby on Rails framework, brought to life through the collective efforts of NC State's faculty and students. This web application supports instructors in creating tailored assignments that can either be new or build upon existing ones. Moreover, it allows for the organization of topics into a roster for student selection. Expertiza offers students the chance to team up for joint projects and assignments, promoting collaborative learning. A key feature of this platform is enabling students to peer-review their colleagues' work.

With its capability to handle a wide variety of document types, Expertiza accepts submissions in formats ranging from URLs to wiki pages. As an open-source learning management system crafted with Ruby on Rails, it boasts a broad range of features that facilitate the submission and peer review of diverse learning materials, including articles, code, and websites. Instructors and teaching assistants can easily monitor and evaluate these submissions, making Expertiza a valuable tool for managing course assignments.

==Introduction==
To develop the backend functionality for the participants controller of Expertiza, ensuring seamless integration with the enhanced user interface for participants. This involves setting up API endpoints for CRUD (Create, Read, Update, Delete) operations, integrating with the database, and ensuring data integrity and security. Our focus includes thorough rswag testing of the participants_controller method and demonstrating Swagger UI integration.

==Problem Statement==
The reimplementation project entails:
#CRUD Operations: Setting up CRUD (Create, Read, Update, Delete) functionalities in the controller to streamline data handling.
#Routes: Establishing pathways for accessing actions within the participants controller.
#Database: Maintaining a database for participant information, including their connections to "Assignment".
#Adherence to DRY Principle: Adhering to the Don't Repeat Yourself (DRY) principle to minimize redundancy and enhance coding efficiency.
#Testing with RSwag: Developing detailed tests using RSwag for every controller action, ensuring their performance and compatibility with Swagger UI. This includes a video tutorial to illustrate the integration with Swagger UI and the operational efficiency of the revamped controller.

== Design ==
[[File:Design_img.jpg|1000px]]

=Implementation of Participants Controller=

The Participants Controller is designed to handle various interactions with participant data within an application, providing a range of RESTful actions. This controller facilitates operations such as listing all participants, retrieving specific participant details, and creating, updating, or deleting participant records, all through JSON responses suitable for API usage. It includes actions that are traditionally used in view-based controllers (such as new and edit) to instantiate and prepare participants for creation or editing. Additionally, the controller offers a specialized action to fetch and render a participant's assignment, enhancing its functionality by addressing specific data retrieval needs. It also implements global error handling for missing records, ensuring that all actions gracefully handle cases where participants are not found. This comprehensive approach makes the controller a central part of the participant management system in the application, equipped to handle both standard CRUD operations and specific relational data accesses in a structured and efficient manner.

==Implemented methods==

===="Create Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def create
@participant = Participant.new(participant_params)
if @participant.save
render json: @participant, status: :created
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>create</code> action will handle the addition of new participants. It will take participant information, conducts security validations, ensures data integrity, and inserts the new record into the database, responding with the participant's details in JSON format or an error message if the process fails.

===="Read Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def index
@participants = Participant.all
render json: { participants: @participants }, status: :ok
end

<code>index</code> action will accept a participant ID, retrieves the corresponding data from the database, and returns it as a JSON object. If the participant does not exist, it will send an error message.

===="Update Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def update
@participant = Participant.find(params[:id])
if @participant.update(participant_params)
render json: { participant: @participant }, status: :ok
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>update</code> action will require a participant ID and the new data to be provided. The method will update the relevant record after security and data validation checks and returns the updated information in JSON format.

===="Delete Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def destroy
@participant = Participant.find(params[:id])
@participant.destroy
render json: { message: "Participant was successfully destroyed." }, status: :ok
end

<code>delete</code> action will remove a participant's record using their ID, ensuring that the request is authenticated and the user is authorized to perform the deletion. Upon successful deletion, it will confirm the action with a success response; otherwise, it returns an error.

===="Participants of a particular assignment Method" [https://github.com/expertiza/reimplementation-back-end/commit/b3647df49ee0a2863d9afe23b6711680650e9e25 Commit]====

def fetch_participants_for_assignment
participants = Participant.where(assignment_id: params[:assignment_id])
render json: participants, status: :ok
end

The <code>fetch_participants_for_assignment</code> method will receive an assignment ID, this method will join the pertinent records from the participants and assignments tables, retrieving a comprehensive dataset that is then converted into a JSON array. This method will be instrumental for scenarios where a holistic view of assignment participation is required.

===="Assignment of a particular Participant Method" [https://github.com/expertiza/reimplementation-back-end/commit/dda3fba2d9ae2dacf1d5ad638d57e2189b17e781 Commit]====

def participant_assignment
participant = Participant.find(params[:participant_id])
assignment = participant.assignment

render json: assignment, status: :ok
rescue ActiveRecord::RecordNotFound
render json: { error: "Participant not found" }, status: :not_found
end

The <code>participant_assignment</code> method is designed to retrieve the assignment associated with a specific participant. It takes a participant ID from the request parameters, finds the corresponding participant record, and accesses its associated assignment. The assignment data is then rendered as a JSON object.

== Design Principles ==

==== Single Responsibility Principle (SRP): ====
*Every function within the ParticipantsController will handle a distinct aspect of participant management.
*The functions will undergo restructuring to delineate responsibilities like fetching data, performing calculations, and presenting views.
*As an illustration, the view function will be dedicated to acquiring participant information.

==== Don't Repeat Yourself (DRY) Principle: ====
*Redundant code within the ParticipantsController will be reduced by moving shared functionalities into auxiliary methods or modules.

==== Encapsulation: ====
*The ParticipantsController will organize data and functionality into suitable methods and classes to reduce dependencies.
*The scope of access to instance variables and controller actions will be restricted to foster encapsulation and ensure a clear division of responsibilities.

=Testing Plan=
We employ a combination of manual testing with tools like Postman, automated testing through RSpec, and API documentation and testing using Swagger. This comprehensive approach allows us to validate our API's functionality, security, and usability across various scenarios.

==Manual testing with Postman==

We are using Postman to test our APIs during the development process.
Below are few examples:

*GET /api/v1/participants: Endpoint to test the fetching of all Participants.

[[File:GET.png|500px]]

Fig 5.1.1 Postman UI displaying API testing to fetch all Participant.

*POST /api/v1/participants: Endpoint to test the creation of a Participant.

[[File:POST.png|500px]]

Fig 5.1.2 Postman UI displaying API testing to create a Partcipant.

*PATCH api/v1/participants/4: Endpoint to test the functionality of updating Participant using its ID.

[[File:PATCH.png|500px]]

Fig 5.1.3 Postman UI displaying API testing to update a Participant using its ID.

*DELETE api/v1/participants/4: Endpoint to test the functionality of deleting a Participant with participant id.

[[File:DELETE.png|500px]]

Fig 5.1.4 Postman UI displaying API testing to delete a Participant using its ID.

*GET api/v1/assignments/1/participants: Endpoint to test the functionality of fetching a participant using assignment Id.

[[File:Assignment Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch a participant using assignment Id.

*GET api/v1/participants/1/assignment: Endpoint to test the functionality of fetching an assignment using participant Id.

[[File:Participant Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch an assignment using participant Id.

==Automated Testing with Rspec==
====Scenario 1: Creating a New Participant====
Validates the creation of a new Participant with appropriate parameters.

Expectation: Expects a 201 Created status and a JSON response with the created participant details.

describe "POST #create" do
context "with valid parameters" do
it "creates a new participant" do
expect {
post :create, params: { participant: attributes_for(:participant) }
}.to change(Participant, :count).by(1)
expect(response).to have_http_status(:created)
end
end
end

====Scenario 2: Handling Invalid Participant Creation====
Tests the creation process with invalid parameters to ensure robust error handling.

Expectation: Expects a 400 Bad Request status and an error message detailing the invalid parameters.

context "with invalid parameters" do
it "does not create a new participant" do
expect {
post :create, params: { participant: { user_id: nil } }
}.to change(Participant, :count).by(0)
expect(response).to have_http_status(:unprocessable_entity)
end
end

====Scenario 3: Fetch a Participant who is not in the database====
Checks the behaviour when attempting to fetch a Participant not present in the database.

Expectation: Expects a not found status

context "when the participant does not exist" do
it "returns a not found status" do
get :show, params: { id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 4: Fetching an Assignment of a particular Participant====
Validates the functionality for fetching an Assignment of a particular Participant Id
Expectation: Expects a 200 Ok status with the assignment of the participant.

describe "#participant_assignment" do
context "when participant exists" do
it "returns the assignment of the participant" do
get :participant_assignment, params: { participant_id: participant.id }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 5: Fetching an Assignment of an invalid Participant====
Validates the functionality for fetching an Assignment of an Invalid Participant Id

Expectation: Expects a not found status status.

context "when participant does not exist" do
it "returns not found status" do
get :participant_assignment, params: { participant_id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 6: Updating a Participant====
Ensures that an existing participant can be updated with valid parameters.

Expectation: Expects a 200 OK status and the updated participant details in the response.

describe "PATCH/PUT #update" do
context "with valid parameters" do
it "updates the participant" do
patch :update, params: { id: participant.id, participant: { type: "NewType" } }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 7: Updating a Participant====
Checks the behavior when attempting to update a participant with invalid parameters.

Expectation: Expects a 422 Unprocessable Entity status and an error message detailing the issue.

context "with invalid parameters" do
it "does not update the participant" do
patch :update, params: { id: participant.id, participant: { user_id: nil } }
expect(response).to have_http_status(:unprocessable_entity)
end
end

==API Documentation and Testing with Swagger==
To provide clear, interactive API documentation, facilitating easy understanding and testing of API endpoints.

Setup: Integrate Swagger with Rails application using gems like rswag.

Documentation: Annotate the API code to generate Swagger documentation automatically. Ensure that each endpoint is clearly described, with information on parameters, request bodies, and response schemas.
Interactive Testing: Use the Swagger UI to interactively test API endpoints directly from the browser, providing an easy way for non-developers to understand and verify API functionality.

                                                                 [[File:SWAGGER.png|750px]]

                                                                       Fig 5.3 Swagger UI displaying API documentation and interactive testing interface for Participants endpoints.

=Relevant Links=
* '''Github Repository:''' https://github.com/achitti2812/expertiza_project4
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/105
* '''Test Video Link:''' https://youtu.be/hwGuzbqcyjQ

==Team==
=====Mentor=====
*Chunduru Chetana

=====Members=====
*Akhilsai Chittipolu
*Koushik Gudipelly
*Sri Vaishnavi Mylavarapu

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb

2024-04-23T17:29:00Z

Kgudipe: Created page with "__TOC__ ==Expertiza== [http://expertiza.ncsu.edu/ Expertiza] stands out as an open-source initiative rooted in the Ruby on Rails framework, brought to life through the collective efforts of NC State's faculty and students. This web application supports instructors in creating tailored assignments that can either be new or build upon existing ones. Moreover, it allows for the organization of topics into a roster for student selection. Expertiza offers students the chance..."

__TOC__

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] stands out as an open-source initiative rooted in the Ruby on Rails framework, brought to life through the collective efforts of NC State's faculty and students. This web application supports instructors in creating tailored assignments that can either be new or build upon existing ones. Moreover, it allows for the organization of topics into a roster for student selection. Expertiza offers students the chance to team up for joint projects and assignments, promoting collaborative learning. A key feature of this platform is enabling students to peer-review their colleagues' work.

With its capability to handle a wide variety of document types, Expertiza accepts submissions in formats ranging from URLs to wiki pages. As an open-source learning management system crafted with Ruby on Rails, it boasts a broad range of features that facilitate the submission and peer review of diverse learning materials, including articles, code, and websites. Instructors and teaching assistants can easily monitor and evaluate these submissions, making Expertiza a valuable tool for managing course assignments.

==Introduction==
To develop the backend functionality for the participants controller of Expertiza, ensuring seamless integration with the enhanced user interface for participants. This involves setting up API endpoints for CRUD (Create, Read, Update, Delete) operations, integrating with the database, and ensuring data integrity and security. Our focus includes thorough rswag testing of the participants_controller method and demonstrating Swagger UI integration.

==Problem Statement==
The reimplementation project entails:
#CRUD Operations: Setting up CRUD (Create, Read, Update, Delete) functionalities in the controller to streamline data handling.
#Routes: Establishing pathways for accessing actions within the participants controller.
#Database: Maintaining a database for participant information, including their connections to "Assignment".
#Adherence to DRY Principle: Adhering to the Don't Repeat Yourself (DRY) principle to minimize redundancy and enhance coding efficiency.
#Testing with RSwag: Developing detailed tests using RSwag for every controller action, ensuring their performance and compatibility with Swagger UI. This includes a video tutorial to illustrate the integration with Swagger UI and the operational efficiency of the revamped controller.

== Design ==
[[File:Design_img.jpg|1000px]]

=Implementation of Participants Controller=

The Participants Controller is designed to handle various interactions with participant data within an application, providing a range of RESTful actions. This controller facilitates operations such as listing all participants, retrieving specific participant details, and creating, updating, or deleting participant records, all through JSON responses suitable for API usage. It includes actions that are traditionally used in view-based controllers (such as new and edit) to instantiate and prepare participants for creation or editing. Additionally, the controller offers a specialized action to fetch and render a participant's assignment, enhancing its functionality by addressing specific data retrieval needs. It also implements global error handling for missing records, ensuring that all actions gracefully handle cases where participants are not found. This comprehensive approach makes the controller a central part of the participant management system in the application, equipped to handle both standard CRUD operations and specific relational data accesses in a structured and efficient manner.

==Implemented methods==

===="Create Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def create
@participant = Participant.new(participant_params)
if @participant.save
render json: @participant, status: :created
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>create</code> action will handle the addition of new participants. It will take participant information, conducts security validations, ensures data integrity, and inserts the new record into the database, responding with the participant's details in JSON format or an error message if the process fails.

===="Read Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def index
@participants = Participant.all
render json: { participants: @participants }, status: :ok
end

<code>index</code> action will accept a participant ID, retrieves the corresponding data from the database, and returns it as a JSON object. If the participant does not exist, it will send an error message.

===="Update Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def update
@participant = Participant.find(params[:id])
if @participant.update(participant_params)
render json: { participant: @participant }, status: :ok
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>update</code> action will require a participant ID and the new data to be provided. The method will update the relevant record after security and data validation checks and returns the updated information in JSON format.

===="Delete Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def destroy
@participant = Participant.find(params[:id])
@participant.destroy
render json: { message: "Participant was successfully destroyed." }, status: :ok
end

<code>delete</code> action will remove a participant's record using their ID, ensuring that the request is authenticated and the user is authorized to perform the deletion. Upon successful deletion, it will confirm the action with a success response; otherwise, it returns an error.

===="Participants of a particular assignment Method" [https://github.com/expertiza/reimplementation-back-end/commit/b3647df49ee0a2863d9afe23b6711680650e9e25 Commit]====

def assignment_participants
participants = Participant.where(assignment_id: params[:assignment_id])
render json: participants, status: :ok
end

The <code>assignment_participants</code> method will receive an assignment ID, this method will join the pertinent records from the participants and assignments tables, retrieving a comprehensive dataset that is then converted into a JSON array. This method will be instrumental for scenarios where a holistic view of assignment participation is required.

===="Assignment of a particular Participant Method" [https://github.com/expertiza/reimplementation-back-end/commit/dda3fba2d9ae2dacf1d5ad638d57e2189b17e781 Commit]====

def participant_assignment
participant = Participant.find(params[:participant_id])
assignment = participant.assignment

render json: assignment, status: :ok
rescue ActiveRecord::RecordNotFound
render json: { error: "Participant not found" }, status: :not_found
end

The <code>participant_assignment</code> method is designed to retrieve the assignment associated with a specific participant. It takes a participant ID from the request parameters, finds the corresponding participant record, and accesses its associated assignment. The assignment data is then rendered as a JSON object.

== Design Principles ==

==== Single Responsibility Principle (SRP): ====
*Every function within the ParticipantsController will handle a distinct aspect of participant management.
*The functions will undergo restructuring to delineate responsibilities like fetching data, performing calculations, and presenting views.
*As an illustration, the view function will be dedicated to acquiring participant information.

==== Don't Repeat Yourself (DRY) Principle: ====
*Redundant code within the ParticipantsController will be reduced by moving shared functionalities into auxiliary methods or modules.

==== Encapsulation: ====
*The ParticipantsController will organize data and functionality into suitable methods and classes to reduce dependencies.
*The scope of access to instance variables and controller actions will be restricted to foster encapsulation and ensure a clear division of responsibilities.

=Testing Plan=
We employ a combination of manual testing with tools like Postman, automated testing through RSpec, and API documentation and testing using Swagger. This comprehensive approach allows us to validate our API's functionality, security, and usability across various scenarios.

==Manual testing with Postman==

We are using Postman to test our APIs during the development process.
Below are few examples:

*GET /api/v1/participants: Endpoint to test the fetching of all Participants.

[[File:GET.png|500px]]

Fig 5.1.1 Postman UI displaying API testing to fetch all Participant.

*POST /api/v1/participants: Endpoint to test the creation of a Participant.

[[File:POST.png|500px]]

Fig 5.1.2 Postman UI displaying API testing to create a Partcipant.

*PATCH api/v1/participants/4: Endpoint to test the functionality of updating Participant using its ID.

[[File:PATCH.png|500px]]

Fig 5.1.3 Postman UI displaying API testing to update a Participant using its ID.

*DELETE api/v1/participants/4: Endpoint to test the functionality of deleting a Participant with participant id.

[[File:DELETE.png|500px]]

Fig 5.1.4 Postman UI displaying API testing to delete a Participant using its ID.

*GET api/v1/assignments/1/participants: Endpoint to test the functionality of fetching a participant using assignment Id.

[[File:Assignment Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch a participant using assignment Id.

*GET api/v1/participants/1/assignment: Endpoint to test the functionality of fetching an assignment using participant Id.

[[File:Participant Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch an assignment using participant Id.

==Automated Testing with Rspec==
====Scenario 1: Creating a New Participant====
Validates the creation of a new Participant with appropriate parameters.

Expectation: Expects a 201 Created status and a JSON response with the created participant details.

describe "POST #create" do
context "with valid parameters" do
it "creates a new participant" do
expect {
post :create, params: { participant: attributes_for(:participant) }
}.to change(Participant, :count).by(1)
expect(response).to have_http_status(:created)
end
end
end

====Scenario 2: Handling Invalid Participant Creation====
Tests the creation process with invalid parameters to ensure robust error handling.

Expectation: Expects a 400 Bad Request status and an error message detailing the invalid parameters.

context "with invalid parameters" do
it "does not create a new participant" do
expect {
post :create, params: { participant: { user_id: nil } }
}.to change(Participant, :count).by(0)
expect(response).to have_http_status(:unprocessable_entity)
end
end

====Scenario 3: Fetch a Participant who is not in the database====
Checks the behaviour when attempting to fetch a Participant not present in the database.

Expectation: Expects a not found status

context "when the participant does not exist" do
it "returns a not found status" do
get :show, params: { id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 4: Fetching an Assignment of a particular Participant====
Validates the functionality for fetching an Assignment of a particular Participant Id
Expectation: Expects a 200 Ok status with the assignment of the participant.

describe "#participant_assignment" do
context "when participant exists" do
it "returns the assignment of the participant" do
get :participant_assignment, params: { participant_id: participant.id }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 5: Fetching an Assignment of an invalid Participant====
Validates the functionality for fetching an Assignment of an Invalid Participant Id

Expectation: Expects a not found status status.

context "when participant does not exist" do
it "returns not found status" do
get :participant_assignment, params: { participant_id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 6: Updating a Participant====
Ensures that an existing participant can be updated with valid parameters.

Expectation: Expects a 200 OK status and the updated participant details in the response.

describe "PATCH/PUT #update" do
context "with valid parameters" do
it "updates the participant" do
patch :update, params: { id: participant.id, participant: { type: "NewType" } }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 7: Updating a Participant====
Checks the behavior when attempting to update a participant with invalid parameters.

Expectation: Expects a 422 Unprocessable Entity status and an error message detailing the issue.

context "with invalid parameters" do
it "does not update the participant" do
patch :update, params: { id: participant.id, participant: { user_id: nil } }
expect(response).to have_http_status(:unprocessable_entity)
end
end

==API Documentation and Testing with Swagger==
To provide clear, interactive API documentation, facilitating easy understanding and testing of API endpoints.

Setup: Integrate Swagger with Rails application using gems like rswag.

Documentation: Annotate the API code to generate Swagger documentation automatically. Ensure that each endpoint is clearly described, with information on parameters, request bodies, and response schemas.
Interactive Testing: Use the Swagger UI to interactively test API endpoints directly from the browser, providing an easy way for non-developers to understand and verify API functionality.

                                                                 [[File:SWAGGER.png|750px]]

                                                                       Fig 5.3 Swagger UI displaying API documentation and interactive testing interface for Participants endpoints.

=Relevant Links=
* '''Github Repository:''' https://github.com/achitti2812/expertiza_project4
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/105
* '''Test Video Link:''' https://youtu.be/hwGuzbqcyjQ

==Team==
=====Mentor=====
*Chunduru Chetana

=====Members=====
*Akhilsai Chittipolu
*Koushik Gudipelly
*Sri Vaishnavi Mylavarapu

CSC/ECE 517 Spring 2024

2024-04-23T17:28:13Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)

2024-04-23T17:27:44Z

Kgudipe: Undo revision 156032 by Kgudipe (talk)

CSC/ECE 517 Spring 2024

2024-04-23T17:25:11Z

Kgudipe: Undo revision 156039 by Kgudipe (talk)

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

CSC/ECE 517 Spring 2024

2024-04-23T17:24:35Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)

2024-04-23T17:22:09Z

Kgudipe:

__TOC__

==Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] stands out as an open-source initiative rooted in the Ruby on Rails framework, brought to life through the collective efforts of NC State's faculty and students. This web application supports instructors in creating tailored assignments that can either be new or build upon existing ones. Moreover, it allows for the organization of topics into a roster for student selection. Expertiza offers students the chance to team up for joint projects and assignments, promoting collaborative learning. A key feature of this platform is enabling students to peer-review their colleagues' work.

With its capability to handle a wide variety of document types, Expertiza accepts submissions in formats ranging from URLs to wiki pages. As an open-source learning management system crafted with Ruby on Rails, it boasts a broad range of features that facilitate the submission and peer review of diverse learning materials, including articles, code, and websites. Instructors and teaching assistants can easily monitor and evaluate these submissions, making Expertiza a valuable tool for managing course assignments.

==Introduction==
To develop the backend functionality for the participants controller of Expertiza, ensuring seamless integration with the enhanced user interface for participants. This involves setting up API endpoints for CRUD (Create, Read, Update, Delete) operations, integrating with the database, and ensuring data integrity and security. Our focus includes thorough rswag testing of the participants_controller method and demonstrating Swagger UI integration.

==Problem Statement==
The reimplementation project entails:
#CRUD Operations: Setting up CRUD (Create, Read, Update, Delete) functionalities in the controller to streamline data handling.
#Routes: Establishing pathways for accessing actions within the participants controller.
#Database: Maintaining a database for participant information, including their connections to "Assignment".
#Adherence to DRY Principle: Adhering to the Don't Repeat Yourself (DRY) principle to minimize redundancy and enhance coding efficiency.
#Testing with RSwag: Developing detailed tests using RSwag for every controller action, ensuring their performance and compatibility with Swagger UI. This includes a video tutorial to illustrate the integration with Swagger UI and the operational efficiency of the revamped controller.

== Design ==
[[File:Design_img.jpg|1000px]]

=Implementation of Participants Controller=

The Participants Controller is designed to handle various interactions with participant data within an application, providing a range of RESTful actions. This controller facilitates operations such as listing all participants, retrieving specific participant details, and creating, updating, or deleting participant records, all through JSON responses suitable for API usage. It includes actions that are traditionally used in view-based controllers (such as new and edit) to instantiate and prepare participants for creation or editing. Additionally, the controller offers a specialized action to fetch and render a participant's assignment, enhancing its functionality by addressing specific data retrieval needs. It also implements global error handling for missing records, ensuring that all actions gracefully handle cases where participants are not found. This comprehensive approach makes the controller a central part of the participant management system in the application, equipped to handle both standard CRUD operations and specific relational data accesses in a structured and efficient manner.

==Implemented methods==

===="Create Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def create
@participant = Participant.new(participant_params)
if @participant.save
render json: @participant, status: :created
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>create</code> action will handle the addition of new participants. It will take participant information, conducts security validations, ensures data integrity, and inserts the new record into the database, responding with the participant's details in JSON format or an error message if the process fails.

===="Read Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def index
@participants = Participant.all
render json: { participants: @participants }, status: :ok
end

<code>index</code> action will accept a participant ID, retrieves the corresponding data from the database, and returns it as a JSON object. If the participant does not exist, it will send an error message.

===="Update Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def update
@participant = Participant.find(params[:id])
if @participant.update(participant_params)
render json: { participant: @participant }, status: :ok
else
render json: @participant.errors, status: :unprocessable_entity
end
end

<code>update</code> action will require a participant ID and the new data to be provided. The method will update the relevant record after security and data validation checks and returns the updated information in JSON format.

===="Delete Method" [https://github.com/expertiza/reimplementation-back-end/commit/022d12ae963d50f582fcedb5301b37c101ad0dd7 Commit]====

def destroy
@participant = Participant.find(params[:id])
@participant.destroy
render json: { message: "Participant was successfully destroyed." }, status: :ok
end

<code>delete</code> action will remove a participant's record using their ID, ensuring that the request is authenticated and the user is authorized to perform the deletion. Upon successful deletion, it will confirm the action with a success response; otherwise, it returns an error.

===="Participants of a particular assignment Method" [https://github.com/expertiza/reimplementation-back-end/commit/b3647df49ee0a2863d9afe23b6711680650e9e25 Commit]====

def assignment_participants
participants = Participant.where(assignment_id: params[:assignment_id])
render json: participants, status: :ok
end

The <code>assignment_participants</code> method will receive an assignment ID, this method will join the pertinent records from the participants and assignments tables, retrieving a comprehensive dataset that is then converted into a JSON array. This method will be instrumental for scenarios where a holistic view of assignment participation is required.

===="Assignment of a particular Participant Method" [https://github.com/expertiza/reimplementation-back-end/commit/dda3fba2d9ae2dacf1d5ad638d57e2189b17e781 Commit]====

def participant_assignment
participant = Participant.find(params[:participant_id])
assignment = participant.assignment

render json: assignment, status: :ok
rescue ActiveRecord::RecordNotFound
render json: { error: "Participant not found" }, status: :not_found
end

The <code>participant_assignment</code> method is designed to retrieve the assignment associated with a specific participant. It takes a participant ID from the request parameters, finds the corresponding participant record, and accesses its associated assignment. The assignment data is then rendered as a JSON object.

== Design Principles ==

==== Single Responsibility Principle (SRP): ====
*Every function within the ParticipantsController will handle a distinct aspect of participant management.
*The functions will undergo restructuring to delineate responsibilities like fetching data, performing calculations, and presenting views.
*As an illustration, the view function will be dedicated to acquiring participant information.

==== Don't Repeat Yourself (DRY) Principle: ====
*Redundant code within the ParticipantsController will be reduced by moving shared functionalities into auxiliary methods or modules.

==== Encapsulation: ====
*The ParticipantsController will organize data and functionality into suitable methods and classes to reduce dependencies.
*The scope of access to instance variables and controller actions will be restricted to foster encapsulation and ensure a clear division of responsibilities.

=Testing Plan=
We employ a combination of manual testing with tools like Postman, automated testing through RSpec, and API documentation and testing using Swagger. This comprehensive approach allows us to validate our API's functionality, security, and usability across various scenarios.

==Manual testing with Postman==

We are using Postman to test our APIs during the development process.
Below are few examples:

*GET /api/v1/participants: Endpoint to test the fetching of all Participants.

[[File:GET.png|500px]]

Fig 5.1.1 Postman UI displaying API testing to fetch all Participant.

*POST /api/v1/participants: Endpoint to test the creation of a Participant.

[[File:POST.png|500px]]

Fig 5.1.2 Postman UI displaying API testing to create a Partcipant.

*PATCH api/v1/participants/4: Endpoint to test the functionality of updating Participant using its ID.

[[File:PATCH.png|500px]]

Fig 5.1.3 Postman UI displaying API testing to update a Participant using its ID.

*DELETE api/v1/participants/4: Endpoint to test the functionality of deleting a Participant with participant id.

[[File:DELETE.png|500px]]

Fig 5.1.4 Postman UI displaying API testing to delete a Participant using its ID.

*GET api/v1/assignments/1/participants: Endpoint to test the functionality of fetching a participant using assignment Id.

[[File:Assignment Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch a participant using assignment Id.

*GET api/v1/participants/1/assignment: Endpoint to test the functionality of fetching an assignment using participant Id.

[[File:Participant Id.png|500px]]

Fig 5.1.5 Postman UI displaying API testing to fetch an assignment using participant Id.

==Automated Testing with Rspec==
====Scenario 1: Creating a New Participant====
Validates the creation of a new Participant with appropriate parameters.

Expectation: Expects a 201 Created status and a JSON response with the created participant details.

describe "POST #create" do
context "with valid parameters" do
it "creates a new participant" do
expect {
post :create, params: { participant: attributes_for(:participant) }
}.to change(Participant, :count).by(1)
expect(response).to have_http_status(:created)
end
end
end

====Scenario 2: Handling Invalid Participant Creation====
Tests the creation process with invalid parameters to ensure robust error handling.

Expectation: Expects a 400 Bad Request status and an error message detailing the invalid parameters.

context "with invalid parameters" do
it "does not create a new participant" do
expect {
post :create, params: { participant: { user_id: nil } }
}.to change(Participant, :count).by(0)
expect(response).to have_http_status(:unprocessable_entity)
end
end

====Scenario 3: Fetch a Participant who is not in the database====
Checks the behaviour when attempting to fetch a Participant not present in the database.

Expectation: Expects a not found status

context "when the participant does not exist" do
it "returns a not found status" do
get :show, params: { id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 4: Fetching an Assignment of a particular Participant====
Validates the functionality for fetching an Assignment of a particular Participant Id
Expectation: Expects a 200 Ok status with the assignment of the participant.

describe "#participant_assignment" do
context "when participant exists" do
it "returns the assignment of the participant" do
get :participant_assignment, params: { participant_id: participant.id }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 5: Fetching an Assignment of an invalid Participant====
Validates the functionality for fetching an Assignment of an Invalid Participant Id

Expectation: Expects a not found status status.

context "when participant does not exist" do
it "returns not found status" do
get :participant_assignment, params: { participant_id: -1 }
expect(response).to have_http_status(:not_found)
end
end

====Scenario 6: Updating a Participant====
Ensures that an existing participant can be updated with valid parameters.

Expectation: Expects a 200 OK status and the updated participant details in the response.

describe "PATCH/PUT #update" do
context "with valid parameters" do
it "updates the participant" do
patch :update, params: { id: participant.id, participant: { type: "NewType" } }
expect(response).to have_http_status(:ok)
end
end
end

====Scenario 7: Updating a Participant====
Checks the behavior when attempting to update a participant with invalid parameters.

Expectation: Expects a 422 Unprocessable Entity status and an error message detailing the issue.

context "with invalid parameters" do
it "does not update the participant" do
patch :update, params: { id: participant.id, participant: { user_id: nil } }
expect(response).to have_http_status(:unprocessable_entity)
end
end

==API Documentation and Testing with Swagger==
To provide clear, interactive API documentation, facilitating easy understanding and testing of API endpoints.

Setup: Integrate Swagger with Rails application using gems like rswag.

Documentation: Annotate the API code to generate Swagger documentation automatically. Ensure that each endpoint is clearly described, with information on parameters, request bodies, and response schemas.
Interactive Testing: Use the Swagger UI to interactively test API endpoints directly from the browser, providing an easy way for non-developers to understand and verify API functionality.

                                                                 [[File:SWAGGER.png|750px]]

                                                                       Fig 5.3 Swagger UI displaying API documentation and interactive testing interface for Participants endpoints.

=Relevant Links=
* '''Github Repository:''' https://github.com/achitti2812/expertiza_project4
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/105
* '''Test Video Link:''' https://youtu.be/hwGuzbqcyjQ

==Team==
=====Mentor=====
*Chunduru Chetana

=====Members=====
*Akhilsai Chittipolu
*Koushik Gudipelly
*Sri Vaishnavi Mylavarapu

CSC/ECE 517 Spring 2024

2024-04-23T17:21:03Z

Kgudipe: Undo revision 156030 by Kgudipe (talk)

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

CSC/ECE 517 Spring 2024

2024-04-23T17:19:51Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2442 Reimplement student task controller]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

File:SWAGGER.png

2024-04-22T17:11:40Z

Kgudipe:

File:DELETE.png

2024-04-22T17:08:48Z

Kgudipe:

File:Participant Id.png

2024-04-22T17:07:04Z

Kgudipe:

File:Assignment Id.png

2024-04-22T17:06:22Z

Kgudipe:

File:Assignment model.png

2024-04-22T17:05:10Z

Kgudipe: Kgudipe uploaded a new version of File:Assignment model.png

File:Assignment.png

2024-04-22T17:03:38Z

Kgudipe: Kgudipe reverted File:Assignment.png to an old version

File:Participant.png

2024-04-22T16:47:49Z

Kgudipe: Kgudipe uploaded a new version of File:Participant.png

File:Assignment.png

2024-04-22T16:47:39Z

Kgudipe: Kgudipe uploaded a new version of File:Assignment.png

File:PATCH.png

2024-04-22T16:47:25Z

Kgudipe:

File:POST.png

2024-04-22T16:47:06Z

Kgudipe:

File:GET.png

2024-04-22T16:46:39Z

Kgudipe:

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)

2024-04-09T01:50:11Z

Kgudipe:

File:Design img.jpg

2024-04-09T01:45:10Z

Kgudipe:

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)

2024-04-09T01:27:50Z

Kgudipe:

CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)

2024-04-09T01:27:15Z

CSC/ECE 517 Spring 2024

2024-04-09T01:26:28Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]

CSC/ECE 517 Spring 2024

2024-04-09T01:23:21Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 SPring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]

CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb

2024-03-24T23:24:45Z

Kgudipe:

== Overview ==
Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb.
We are to use SOLID principles and adhere to the Guidelines for Reimplementation.

duties_controller.rb

This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is used to update the duty in the database. Finally, the delete action can be used to remove a duty from the database. Expertiza's Duties module helps with duty management.

badges_controller.rb

The controller generates a new Badge instance by utilizing user-provided parameters via the create action. If an image file is included, it is also stored, and the badge instance's image_name attribute is updated accordingly.

== Introduction To Expertiza System ==
The Expertiza platform is a versatile and modular system designed to enable students to submit assignments and quizzes smoothly, while also facilitating collaborative learning through features such as peer review. Embraced by students, teaching assistants, and professors alike, this sophisticated system optimizes academic assessments, promoting an interactive and efficient educational environment.

The primary aim of the student quizzes module is to provide a platform for students to generate quizzes for their peers who are working on the same assignments. This fosters a collaborative learning environment where students can collectively improve their understanding and support each other's educational progress.

== Issues with Previous Functionality ==
Previously, the Expertiza system lacked specific functionalities related to duties and badges, which meant there were no established mechanisms within the system to manage duties or to create and manage badges. This absence was notable, as such features could significantly enhance user interaction and system management by allowing for the assignment of responsibilities and the acknowledgment of achievements within the system. To address this gap, a project has been initiated to develop and integrate these functionalities into the Expertiza system through an API framework built on Rails.

== Design ==
The project entails revamping and improving the Duties and Badges modules within an API framework constructed on Rails. In duties_controller.rb, actions for handling duties, such as creation, editing, updating, and deletion, in the Expertiza system are defined. Conversely, badges_controller.rb manages the creation of Badge instances, enabling users to define badge parameters and optionally attach an image file, which is then saved and linked with the badge.

The primary focus of the project is to implement these functionalities as RESTful API endpoints, adhering strictly to JSON response standards. Comprehensive testing, covering both positive and negative scenarios, is imperative to validate the accuracy and resilience of the implemented features. Additionally, prioritizing security, error handling, and validation is crucial for maintaining data integrity and thwarting potential vulnerabilities. The reimplementation must adhere to Rails conventions and adhere to best practices, promoting maintainability and scalability while ensuring smooth integration with other modules in the Expertiza system.

=== Test Driven Development (TDD) ===
Our approach to developing Expertiza duties and bages controller will adhere to a test-driven design methodology. This means that we will be utilizing the test skeletons provided to us and tests for each component of the each module before implementing the corresponding functionalities. By following this rigorous testing approach, we ensure a reliable and thoroughly validated system, enhancing the overall quality and robustness of the Expertiza platform.

=== Objectives ===

* Create: Develop methods in duties_controller and badges_controller to facilitate the creation of new Duties and Badges, respectively. These methods will allow instructors and system administrators to input necessary details such as duty descriptions, badge criteria, and associated rewards.

* Read: Implement show actions within both controllers to enable users to retrieve and view details of specific Duties and Badges. This includes viewing duty responsibilities, badge criteria, and any rewards associated with the completion of duties or earning of badges.

* Update: Add update methods in duties_controller and badges_controller to allow for the modification of existing Duties and Badges. This functionality will enable the adjustment of details such as duty parameters and badge criteria to keep the system’s content current and relevant.

* Delete: Create destroy actions in both controllers to support the deletion of Duties and Badges that are no longer needed or relevant. This will assist in maintaining a clean and efficient database, removing outdated or unnecessary information.

* Index: Enhance the index actions in both duties_controller and badges_controller to list all Duties and Badges, respectively, providing users with an overview of available duties and badges. The index view will be optimized for ease of access and clarity, making it simpler for users to navigate and manage duties and badges within the system.

=== Test Plan ===
* cURL shall be used to simulate HTTP requests

== Implementation ==
=== Duties Controller ===

'''

class Api::V1::DutiesController < ApplicationController
before_action :set_duty, only: %i[ show update destroy ]

'''index Method:'''

Function: Retrieves all duties.

HTTP Verb: GET

URL Endpoint: /duties

Description: Fetches all duties from the database using the Duty.all method and renders a JSON response containing all duties.
# GET /duties
def index
@duties = Duty.all
render json: @duties
end

'''show Method:'''

Function: Retrieves a specific duty.

HTTP Verb: GET

URL Endpoint: /duties/:id

Description: Finds a duty by its ID and renders a JSON response containing the specific duty
# GET /duties/1
def show
render json: @duty, status: :ok
end

'''create Method:'''

Function: Creates a new duty.

HTTP Verb: POST

URL Endpoint: /duties

Description: Creates a new duty by instantiating a Duty object with the provided duty parameters from the request (duty_params).
# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
render json: @duty, status: :created, location: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''update Method:'''

Function: Updates an existing duty.

HTTP Verb: PATCH/PUT

URL Endpoint: /duties/:id

Description: Updates an existing duty specified by its ID using the provided duty parameters from the request (duty_params).
# PATCH/PUT /duties/1
def update
if @duty.update(duty_params)
render json: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''destroy Method:'''

Function: Deletes a duty.

HTTP Verb: DELETE

URL Endpoint: /duties/:id

Description: Finds a specific duty by its ID and destroys (deletes) it. It then renders a JSON response with a success message
# DELETE /duties/1
def destroy
@duty.destroy
render json: { message: "Duty was successfully destroyed." }, status: :ok
end

'''set_duty Method (Private):'''

This technique serves as a callback to establish the @duty instance variable by locating the duty according to the :id parameter. It is applied prior to the show, update, and destroy actions to prepare the specific duty undergoing operation.

private
# Use callbacks to share common setup or constraints between actions.
def set_duty
@duty = Duty.find(params[:id])
end

'''duty_params Method (Private):'''

This process filters the duty parameters received from the request, permitting only designated parameters (:name, :assignment_id, :max_members_for_duties) for creating or updating a duty. It utilizes Rails' strong parameters feature for security purposes.

# Only allow a list of trusted parameters through.
def duty_params
params.require(:duty).permit(:name, :assignment_id, :max_members_for_duties)
end
end

'''

=== Badges Controller ===

'''
class Api::V1::BadgesController < ApplicationController
before_action :set_badge, only: %i[ show update destroy ]

'''index Method:'''

HTTP Verb: GET

Endpoint: /badges

Functionality: Retrieves all badges.

Description: Fetches all existing badges from the database using Badge.all and returns a JSON array containing all badge records.

# GET /badges
# Lists all badges
def index
@badges = Badge.all
render json: { badges: @badges }, status: :ok
end

'''show Method:'''

HTTP Verb: GET

Endpoint: /badges/:id

Functionality: Retrieves a specific badge.

Description: Finds and retrieves a particular badge by its ID from the database. The method responds with a JSON object containing the details of the specific badge.
# GET /badges/1
# Shows a single badge
def show
render json: { badge: @badge }, status: :ok
end

'''create Method:'''

HTTP Verb: POST

Endpoint: /badges

Functionality: Creates a new badge.

Description: Instantiates a new badge using the parameters provided in the request (badge_params).
# POST /badges
# Creates a new badge
def create
@badge = Badge.new(badge_params)

if @badge.save
render json: { badge: @badge }, status: :created
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''update Method:'''

HTTP Verb: PATCH/PUT

Endpoint: /badges/:id

Functionality: Updates an existing badge.

Description: Modifies the attributes of an existing badge based on the parameters received in the request (badge_params).
# PATCH/PUT /badges/1
# Updates an existing badge
def update
if @badge.update(badge_params)
render json: { badge: @badge }, status: :ok
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''destroy Method:'''

HTTP Verb: DELETE

Endpoint: /badges/:id

Functionality: Deletes a badge.

Description: Locates a specific badge by its ID and removes it from the database.
# DELETE /badges/1
# Deletes a badge
def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

'''set_badge Method (Private):'''

Function: Sets up a specific badge for other actions.

Description: This callback function locates and assigns the @badge instance variable according to the :id parameter before executing the show, update, and destroy actions.

private
# Use callbacks to share common setup or constraints between actions.
def set_badge
@badge = Badge.find(params[:id])
end

'''badge_params Method (Private):'''

Function: Filters and permits badge parameters for security.

Description: This process screens the badge parameters received via the request, permitting only certain parameters (:name, :description, :image_name, :image_file) to be utilized for creating or updating a badge.
# Only allow a list of trusted parameters through.
def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
'''

=== Database Setup ===
==== 1. Create an Institution ====
Open shell on the mysql server and run:
mysql -u dev -pexpertiza
use reimplementation_development;

Then run the followinginsert command:
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW());

==== 2. Obtain an Encrypted Password ====
Open a new terminal in the container reimplementation-back-end-app and run the following commands
rails console
BCrypt::Password.create('password123')

You should obtain a string like the following but it will not match:
'$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG'

This will be placed as the password in the next step.

==== 3. Create an Admin User ====
Now, in the mysql terminal run the following (replacing the ‘$2a…’ with the one generated in step 2)

INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);

==== 4. Start the Server ====
At this point we can start the server to issue cURL commands once the server is running.
Start rails server on port 3002
rails s -p 3002

=== cURL User Required Setup ===
==== 1. Login as an User and Get Bearer Token ====
Get bearer token first (for instructor):

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d '{"user_name": "admin", "password": "password123"}'

Note: You can use curl commands from the Windows command prompt, but you cannot use single quotes. For example the above JSON command must be written for Windows:

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d “{\"user_name\": \"admin\", \"password\": \"password123\"}”

Also, RubyMine has an option to construct HTTP requests from cURL commands.
Tools->HTTP Client->Convert cURL to HTTP Request

[[File:CSC517Fall2023_E2376_Convert_cURL_RubyMine_.png|100px]]

Issuing the HTTP requests will return a Bearer Token that must be included while accessing other pages as an Instructor

==== 2. User Creates Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.
Be sure the ids match the database ids for the assignments.
curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test duty 1",
"max_members_for_duty": 2,
"assignment_id": 1}'

==== 3. User can see all available Duties ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 4. User can see a particular Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the duty.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 5. User can update a Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty and assignments.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test",
"max_members_for_duty": 3,
"assignment_id": 1}'

==== 6. User can delete a Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 7. User Creates Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge 3",
"description": "testing creation of badge 3",
"image_file": ""}'

==== 8. User can see all available Badges====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 9. User can see a particular Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the badge.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 10. User can update a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge_1",
"description": "testing",
"image_file": ""}'

==== 11. User can delete a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/badges/3' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

== Conclusion ==
In summary, the reimplementation project for the Duties and Badges modules in Expertiza is crucial for bringing existing functionalities in line with API standards and addressing identified shortcomings from the previous implementation.

The Duties module, managed through duties_controller.rb, is central to handling duties' creation, editing, and deletion within the system. Similarly, the Badges module, governed by badges_controller.rb, oversees badge creation and management, including handling image files.

The main issues with the previous implementation stemmed from treating the system as a traditional Rails MVC application rather than as a Rails API. This resulted in non-compliance with API standards in request and response handling, which this reimplementation aims to fix. Furthermore, deficiencies in testing procedures underscored the need for comprehensive testing to ensure system robustness and reliability.

The planned work involves strict adherence to API-style interactions, returning data in JSON format, and implementing thorough testing for all REST endpoints to ensure robust verification of Duties and Badge functionalities across various scenarios.

By addressing these issues and carefully implementing planned functionalities, this reimplementation aims to improve system efficiency, robustness, and adherence to API conventions, ultimately providing a more reliable and scalable platform for managing duties and badges within Expertiza.

== Useful Links ==

GitHub repository: https://github.com/kgudipe/expertiza 

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/91

== Contributors ==
'''Group members:'''

Akhilsai Chittipolu

Koushik Gudipelly

Sri Vaishnavi Mylavarapu

'''Mentor:'''

Chunduru Chetana

CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb

2024-03-24T22:55:42Z

Kgudipe: Created page with "== Overview == Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb. We are to use SOLID principles and adhere to the Guidelines for Reimplementation. duties_controller.rb This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is us..."

== Overview ==
Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb.
We are to use SOLID principles and adhere to the Guidelines for Reimplementation.

duties_controller.rb

This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is used to update the duty in the database. Finally, the delete action can be used to remove a duty from the database. Expertiza's Duties module helps with duty management.

badges_controller.rb

The controller generates a new Badge instance by utilizing user-provided parameters via the create action. If an image file is included, it is also stored, and the badge instance's image_name attribute is updated accordingly.

== Introduction To Expertiza System ==
The Expertiza platform is a versatile and modular system designed to enable students to submit assignments and quizzes smoothly, while also facilitating collaborative learning through features such as peer review. Embraced by students, teaching assistants, and professors alike, this sophisticated system optimizes academic assessments, promoting an interactive and efficient educational environment.

The primary aim of the student quizzes module is to provide a platform for students to generate quizzes for their peers who are working on the same assignments. This fosters a collaborative learning environment where students can collectively improve their understanding and support each other's educational progress.

== Issues with Previous Functionality ==
Previously, the Expertiza system lacked specific functionalities related to duties and badges, which meant there were no established mechanisms within the system to manage duties or to create and manage badges. This absence was notable, as such features could significantly enhance user interaction and system management by allowing for the assignment of responsibilities and the acknowledgment of achievements within the system. To address this gap, a project has been initiated to develop and integrate these functionalities into the Expertiza system through an API framework built on Rails.

== Design ==
The project entails revamping and improving the Duties and Badges modules within an API framework constructed on Rails. In duties_controller.rb, actions for handling duties, such as creation, editing, updating, and deletion, in the Expertiza system are defined. Conversely, badges_controller.rb manages the creation of Badge instances, enabling users to define badge parameters and optionally attach an image file, which is then saved and linked with the badge.

The primary focus of the project is to implement these functionalities as RESTful API endpoints, adhering strictly to JSON response standards. Comprehensive testing, covering both positive and negative scenarios, is imperative to validate the accuracy and resilience of the implemented features. Additionally, prioritizing security, error handling, and validation is crucial for maintaining data integrity and thwarting potential vulnerabilities. The reimplementation must adhere to Rails conventions and adhere to best practices, promoting maintainability and scalability while ensuring smooth integration with other modules in the Expertiza system.

=== Test Driven Development (TDD) ===
Our approach to developing Expertiza duties and bages controller will adhere to a test-driven design methodology. This means that we will be utilizing the test skeletons provided to us and tests for each component of the each module before implementing the corresponding functionalities. By following this rigorous testing approach, we ensure a reliable and thoroughly validated system, enhancing the overall quality and robustness of the Expertiza platform.

=== Objectives ===

* Create: Develop methods in duties_controller and badges_controller to facilitate the creation of new Duties and Badges, respectively. These methods will allow instructors and system administrators to input necessary details such as duty descriptions, badge criteria, and associated rewards.

* Read: Implement show actions within both controllers to enable users to retrieve and view details of specific Duties and Badges. This includes viewing duty responsibilities, badge criteria, and any rewards associated with the completion of duties or earning of badges.

* Update: Add update methods in duties_controller and badges_controller to allow for the modification of existing Duties and Badges. This functionality will enable the adjustment of details such as duty parameters and badge criteria to keep the system’s content current and relevant.

* Delete: Create destroy actions in both controllers to support the deletion of Duties and Badges that are no longer needed or relevant. This will assist in maintaining a clean and efficient database, removing outdated or unnecessary information.

* Index: Enhance the index actions in both duties_controller and badges_controller to list all Duties and Badges, respectively, providing users with an overview of available duties and badges. The index view will be optimized for ease of access and clarity, making it simpler for users to navigate and manage duties and badges within the system.

=== Test Plan ===
* cURL shall be used to simulate HTTP requests
* Only an Admin shall create a test

== Implementation ==
=== Duties Controller ===

'''

class Api::V1::DutiesController < ApplicationController
before_action :set_duty, only: %i[ show update destroy ]

'''index Method:'''

Function: Retrieves all duties.

HTTP Verb: GET

URL Endpoint: /duties

Description: Fetches all duties from the database using the Duty.all method and renders a JSON response containing all duties.
# GET /duties
def index
@duties = Duty.all
render json: @duties
end

'''show Method:'''

Function: Retrieves a specific duty.

HTTP Verb: GET

URL Endpoint: /duties/:id

Description: Finds a duty by its ID and renders a JSON response containing the specific duty
# GET /duties/1
def show
render json: @duty, status: :ok
end

'''create Method:'''

Function: Creates a new duty.

HTTP Verb: POST

URL Endpoint: /duties

Description: Creates a new duty by instantiating a Duty object with the provided duty parameters from the request (duty_params).
# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
render json: @duty, status: :created, location: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''update Method:'''

Function: Updates an existing duty.

HTTP Verb: PATCH/PUT

URL Endpoint: /duties/:id

Description: Updates an existing duty specified by its ID using the provided duty parameters from the request (duty_params).
# PATCH/PUT /duties/1
def update
if @duty.update(duty_params)
render json: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''destroy Method:'''

Function: Deletes a duty.

HTTP Verb: DELETE

URL Endpoint: /duties/:id

Description: Finds a specific duty by its ID and destroys (deletes) it. It then renders a JSON response with a success message
# DELETE /duties/1
def destroy
@duty.destroy
render json: { message: "Duty was successfully destroyed." }, status: :ok
end

'''set_duty Method (Private):'''

This technique serves as a callback to establish the @duty instance variable by locating the duty according to the :id parameter. It is applied prior to the show, update, and destroy actions to prepare the specific duty undergoing operation.

private
# Use callbacks to share common setup or constraints between actions.
def set_duty
@duty = Duty.find(params[:id])
end

'''duty_params Method (Private):'''

This process filters the duty parameters received from the request, permitting only designated parameters (:name, :assignment_id, :max_members_for_duties) for creating or updating a duty. It utilizes Rails' strong parameters feature for security purposes.

# Only allow a list of trusted parameters through.
def duty_params
params.require(:duty).permit(:name, :assignment_id, :max_members_for_duties)
end
end

'''

=== Badges Controller ===

'''
class Api::V1::BadgesController < ApplicationController
before_action :set_badge, only: %i[ show update destroy ]

'''index Method:'''

HTTP Verb: GET

Endpoint: /badges

Functionality: Retrieves all badges.

Description: Fetches all existing badges from the database using Badge.all and returns a JSON array containing all badge records.

# GET /badges
# Lists all badges
def index
@badges = Badge.all
render json: { badges: @badges }, status: :ok
end

'''show Method:'''

HTTP Verb: GET

Endpoint: /badges/:id

Functionality: Retrieves a specific badge.

Description: Finds and retrieves a particular badge by its ID from the database. The method responds with a JSON object containing the details of the specific badge.
# GET /badges/1
# Shows a single badge
def show
render json: { badge: @badge }, status: :ok
end

'''create Method:'''

HTTP Verb: POST

Endpoint: /badges

Functionality: Creates a new badge.

Description: Instantiates a new badge using the parameters provided in the request (badge_params).
# POST /badges
# Creates a new badge
def create
@badge = Badge.new(badge_params)

if @badge.save
render json: { badge: @badge }, status: :created
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''update Method:'''

HTTP Verb: PATCH/PUT

Endpoint: /badges/:id

Functionality: Updates an existing badge.

Description: Modifies the attributes of an existing badge based on the parameters received in the request (badge_params).
# PATCH/PUT /badges/1
# Updates an existing badge
def update
if @badge.update(badge_params)
render json: { badge: @badge }, status: :ok
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''destroy Method:'''

HTTP Verb: DELETE

Endpoint: /badges/:id

Functionality: Deletes a badge.

Description: Locates a specific badge by its ID and removes it from the database.
# DELETE /badges/1
# Deletes a badge
def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

'''set_badge Method (Private):'''

Function: Sets up a specific badge for other actions.

Description: This callback function locates and assigns the @badge instance variable according to the :id parameter before executing the show, update, and destroy actions.

private
# Use callbacks to share common setup or constraints between actions.
def set_badge
@badge = Badge.find(params[:id])
end

'''badge_params Method (Private):'''

Function: Filters and permits badge parameters for security.

Description: This process screens the badge parameters received via the request, permitting only certain parameters (:name, :description, :image_name, :image_file) to be utilized for creating or updating a badge.
# Only allow a list of trusted parameters through.
def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
'''

=== Database Setup ===
==== 1. Create an Institution ====
Open shell on the mysql server and run:
mysql -u dev -pexpertiza
use reimplementation_development;

Then run the followinginsert command:
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW());

==== 2. Obtain an Encrypted Password ====
Open a new terminal in the container reimplementation-back-end-app and run the following commands
rails console
BCrypt::Password.create('password123')

You should obtain a string like the following but it will not match:
'$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG'

This will be placed as the password in the next step.

==== 3. Create an Admin User ====
Now, in the mysql terminal run the following (replacing the ‘$2a…’ with the one generated in step 2)

INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);

==== 4. Start the Server ====
At this point we can start the server to issue cURL commands once the server is running.
Start rails server on port 3002
rails s -p 3002

=== cURL User Required Setup ===
==== 1. Login as an User and Get Bearer Token ====
Get bearer token first (for instructor):

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d '{"user_name": "admin", "password": "password123"}'

Note: You can use curl commands from the Windows command prompt, but you cannot use single quotes. For example the above JSON command must be written for Windows:

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d “{\"user_name\": \"admin\", \"password\": \"password123\"}”

Also, RubyMine has an option to construct HTTP requests from cURL commands.
Tools->HTTP Client->Convert cURL to HTTP Request

[[File:CSC517Fall2023_E2376_Convert_cURL_RubyMine_.png|100px]]

Issuing the HTTP requests will return a Bearer Token that must be included while accessing other pages as an Instructor

==== 2. User Creates Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.
Be sure the ids match the database ids for the assignments.
curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test duty 1",
"max_members_for_duty": 2,
"assignment_id": 1}'

==== 3. User can see all available Duties ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 4. User can see a particular Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the duty.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 5. User can update a Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty and assignments.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test",
"max_members_for_duty": 3,
"assignment_id": 1}'

==== 6. User can delete a Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 7. User Creates Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge 3",
"description": "testing creation of badge 3",
"image_file": ""}'

==== 8. User can see all available Badges====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 9. User can see a particular Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the badge.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 10. User can update a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge_1",
"description": "testing",
"image_file": ""}'

==== 11. User can delete a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/badges/3' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

== Conclusion ==
In summary, the reimplementation project for the Duties and Badges modules in Expertiza is crucial for bringing existing functionalities in line with API standards and addressing identified shortcomings from the previous implementation.

The Duties module, managed through duties_controller.rb, is central to handling duties' creation, editing, and deletion within the system. Similarly, the Badges module, governed by badges_controller.rb, oversees badge creation and management, including handling image files.

The main issues with the previous implementation stemmed from treating the system as a traditional Rails MVC application rather than as a Rails API. This resulted in non-compliance with API standards in request and response handling, which this reimplementation aims to fix. Furthermore, deficiencies in testing procedures underscored the need for comprehensive testing to ensure system robustness and reliability.

The planned work involves strict adherence to API-style interactions, returning data in JSON format, and implementing thorough testing for all REST endpoints to ensure robust verification of Duties and Badge functionalities across various scenarios.

By addressing these issues and carefully implementing planned functionalities, this reimplementation aims to improve system efficiency, robustness, and adherence to API conventions, ultimately providing a more reliable and scalable platform for managing duties and badges within Expertiza.

== Useful Links ==

== Contributors ==
'''Group members:'''

Akhilsai Chittipolu

Koushik Gudipelly

Sri Vaishnavi Mylavarapu

'''Mentor:'''

Chunduru Chetana

CSC/ECE 517 Spring 2024

2024-03-24T22:55:01Z

Kgudipe:

* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]

User:Smylava

2024-03-24T22:51:34Z

Kgudipe: Kgudipe moved page User:Smylava to E2419. Reimplement duties controller.rb and badges controller.rb

#REDIRECT [[E2419. Reimplement duties controller.rb and badges controller.rb]]

E2419. Reimplement duties controller.rb and badges controller.rb

2024-03-24T22:51:34Z

Kgudipe: Kgudipe moved page User:Smylava to E2419. Reimplement duties controller.rb and badges controller.rb

== Overview ==
Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb.
We are to use SOLID principles and adhere to the Guidelines for Reimplementation.

duties_controller.rb

This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is used to update the duty in the database. Finally, the delete action can be used to remove a duty from the database. Expertiza's Duties module helps with duty management.

badges_controller.rb

The controller generates a new Badge instance by utilizing user-provided parameters via the create action. If an image file is included, it is also stored, and the badge instance's image_name attribute is updated accordingly.

== Introduction To Expertiza System ==
The Expertiza platform is a versatile and modular system designed to enable students to submit assignments and quizzes smoothly, while also facilitating collaborative learning through features such as peer review. Embraced by students, teaching assistants, and professors alike, this sophisticated system optimizes academic assessments, promoting an interactive and efficient educational environment.

The primary aim of the student quizzes module is to provide a platform for students to generate quizzes for their peers who are working on the same assignments. This fosters a collaborative learning environment where students can collectively improve their understanding and support each other's educational progress.

== Issues with Previous Functionality ==
Previously, the Expertiza system lacked specific functionalities related to duties and badges, which meant there were no established mechanisms within the system to manage duties or to create and manage badges. This absence was notable, as such features could significantly enhance user interaction and system management by allowing for the assignment of responsibilities and the acknowledgment of achievements within the system. To address this gap, a project has been initiated to develop and integrate these functionalities into the Expertiza system through an API framework built on Rails.

== Design ==
The project entails revamping and improving the Duties and Badges modules within an API framework constructed on Rails. In duties_controller.rb, actions for handling duties, such as creation, editing, updating, and deletion, in the Expertiza system are defined. Conversely, badges_controller.rb manages the creation of Badge instances, enabling users to define badge parameters and optionally attach an image file, which is then saved and linked with the badge.

The primary focus of the project is to implement these functionalities as RESTful API endpoints, adhering strictly to JSON response standards. Comprehensive testing, covering both positive and negative scenarios, is imperative to validate the accuracy and resilience of the implemented features. Additionally, prioritizing security, error handling, and validation is crucial for maintaining data integrity and thwarting potential vulnerabilities. The reimplementation must adhere to Rails conventions and adhere to best practices, promoting maintainability and scalability while ensuring smooth integration with other modules in the Expertiza system.

=== Test Driven Development (TDD) ===
Our approach to developing Expertiza duties and bages controller will adhere to a test-driven design methodology. This means that we will be utilizing the test skeletons provided to us and tests for each component of the each module before implementing the corresponding functionalities. By following this rigorous testing approach, we ensure a reliable and thoroughly validated system, enhancing the overall quality and robustness of the Expertiza platform.

=== Objectives ===

* Create: Develop methods in duties_controller and badges_controller to facilitate the creation of new Duties and Badges, respectively. These methods will allow instructors and system administrators to input necessary details such as duty descriptions, badge criteria, and associated rewards.

* Read: Implement show actions within both controllers to enable users to retrieve and view details of specific Duties and Badges. This includes viewing duty responsibilities, badge criteria, and any rewards associated with the completion of duties or earning of badges.

* Update: Add update methods in duties_controller and badges_controller to allow for the modification of existing Duties and Badges. This functionality will enable the adjustment of details such as duty parameters and badge criteria to keep the system’s content current and relevant.

* Delete: Create destroy actions in both controllers to support the deletion of Duties and Badges that are no longer needed or relevant. This will assist in maintaining a clean and efficient database, removing outdated or unnecessary information.

* Index: Enhance the index actions in both duties_controller and badges_controller to list all Duties and Badges, respectively, providing users with an overview of available duties and badges. The index view will be optimized for ease of access and clarity, making it simpler for users to navigate and manage duties and badges within the system.

=== Test Plan ===
* cURL shall be used to simulate HTTP requests
* Only an Admin shall create a test

== Implementation ==
=== Duties Controller ===

'''

class Api::V1::DutiesController < ApplicationController
before_action :set_duty, only: %i[ show update destroy ]

'''index Method:'''

Function: Retrieves all duties.

HTTP Verb: GET

URL Endpoint: /duties

Description: Fetches all duties from the database using the Duty.all method and renders a JSON response containing all duties.
# GET /duties
def index
@duties = Duty.all
render json: @duties
end

'''show Method:'''

Function: Retrieves a specific duty.

HTTP Verb: GET

URL Endpoint: /duties/:id

Description: Finds a duty by its ID and renders a JSON response containing the specific duty
# GET /duties/1
def show
render json: @duty, status: :ok
end

'''create Method:'''

Function: Creates a new duty.

HTTP Verb: POST

URL Endpoint: /duties

Description: Creates a new duty by instantiating a Duty object with the provided duty parameters from the request (duty_params).
# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
render json: @duty, status: :created, location: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''update Method:'''

Function: Updates an existing duty.

HTTP Verb: PATCH/PUT

URL Endpoint: /duties/:id

Description: Updates an existing duty specified by its ID using the provided duty parameters from the request (duty_params).
# PATCH/PUT /duties/1
def update
if @duty.update(duty_params)
render json: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''destroy Method:'''

Function: Deletes a duty.

HTTP Verb: DELETE

URL Endpoint: /duties/:id

Description: Finds a specific duty by its ID and destroys (deletes) it. It then renders a JSON response with a success message
# DELETE /duties/1
def destroy
@duty.destroy
render json: { message: "Duty was successfully destroyed." }, status: :ok
end

'''set_duty Method (Private):'''

This technique serves as a callback to establish the @duty instance variable by locating the duty according to the :id parameter. It is applied prior to the show, update, and destroy actions to prepare the specific duty undergoing operation.

private
# Use callbacks to share common setup or constraints between actions.
def set_duty
@duty = Duty.find(params[:id])
end

'''duty_params Method (Private):'''

This process filters the duty parameters received from the request, permitting only designated parameters (:name, :assignment_id, :max_members_for_duties) for creating or updating a duty. It utilizes Rails' strong parameters feature for security purposes.

# Only allow a list of trusted parameters through.
def duty_params
params.require(:duty).permit(:name, :assignment_id, :max_members_for_duties)
end
end

'''

=== Badges Controller ===

'''
class Api::V1::BadgesController < ApplicationController
before_action :set_badge, only: %i[ show update destroy ]

'''index Method:'''

HTTP Verb: GET

Endpoint: /badges

Functionality: Retrieves all badges.

Description: Fetches all existing badges from the database using Badge.all and returns a JSON array containing all badge records.

# GET /badges
# Lists all badges
def index
@badges = Badge.all
render json: { badges: @badges }, status: :ok
end

'''show Method:'''

HTTP Verb: GET

Endpoint: /badges/:id

Functionality: Retrieves a specific badge.

Description: Finds and retrieves a particular badge by its ID from the database. The method responds with a JSON object containing the details of the specific badge.
# GET /badges/1
# Shows a single badge
def show
render json: { badge: @badge }, status: :ok
end

'''create Method:'''

HTTP Verb: POST

Endpoint: /badges

Functionality: Creates a new badge.

Description: Instantiates a new badge using the parameters provided in the request (badge_params).
# POST /badges
# Creates a new badge
def create
@badge = Badge.new(badge_params)

if @badge.save
render json: { badge: @badge }, status: :created
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''update Method:'''

HTTP Verb: PATCH/PUT

Endpoint: /badges/:id

Functionality: Updates an existing badge.

Description: Modifies the attributes of an existing badge based on the parameters received in the request (badge_params).
# PATCH/PUT /badges/1
# Updates an existing badge
def update
if @badge.update(badge_params)
render json: { badge: @badge }, status: :ok
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''destroy Method:'''

HTTP Verb: DELETE

Endpoint: /badges/:id

Functionality: Deletes a badge.

Description: Locates a specific badge by its ID and removes it from the database.
# DELETE /badges/1
# Deletes a badge
def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

'''set_badge Method (Private):'''

Function: Sets up a specific badge for other actions.

Description: This callback function locates and assigns the @badge instance variable according to the :id parameter before executing the show, update, and destroy actions.

private
# Use callbacks to share common setup or constraints between actions.
def set_badge
@badge = Badge.find(params[:id])
end

'''badge_params Method (Private):'''

Function: Filters and permits badge parameters for security.

Description: This process screens the badge parameters received via the request, permitting only certain parameters (:name, :description, :image_name, :image_file) to be utilized for creating or updating a badge.
# Only allow a list of trusted parameters through.
def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
'''

=== Database Setup ===
==== 1. Create an Institution ====
Open shell on the mysql server and run:
mysql -u dev -pexpertiza
use reimplementation_development;

Then run the followinginsert command:
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW());

==== 2. Obtain an Encrypted Password ====
Open a new terminal in the container reimplementation-back-end-app and run the following commands
rails console
BCrypt::Password.create('password123')

You should obtain a string like the following but it will not match:
'$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG'

This will be placed as the password in the next step.

==== 3. Create an Admin User ====
Now, in the mysql terminal run the following (replacing the ‘$2a…’ with the one generated in step 2)

INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);

==== 4. Start the Server ====
At this point we can start the server to issue cURL commands once the server is running.
Start rails server on port 3002
rails s -p 3002

=== cURL User Required Setup ===
==== 1. Login as an User and Get Bearer Token ====
Get bearer token first (for instructor):

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d '{"user_name": "admin", "password": "password123"}'

Note: You can use curl commands from the Windows command prompt, but you cannot use single quotes. For example the above JSON command must be written for Windows:

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d “{\"user_name\": \"admin\", \"password\": \"password123\"}”

Also, RubyMine has an option to construct HTTP requests from cURL commands.
Tools->HTTP Client->Convert cURL to HTTP Request

[[File:CSC517Fall2023_E2376_Convert_cURL_RubyMine_.png|100px]]

Issuing the HTTP requests will return a Bearer Token that must be included while accessing other pages as an Instructor

==== 2. User Creates Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.
Be sure the ids match the database ids for the assignments.
curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test duty 1",
"max_members_for_duty": 2,
"assignment_id": 1}'

==== 3. User can see all available Duties ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 4. User can see a particular Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the duty.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 5. User can update a Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty and assignments.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test",
"max_members_for_duty": 3,
"assignment_id": 1}'

==== 6. User can delete a Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 7. User Creates Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge 3",
"description": "testing creation of badge 3",
"image_file": ""}'

==== 8. User can see all available Badges====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 9. User can see a particular Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the badge.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 10. User can update a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge_1",
"description": "testing",
"image_file": ""}'

==== 11. User can delete a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/badges/3' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

== Conclusion ==
In summary, the reimplementation project for the Duties and Badges modules in Expertiza is crucial for bringing existing functionalities in line with API standards and addressing identified shortcomings from the previous implementation.

The Duties module, managed through duties_controller.rb, is central to handling duties' creation, editing, and deletion within the system. Similarly, the Badges module, governed by badges_controller.rb, oversees badge creation and management, including handling image files.

The main issues with the previous implementation stemmed from treating the system as a traditional Rails MVC application rather than as a Rails API. This resulted in non-compliance with API standards in request and response handling, which this reimplementation aims to fix. Furthermore, deficiencies in testing procedures underscored the need for comprehensive testing to ensure system robustness and reliability.

The planned work involves strict adherence to API-style interactions, returning data in JSON format, and implementing thorough testing for all REST endpoints to ensure robust verification of Duties and Badge functionalities across various scenarios.

By addressing these issues and carefully implementing planned functionalities, this reimplementation aims to improve system efficiency, robustness, and adherence to API conventions, ultimately providing a more reliable and scalable platform for managing duties and badges within Expertiza.

== Useful Links ==

== Contributors ==
'''Group members:'''

Akhilsai Chittipolu

Koushik Gudipelly

Sri Vaishnavi Mylavarapu

'''Mentor:'''

Chunduru Chetana

E2419. Reimplement duties controller.rb and badges controller.rb

2024-03-24T18:52:20Z

Kgudipe:

== Overview ==
Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb.
We are to use SOLID principles and adhere to the Guidelines for Reimplementation.

duties_controller.rb

This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is used to update the duty in the database. Finally, the delete action can be used to remove a duty from the database. Expertiza's Duties module helps with duty management.

badges_controller.rb

The controller generates a new Badge instance by utilizing user-provided parameters via the create action. If an image file is included, it is also stored, and the badge instance's image_name attribute is updated accordingly.

== Introduction To Expertiza System ==
The Expertiza platform is a versatile and modular system designed to enable students to submit assignments and quizzes smoothly, while also facilitating collaborative learning through features such as peer review. Embraced by students, teaching assistants, and professors alike, this sophisticated system optimizes academic assessments, promoting an interactive and efficient educational environment.

The primary aim of the student quizzes module is to provide a platform for students to generate quizzes for their peers who are working on the same assignments. This fosters a collaborative learning environment where students can collectively improve their understanding and support each other's educational progress.

== Issues with Previous Functionality ==
Previously, the Expertiza system lacked specific functionalities related to duties and badges, which meant there were no established mechanisms within the system to manage duties or to create and manage badges. This absence was notable, as such features could significantly enhance user interaction and system management by allowing for the assignment of responsibilities and the acknowledgment of achievements within the system. To address this gap, a project has been initiated to develop and integrate these functionalities into the Expertiza system through an API framework built on Rails.

== Design ==
The project entails revamping and improving the Duties and Badges modules within an API framework constructed on Rails. In duties_controller.rb, actions for handling duties, such as creation, editing, updating, and deletion, in the Expertiza system are defined. Conversely, badges_controller.rb manages the creation of Badge instances, enabling users to define badge parameters and optionally attach an image file, which is then saved and linked with the badge.

The primary focus of the project is to implement these functionalities as RESTful API endpoints, adhering strictly to JSON response standards. Comprehensive testing, covering both positive and negative scenarios, is imperative to validate the accuracy and resilience of the implemented features. Additionally, prioritizing security, error handling, and validation is crucial for maintaining data integrity and thwarting potential vulnerabilities. The reimplementation must adhere to Rails conventions and adhere to best practices, promoting maintainability and scalability while ensuring smooth integration with other modules in the Expertiza system.

=== Test Driven Development (TDD) ===
Our approach to developing Expertiza duties and bages controller will adhere to a test-driven design methodology. This means that we will be utilizing the test skeletons provided to us and tests for each component of the each module before implementing the corresponding functionalities. By following this rigorous testing approach, we ensure a reliable and thoroughly validated system, enhancing the overall quality and robustness of the Expertiza platform.

=== Objectives ===

* Create: Develop methods in duties_controller and badges_controller to facilitate the creation of new Duties and Badges, respectively. These methods will allow instructors and system administrators to input necessary details such as duty descriptions, badge criteria, and associated rewards.

* Read: Implement show actions within both controllers to enable users to retrieve and view details of specific Duties and Badges. This includes viewing duty responsibilities, badge criteria, and any rewards associated with the completion of duties or earning of badges.

* Update: Add update methods in duties_controller and badges_controller to allow for the modification of existing Duties and Badges. This functionality will enable the adjustment of details such as duty parameters and badge criteria to keep the system’s content current and relevant.

* Delete: Create destroy actions in both controllers to support the deletion of Duties and Badges that are no longer needed or relevant. This will assist in maintaining a clean and efficient database, removing outdated or unnecessary information.

* Index: Enhance the index actions in both duties_controller and badges_controller to list all Duties and Badges, respectively, providing users with an overview of available duties and badges. The index view will be optimized for ease of access and clarity, making it simpler for users to navigate and manage duties and badges within the system.

=== Test Plan ===
* cURL shall be used to simulate HTTP requests
* Only an Admin shall create a test

== Implementation ==
=== Duties Controller ===

'''

class Api::V1::DutiesController < ApplicationController
before_action :set_duty, only: %i[ show update destroy ]

'''index Method:'''

Function: Retrieves all duties.

HTTP Verb: GET

URL Endpoint: /duties

Description: Fetches all duties from the database using the Duty.all method and renders a JSON response containing all duties.
# GET /duties
def index
@duties = Duty.all
render json: @duties
end

'''show Method:'''

Function: Retrieves a specific duty.

HTTP Verb: GET

URL Endpoint: /duties/:id

Description: Finds a duty by its ID and renders a JSON response containing the specific duty
# GET /duties/1
def show
render json: @duty, status: :ok
end

'''create Method:'''

Function: Creates a new duty.

HTTP Verb: POST

URL Endpoint: /duties

Description: Creates a new duty by instantiating a Duty object with the provided duty parameters from the request (duty_params).
# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
render json: @duty, status: :created, location: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''update Method:'''

Function: Updates an existing duty.

HTTP Verb: PATCH/PUT

URL Endpoint: /duties/:id

Description: Updates an existing duty specified by its ID using the provided duty parameters from the request (duty_params).
# PATCH/PUT /duties/1
def update
if @duty.update(duty_params)
render json: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''destroy Method:'''

Function: Deletes a duty.

HTTP Verb: DELETE

URL Endpoint: /duties/:id

Description: Finds a specific duty by its ID and destroys (deletes) it. It then renders a JSON response with a success message
# DELETE /duties/1
def destroy
@duty.destroy
render json: { message: "Duty was successfully destroyed." }, status: :ok
end

'''set_duty Method (Private):'''

This technique serves as a callback to establish the @duty instance variable by locating the duty according to the :id parameter. It is applied prior to the show, update, and destroy actions to prepare the specific duty undergoing operation.

private
# Use callbacks to share common setup or constraints between actions.
def set_duty
@duty = Duty.find(params[:id])
end

'''duty_params Method (Private):'''

This process filters the duty parameters received from the request, permitting only designated parameters (:name, :assignment_id, :max_members_for_duties) for creating or updating a duty. It utilizes Rails' strong parameters feature for security purposes.

# Only allow a list of trusted parameters through.
def duty_params
params.require(:duty).permit(:name, :assignment_id, :max_members_for_duties)
end
end

'''

=== Badges Controller ===

'''
class Api::V1::BadgesController < ApplicationController
before_action :set_badge, only: %i[ show update destroy ]

'''index Method:'''

HTTP Verb: GET

Endpoint: /badges

Functionality: Retrieves all badges.

Description: Fetches all existing badges from the database using Badge.all and returns a JSON array containing all badge records.

# GET /badges
# Lists all badges
def index
@badges = Badge.all
render json: { badges: @badges }, status: :ok
end

'''show Method:'''

HTTP Verb: GET

Endpoint: /badges/:id

Functionality: Retrieves a specific badge.

Description: Finds and retrieves a particular badge by its ID from the database. The method responds with a JSON object containing the details of the specific badge.
# GET /badges/1
# Shows a single badge
def show
render json: { badge: @badge }, status: :ok
end

'''create Method:'''

HTTP Verb: POST

Endpoint: /badges

Functionality: Creates a new badge.

Description: Instantiates a new badge using the parameters provided in the request (badge_params).
# POST /badges
# Creates a new badge
def create
@badge = Badge.new(badge_params)

if @badge.save
render json: { badge: @badge }, status: :created
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''update Method:'''

HTTP Verb: PATCH/PUT

Endpoint: /badges/:id

Functionality: Updates an existing badge.

Description: Modifies the attributes of an existing badge based on the parameters received in the request (badge_params).
# PATCH/PUT /badges/1
# Updates an existing badge
def update
if @badge.update(badge_params)
render json: { badge: @badge }, status: :ok
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''destroy Method:'''

HTTP Verb: DELETE

Endpoint: /badges/:id

Functionality: Deletes a badge.

Description: Locates a specific badge by its ID and removes it from the database.
# DELETE /badges/1
# Deletes a badge
def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

'''set_badge Method (Private):'''

Function: Sets up a specific badge for other actions.

Description: This callback function locates and assigns the @badge instance variable according to the :id parameter before executing the show, update, and destroy actions.

private
# Use callbacks to share common setup or constraints between actions.
def set_badge
@badge = Badge.find(params[:id])
end

'''badge_params Method (Private):'''

Function: Filters and permits badge parameters for security.

Description: This process screens the badge parameters received via the request, permitting only certain parameters (:name, :description, :image_name, :image_file) to be utilized for creating or updating a badge.
# Only allow a list of trusted parameters through.
def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
'''

=== Database Setup ===
==== 1. Create an Institution ====
Open shell on the mysql server and run:
mysql -u dev -pexpertiza
use reimplementation_development;

Then run the followinginsert command:
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW());

==== 2. Obtain an Encrypted Password ====
Open a new terminal in the container reimplementation-back-end-app and run the following commands
rails console
BCrypt::Password.create('password123')

You should obtain a string like the following but it will not match:
'$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG'

This will be placed as the password in the next step.

==== 3. Create an Admin User ====
Now, in the mysql terminal run the following (replacing the ‘$2a…’ with the one generated in step 2)

INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);

==== 4. Start the Server ====
At this point we can start the server to issue cURL commands once the server is running.
Start rails server on port 3002
rails s -p 3002

=== cURL User Required Setup ===
==== 1. Login as an User and Get Bearer Token ====
Get bearer token first (for instructor):

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d '{"user_name": "admin", "password": "password123"}'

Note: You can use curl commands from the Windows command prompt, but you cannot use single quotes. For example the above JSON command must be written for Windows:

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d “{\"user_name\": \"admin\", \"password\": \"password123\"}”

Also, RubyMine has an option to construct HTTP requests from cURL commands.
Tools->HTTP Client->Convert cURL to HTTP Request

[[File:CSC517Fall2023_E2376_Convert_cURL_RubyMine_.png|100px]]

Issuing the HTTP requests will return a Bearer Token that must be included while accessing other pages as an Instructor

==== 2. User Creates Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.
Be sure the ids match the database ids for the assignments.
curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test duty 1",
"max_members_for_duty": 2,
"assignment_id": 1}'

==== 3. User can see all available Duties ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 4. User can see a particular Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the duty.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 5. User can update a Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty and assignments.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test",
"max_members_for_duty": 3,
"assignment_id": 1}'

==== 6. User can delete a Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 7. User Creates Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge 3",
"description": "testing creation of badge 3",
"image_file": ""}'

==== 8. User can see all available Badges====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 9. User can see a particular Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the badge.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 10. User can update a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge_1",
"description": "testing",
"image_file": ""}'

==== 11. User can delete a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/badges/3' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

== Conclusion ==
In summary, the reimplementation project for the Duties and Badges modules in Expertiza is crucial for bringing existing functionalities in line with API standards and addressing identified shortcomings from the previous implementation.

The Duties module, managed through duties_controller.rb, is central to handling duties' creation, editing, and deletion within the system. Similarly, the Badges module, governed by badges_controller.rb, oversees badge creation and management, including handling image files.

The main issues with the previous implementation stemmed from treating the system as a traditional Rails MVC application rather than as a Rails API. This resulted in non-compliance with API standards in request and response handling, which this reimplementation aims to fix. Furthermore, deficiencies in testing procedures underscored the need for comprehensive testing to ensure system robustness and reliability.

The planned work involves strict adherence to API-style interactions, returning data in JSON format, and implementing thorough testing for all REST endpoints to ensure robust verification of Duties and Badge functionalities across various scenarios.

By addressing these issues and carefully implementing planned functionalities, this reimplementation aims to improve system efficiency, robustness, and adherence to API conventions, ultimately providing a more reliable and scalable platform for managing duties and badges within Expertiza.

== Useful Links ==

== Contributors ==
'''Group members:'''

Akhilsai Chittipolu

Koushik Gudipelly

Sri Vaishnavi Mylavarapu

'''Mentor:'''

Chunduru Chetana

E2419. Reimplement duties controller.rb and badges controller.rb

2024-03-24T18:07:26Z

Kgudipe:

== Overview ==
Our team is tasked with creating the backend reimplementation of the duties_controller.rb and badges_controller.rb.
We are to use SOLID principles and adhere to the Guidelines for Reimplementation.

duties_controller.rb

This duties_controller defines the following actions: create, update, and remove. The create action is used to save the new duty to the database. While the edit action renders the form for altering an existing duty, the update action is used to update the duty in the database. Finally, the delete action can be used to remove a duty from the database. Expertiza's Duties module helps with duty management.

badges_controller.rb

The controller generates a new Badge instance by utilizing user-provided parameters via the create action. If an image file is included, it is also stored, and the badge instance's image_name attribute is updated accordingly.

== Introduction To Expertiza System ==
The Expertiza platform is a versatile and modular system designed to enable students to submit assignments and quizzes smoothly, while also facilitating collaborative learning through features such as peer review. Embraced by students, teaching assistants, and professors alike, this sophisticated system optimizes academic assessments, promoting an interactive and efficient educational environment.

The primary aim of the student quizzes module is to provide a platform for students to generate quizzes for their peers who are working on the same assignments. This fosters a collaborative learning environment where students can collectively improve their understanding and support each other's educational progress.

== Issues with Previous Functionality ==
Previously, the Expertiza system lacked specific functionalities related to duties and badges, which meant there were no established mechanisms within the system to manage duties or to create and manage badges. This absence was notable, as such features could significantly enhance user interaction and system management by allowing for the assignment of responsibilities and the acknowledgment of achievements within the system. To address this gap, a project has been initiated to develop and integrate these functionalities into the Expertiza system through an API framework built on Rails.

== Design ==
The project entails revamping and improving the Duties and Badges modules within an API framework constructed on Rails. In duties_controller.rb, actions for handling duties, such as creation, editing, updating, and deletion, in the Expertiza system are defined. Conversely, badges_controller.rb manages the creation of Badge instances, enabling users to define badge parameters and optionally attach an image file, which is then saved and linked with the badge.

The primary focus of the project is to implement these functionalities as RESTful API endpoints, adhering strictly to JSON response standards. Comprehensive testing, covering both positive and negative scenarios, is imperative to validate the accuracy and resilience of the implemented features. Additionally, prioritizing security, error handling, and validation is crucial for maintaining data integrity and thwarting potential vulnerabilities. The reimplementation must adhere to Rails conventions and adhere to best practices, promoting maintainability and scalability while ensuring smooth integration with other modules in the Expertiza system.

=== Test Driven Development (TDD) ===
Our approach to developing Expertiza duties and bages controller will adhere to a test-driven design methodology. This means that we will be utilizing the test skeletons provided to us and tests for each component of the each module before implementing the corresponding functionalities. By following this rigorous testing approach, we ensure a reliable and thoroughly validated system, enhancing the overall quality and robustness of the Expertiza platform.

=== Objectives ===

* Create: Develop methods in duties_controller and badges_controller to facilitate the creation of new Duties and Badges, respectively. These methods will allow instructors and system administrators to input necessary details such as duty descriptions, badge criteria, and associated rewards.

* Read: Implement show actions within both controllers to enable users to retrieve and view details of specific Duties and Badges. This includes viewing duty responsibilities, badge criteria, and any rewards associated with the completion of duties or earning of badges.

* Update: Add update methods in duties_controller and badges_controller to allow for the modification of existing Duties and Badges. This functionality will enable the adjustment of details such as duty parameters and badge criteria to keep the system’s content current and relevant.

* Delete: Create destroy actions in both controllers to support the deletion of Duties and Badges that are no longer needed or relevant. This will assist in maintaining a clean and efficient database, removing outdated or unnecessary information.

* Index: Enhance the index actions in both duties_controller and badges_controller to list all Duties and Badges, respectively, providing users with an overview of available duties and badges. The index view will be optimized for ease of access and clarity, making it simpler for users to navigate and manage duties and badges within the system.

=== Test Plan ===
* cURL shall be used to simulate HTTP requests
* Only an Admin shall create a test

== Implementation ==
=== Duties Controller ===

'''

class Api::V1::DutiesController < ApplicationController
before_action :set_duty, only: %i[ show update destroy ]

'''index Method:'''

Function: Retrieves all duties.

HTTP Verb: GET

URL Endpoint: /duties

Description: Fetches all duties from the database using the Duty.all method and renders a JSON response containing all duties.
# GET /duties
def index
@duties = Duty.all
render json: @duties
end

'''show Method:'''

Function: Retrieves a specific duty.

HTTP Verb: GET

URL Endpoint: /duties/:id

Description: Finds a duty by its ID and renders a JSON response containing the specific duty
# GET /duties/1
def show
render json: @duty, status: :ok
end

'''create Method:'''

Function: Creates a new duty.

HTTP Verb: POST

URL Endpoint: /duties

Description: Creates a new duty by instantiating a Duty object with the provided duty parameters from the request (duty_params).
# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
render json: @duty, status: :created, location: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''update Method:'''

Function: Updates an existing duty.

HTTP Verb: PATCH/PUT

URL Endpoint: /duties/:id

Description: Updates an existing duty specified by its ID using the provided duty parameters from the request (duty_params).
# PATCH/PUT /duties/1
def update
if @duty.update(duty_params)
render json: @duty
else
render json: @duty.errors, status: :unprocessable_entity
end
end

'''destroy Method:'''

Function: Deletes a duty.

HTTP Verb: DELETE

URL Endpoint: /duties/:id

Description: Finds a specific duty by its ID and destroys (deletes) it. It then renders a JSON response with a success message
# DELETE /duties/1
def destroy
@duty.destroy
render json: { message: "Duty was successfully destroyed." }, status: :ok
end

'''set_duty Method (Private):'''

This technique serves as a callback to establish the @duty instance variable by locating the duty according to the :id parameter. It is applied prior to the show, update, and destroy actions to prepare the specific duty undergoing operation.

private
# Use callbacks to share common setup or constraints between actions.
def set_duty
@duty = Duty.find(params[:id])
end

'''duty_params Method (Private):'''

This process filters the duty parameters received from the request, permitting only designated parameters (:name, :assignment_id, :max_members_for_duties) for creating or updating a duty. It utilizes Rails' strong parameters feature for security purposes.

# Only allow a list of trusted parameters through.
def duty_params
params.require(:duty).permit(:name, :assignment_id, :max_members_for_duties)
end
end

'''

=== Badges Controller ===

'''
class Api::V1::BadgesController < ApplicationController
before_action :set_badge, only: %i[ show update destroy ]

'''index Method:'''

HTTP Verb: GET

Endpoint: /badges

Functionality: Retrieves all badges.

Description: Fetches all existing badges from the database using Badge.all and returns a JSON array containing all badge records.

# GET /badges
# Lists all badges
def index
@badges = Badge.all
render json: { badges: @badges }, status: :ok
end

'''show Method:'''

HTTP Verb: GET

Endpoint: /badges/:id

Functionality: Retrieves a specific badge.

Description: Finds and retrieves a particular badge by its ID from the database. The method responds with a JSON object containing the details of the specific badge.
# GET /badges/1
# Shows a single badge
def show
render json: { badge: @badge }, status: :ok
end

'''create Method:'''

HTTP Verb: POST

Endpoint: /badges

Functionality: Creates a new badge.

Description: Instantiates a new badge using the parameters provided in the request (badge_params).
# POST /badges
# Creates a new badge
def create
@badge = Badge.new(badge_params)

if @badge.save
render json: { badge: @badge }, status: :created
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''update Method:'''

HTTP Verb: PATCH/PUT

Endpoint: /badges/:id

Functionality: Updates an existing badge.

Description: Modifies the attributes of an existing badge based on the parameters received in the request (badge_params).
# PATCH/PUT /badges/1
# Updates an existing badge
def update
if @badge.update(badge_params)
render json: { badge: @badge }, status: :ok
else
render json: { errors: @badge.errors.full_messages }, status: :unprocessable_entity
end
end

'''destroy Method:'''

HTTP Verb: DELETE

Endpoint: /badges/:id

Functionality: Deletes a badge.

Description: Locates a specific badge by its ID and removes it from the database.
# DELETE /badges/1
# Deletes a badge
def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

'''set_badge Method (Private):'''

Function: Sets up a specific badge for other actions.

Description: This callback function locates and assigns the @badge instance variable according to the :id parameter before executing the show, update, and destroy actions.

private
# Use callbacks to share common setup or constraints between actions.
def set_badge
@badge = Badge.find(params[:id])
end

'''badge_params Method (Private):'''

Function: Filters and permits badge parameters for security.

Description: This process screens the badge parameters received via the request, permitting only certain parameters (:name, :description, :image_name, :image_file) to be utilized for creating or updating a badge.
# Only allow a list of trusted parameters through.
def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
'''

=== Database Setup ===
==== 1. Create an Institution ====
Open shell on the mysql server and run:
mysql -u dev -pexpertiza
use reimplementation_development;

Then run the followinginsert command:
INSERT INTO institutions (name, created_at, updated_at) VALUES ('North Carolina State University', NOW(), NOW());

==== 2. Obtain an Encrypted Password ====
Open a new terminal in the container reimplementation-back-end-app and run the following commands
rails console
BCrypt::Password.create('password123')

You should obtain a string like the following but it will not match:
'$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG'

This will be placed as the password in the next step.

==== 3. Create an Admin User ====
Now, in the mysql terminal run the following (replacing the ‘$2a…’ with the one generated in step 2)

INSERT INTO users (name, email, password_digest, role_id, created_at, updated_at, full_name, institution_id) VALUES ('admin', 'admin2@example.com', '$2a$12$TWct/jRMKbb1Pm1NtxKmPuAkk8IOIHnJyBaU4eiMQ5MjV41Se0AXG', 1, NOW(), NOW(), 'admin admin', 1);

==== 4. Start the Server ====
At this point we can start the server to issue cURL commands once the server is running.
Start rails server on port 3002
rails s -p 3002

=== cURL User Required Setup ===
==== 1. Login as an User and Get Bearer Token ====
Get bearer token first (for instructor):

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d '{"user_name": "admin", "password": "password123"}'

Note: You can use curl commands from the Windows command prompt, but you cannot use single quotes. For example the above JSON command must be written for Windows:

curl -X POST http://localhost:3002/login -H "Content-Type: application/json" -d “{\"user_name\": \"admin\", \"password\": \"password123\"}”

Also, RubyMine has an option to construct HTTP requests from cURL commands.
Tools->HTTP Client->Convert cURL to HTTP Request

[[File:CSC517Fall2023_E2376_Convert_cURL_RubyMine_.png|100px]]

Issuing the HTTP requests will return a Bearer Token that must be included while accessing other pages as an Instructor

==== 2. User Creates Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.
Be sure the ids match the database ids for the assignments.
curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test duty 1",
"max_members_for_duty": 2,
"assignment_id": 1
}'

==== 3. User can see all available Duties ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 4. User can see a particular Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the duty.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 5. User can update a Duty====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty and assignments.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test",
"max_members_for_duty": 3,
"assignment_id": 1
}'

==== 6. User can delete a Duty ====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the duty.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/duties/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 7. User Creates Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'POST' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge 3",
"description": "testing creation of badge 3",
"image_file": ""
}'

==== 8. User can see all available Badges====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 9. User can see a particular Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an instructor.
Be sure the ids match the database ids for the badge.

curl -X 'GET' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

==== 10. User can update a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'PATCH' \
'http://127.0.0.1:3002/api/v1/badges/1' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg' \
-H 'Content-Type: application/json' \
-d '{
"name": "test badge_1",
"description": "testing",
"image_file": ""
}'

==== 11. User can delete a Badge====
Execute the following command. Make sure the Bearer Token matches what was obtained in step 1 when logging in as an User.

Be sure the ids match the database ids for the badge.

curl -X 'DELETE' \
'http://127.0.0.1:3002/api/v1/badges/3' \
-H 'accept: /' \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwiZnVsbF9uYW1lIjoiYWRtaW4gYWRtaW4iLCJyb2xlIjoiU3VwZXIgQWRtaW5pc3RyYXRvciIsImluc3RpdHV0aW9uX2lkIjoxLCJleHAiOjE3MTEzNDEzOTl9.GNjSZGuZnmCJVWRtwKORMgMtV6f9wiHlWzH7weLMq3z3ipTU2qw6SMoDZsSoNnRlDerknzcIaz8sccrjWdQ6CGT_IDavygi0GQzA9t8l4HZtDCObmcGRiFyFEkYoJHfxw6M2F_AQC9Csl_FgUFbQCxj-goFfVYZxs-YkXnqMl_nJFKeQRWrhkSEW-_sJm0IUw8ytmo3TuOEwbuNWwHI6EjH3acB5o4WBZxBfJPbKb3OoFEMYe-vjf6lnpLn4mIBhHrnrgNFe8AxMiqV0CuOe6Yl8MqMMyCEzf9k_1aXIpb3nqHlBATRzjrZh7vS-YDqt0bUCYNHPsSINdPqVrzhLFg'

== Conclusion ==
In summary, the reimplementation project for the Duties and Badges modules in Expertiza is crucial for bringing existing functionalities in line with API standards and addressing identified shortcomings from the previous implementation.

The Duties module, managed through duties_controller.rb, is central to handling duties' creation, editing, and deletion within the system. Similarly, the Badges module, governed by badges_controller.rb, oversees badge creation and management, including handling image files.

The main issues with the previous implementation stemmed from treating the system as a traditional Rails MVC application rather than as a Rails API. This resulted in non-compliance with API standards in request and response handling, which this reimplementation aims to fix. Furthermore, deficiencies in testing procedures underscored the need for comprehensive testing to ensure system robustness and reliability.

The planned work involves strict adherence to API-style interactions, returning data in JSON format, and implementing thorough testing for all REST endpoints to ensure robust verification of Duties and Badge functionalities across various scenarios.

By addressing these issues and carefully implementing planned functionalities, this reimplementation aims to improve system efficiency, robustness, and adherence to API conventions, ultimately providing a more reliable and scalable platform for managing duties and badges within Expertiza.

== Useful Links ==

== Contributors ==
'''Group members:'''

Akhilsai Chittipolu

Koushik Gudipelly

Sri Vaishnavi Mylavarapu

'''Mentor:'''

Chunduru Chetana