Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T20:19:01Z

Sstangad: /* Test Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

[https://github.com/expertiza/expertiza/blob/main/app/controllers/duties_controller.rb Here is the previous implementation of the duties_controller.rb]

The class diagram below explains how the classes and the objects interact with each other. Also, it gives a brief idea about the implementation of the operations implemented in the Controllers.
[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Swagger UI'''

As part of our testing process, we have implemented Swagger UI automated testing to thoroughly test the DutiesController and BadgesController, as well as the Duty and Badge model classes. Swagger UI is a tool that allows us to test each API endpoint by sending HTTP requests and receiving responses.

To ensure that each endpoint is working correctly, we have created test cases for each route of the DutiesController and BadgesController. For each test case, we make a valid request with the correct parameters and verify that the expected response is obtained. This helps us ensure that each endpoint is capable of processing requests and returning the correct output.

In addition to testing valid requests, we have also tested for invalid requests. This involves submitting requests with an incorrect number of parameters, invalid parameter types, and values that do not meet the validation requirements of the endpoint. When testing invalid requests, we expect the endpoint to return a status 422 Invalid Request as the response. By testing invalid requests, we can ensure that each endpoint is capable of handling unexpected inputs and responding appropriately.

By employing Swagger UI automated testing, we have been able to thoroughly test each API endpoint and ensure that they are capable of handling both valid and invalid requests. This helps us ensure that our API functions as intended and that any issues are caught early in the development process.
Here are some snapshots of the API testing done using Swagger:

[[ File: API screenshots.png | 850px ]]

[[ File: APi screenshots1.png | 850px ]]

[[ File: API screenshot2.png | 850px ]]

'''Testing with RSpec'''

As part of our testing process, we have implemented RSpec test cases to thoroughly test our code base. Using RSpec allows us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we have the ability to write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By utilizing RSpec, we have greater confidence in the correctness of our code and can quickly identify any issues that may arise as changes are made. We have already employed RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

Specifically, for the BadgesController and DutiesController, we have written test cases to thoroughly test the CRUD operations and their associated functionalities. We have tested API functionalities by writing test cases for the get, patch, and post API calls. For example, we can write a test case to ensure that the controller behaves as intended when a user attempts to update a badge. This involves verifying that the update request is received by the controller, the badge is updated in the database with the correct information, and the updated badge is returned in the response. By writing test cases in this manner, we can ensure that our API functions as intended and any issues are caught early in the development process.

Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T20:14:41Z

Sstangad: /* Test Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

[https://github.com/expertiza/expertiza/blob/main/app/controllers/duties_controller.rb Here is the previous implementation of the duties_controller.rb]

The class diagram below explains how the classes and the objects interact with each other. Also, it gives a brief idea about the implementation of the operations implemented in the Controllers.
[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Swagger UI'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Here are some snapshots of the API testing done using Swagger:

[[ File: API screenshots.png | 850px ]]

[[ File: APi screenshots1.png | 850px ]]

[[ File: API screenshot2.png | 850px ]]

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

File:API screenshot2.png

2023-05-03T20:10:30Z

Sstangad:

File:APi screenshots1.png

2023-05-03T20:09:58Z

Sstangad:

File:API screenshots.png

2023-05-03T20:09:32Z

Sstangad:

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T20:08:57Z

Sstangad: /* Test Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

[https://github.com/expertiza/expertiza/blob/main/app/controllers/duties_controller.rb Here is the previous implementation of the duties_controller.rb]

The class diagram below explains how the classes and the objects interact with each other. Also, it gives a brief idea about the implementation of the operations implemented in the Controllers.
[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Swagger UI'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Here are some snapshots of the API testing done using Swagger:

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T20:05:37Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

[https://github.com/expertiza/expertiza/blob/main/app/controllers/duties_controller.rb Here is the previous implementation of the duties_controller.rb]

The class diagram below explains how the classes and the objects interact with each other. Also, it gives a brief idea about the implementation of the operations implemented in the Controllers.
[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T20:03:02Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

The class diagram below explains how the classes and the objects interact with each other. Also, it gives a brief idea about the implementation of the operations implemented in the Controllers.
[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-05-03T19:59:55Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' The BadgesController has been re-implemented in a more efficient and object-oriented manner by adhering to the RESTful API for the controller. The controller logic has been split into two separate parts: the Badge model and the BadgesController controller. Previously, all CRUD methods and dependent methods were contained in the same controller class, which went against the principles of the MVC pattern. As part of the changes, the dependent and validation methods have been relocated to the Badge.rb model class, which has made it much easier and more intuitive for coders to work with the code. These changes have already been implemented and are now in effect.
Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
before_action :set_badge, only: [:show, :edit, :update, :destroy]
before_action :set_return_to, only: [:new]

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

def new
@badge = Badge.new
render json: { badge: @badge }, status: :ok
end

def show
render json: { badge: @badge }, status: :ok
end

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

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

def destroy
@badge.destroy
render json: { message: "Badge was successfully destroyed." }, status: :ok
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name, :image_file)
end
end
</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-25T03:31:24Z

Sstangad: /* Test Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Swagger UI automated testing to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Swagger UI will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T02:38:19Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

[[File: Duty 1.png | 700px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:47:16Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated.

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project. Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File: ArchitectDiagram.png | 800px]]

Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

File:ArchitectDiagram.png

2023-04-13T00:45:18Z

Sstangad:

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:44:02Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project.Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File:Arch Diagram.png | 800px]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

File:Arch Diagram.png

2023-04-13T00:43:23Z

Sstangad:

File:Architecture Diagram.jpeg

2023-04-13T00:41:14Z

Sstangad:

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:40:45Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

The MVC architecture is well-suited for object-oriented principles-focused projects or applications because it follows the principles of separation of concerns, modularity, and extensibility. Separating the application into three distinct components, each with a specific responsibility, it allows for greater flexibility in making changes and adding new features without affecting the entire system. Furthermore, the MVC architecture promotes code reuse, since each component can be designed and tested independently. This results in cleaner, more maintainable code and can reduce the overall development time and cost of the project.Overall, the MVC architecture is an effective way to organize and structure complex object-oriented projects or applications, providing a solid foundation for software development that is easily maintainable and scalable.

[[File:Example.jpg]]

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:38:23Z

Sstangad:

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

==References==

https://vahid.blog/post/2021-04-16-understanding-the-model-view-controller-mvc-pattern/

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:25:33Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Test Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:24:22Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

* Sample test cases for '''BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:24:06Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

*'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:23:50Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''Testing with Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''Testing with RSpec'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:22:57Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''API testing using Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''RSpec Test Cases'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:22:47Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''API testing using Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

'''RSpec Test Cases'''

We will also be using RSpec test cases for testing the code base. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:22:14Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''API testing using Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

'''RSpec Test Cases''''

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:21:49Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

'''API testing using Postman'''

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:11:29Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

*'''Sample test cases for BadgesController:'''

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:10:44Z

Sstangad: /* Design and Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:09:10Z

Sstangad: /* Contributors */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:08:26Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file:
fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec',
'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:07:20Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end

context "with invalid attributes" do
it "does not create a new badge" do
expect {
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.not_to change(Badge, :count)
end

it "renders the new template" do
post :create, params: { badge: { name: "", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to render_template(:new)
end
end
end
</pre>

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-13T00:05:06Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

<pre>
RSpec.describe BadgesController, type: :controller do
describe "GET #index" do
it "returns a successful response" do
get :index
expect(response).to be_successful
end

it "assigns all badges to @badges" do
badge = Badge.create(name: "Test Badge", description: "This is a test badge")
get :index
expect(assigns(:badges)).to eq([badge])
end
end
</pre>

<pre>
describe "POST #create" do
context "with valid attributes" do
it "creates a new badge" do
expect {
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
}.to change(Badge, :count).by(1)
end

it "redirects to the badges index page" do
post :create, params: { badge: { name: "Test Badge", description: "This is a test badge", image_file: fixture_file_upload(Rails.root.join('spec', 'fixtures', 'badge.png'), 'image/png') } }
expect(response).to redirect_to(badges_url)
end
end
</pre>

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-12T23:58:32Z

Sstangad: /* Testing Methodology */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

For the BadgesController as well as the DutiesController, we have the scope to write the test cases and test the CRUD operations and their functionalities. We can test the API functionalities by writing test cases for testing the get, patch, and post API calls. The following is an example test case of how we can test and write the scripts for the controller. Given below is a example of an RSpec test case for BadgesController and its operations:

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-12T18:49:12Z

Sstangad: /* Design Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design and Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-12T16:19:38Z

Sstangad: /* Implementation */

==Problem Statement==

The problem at hand involves the Duties and Badge modules of Expertiza. Mainly, the task is to improve the code logic and design by following the Object Oriented Design principles and methods and make the code base more efficient, easy to read and structured. We have two controller classes "duties_controller.rb" and "badge_controller.rb".

The duties_controller in the Duties module defines several actions, including create, edit, update, and delete. The create action is used to save the new duty to the database, while the edit action renders the form for editing an existing duty. The update action updates the duty in the database, and the delete action deletes a duty from the database.

On the other hand, the Badge module has a create action that creates a new Badge instance using user parameters and saves an image file if attached. It also updates the image_name attribute of the badge instance. Additionally, there is a new action that sets up a new Badge instance and a redirect_to_assignment method to redirect to the previous page visited by the user. This method is used with the new action to keep track of the page the user was on when they requested a new Badge instance.

The task is to ensure that the Duties and Badge modules function correctly and that the create, edit, update, delete, and new actions all work as intended as well as to optimize, restructure and reimplement the code by following the Object Oriented way. This will help manage duties and badges in Expertiza effectively.

==Aim of this Project==
The aim of this Project is:

#Re-implementing CRUD operations for each controller
#Fix bugs and minor flows in the existing code base and functionality
#Removing redundant or unclear code logic
#Writing RSpec test scripts for both the controllers

By meeting these objectives, both controllers can perform their fundamental create, read, update, and delete operations, while also improving the code's readability and functionality. Additionally, it will aid in addressing any current bugs, thereby enhancing the accuracy of the code.

==Design Implementation==

We have given two controllers, duties_controller.rb and badges_controller.rb where we have to reimplement the code using a more object-oriented and efficient way. One potential way to refactor this code in a more object-oriented and efficient manner is to extract responsibilities into smaller objects with clear roles and interfaces. This can help reduce complexity and coupling between different parts of the system, making it easier to maintain and extend over time. Additionally, adopting design patterns and principles like SOLID can help improve the overall quality and modularity of the codebase. Overall, investing time and effort in improving the design and architecture of the code can pay off in the long term by reducing technical debt and enabling faster and more effective development.

After gaining a grasp of the system's flow, we delved into the code within the controllers. Upon initial inspection, it became apparent that the controllers were managing all of the CRUD operations but there were some minor changes that can enhance it and make it more readable and easy to understand. We discerned which functionalities did not pertain to the duties_controler as well as the badges_controller and determined which redundant code should be eliminated. Our reimplementation project has addressed the following issues:

*'''duties_controller.rb:''' To reimplement the DutiesController in a more modular, reusable and efficient, we can do the following changes :-
# Check if the user is authorized to perform the actions on the resource.
# Removed the action_allowed? method.
# As the record is already found, we can remove 'find' from 'update_attributes'.
# Changed the delete action to destroy for consistency with Rails conventions.
# Add a rescue block in set_duty to handle cases when the duty record is not found.
# Display errors in a more user friendly format.
# Remove 'AuthorizationHelper' since we are using 'authorize_resource'.
# Change the parameter fetching of assignment_id to '@duty.assignment_id' as this increases dependency on user input a lot.
# Removing unnecessary semicolons.

Here is the previous code of the 'duties_controller.rb'

<pre>
# frozen_string_literal: true

class DutiesController < ApplicationController
include AuthorizationHelper

# duties can be created/modified by Teaching Assistants, Instructor, Admin, Super Admin
def action_allowed?
current_user_has_ta_privileges?
end

before_action :set_duty, only: %i[show edit update destroy]

# GET /duties
def index
@duties = Duty.all
end

# GET /duties/1
def show; end

# GET /duties/new
def new
@duty = Duty.new
@id = params[:id]
end

# GET /duties/1/edit
def edit; end

# POST /duties
def create
@duty = Duty.new(duty_params)

if @duty.save
# When the duty (role) is created successfully we return back to the assignment edit page
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully created.'
else
redirect_to_create_page_and_show_error
end
end

# PATCH/PUT /duties/1
def update
@duty = Duty.find(params[:id])

if @duty.update_attributes(duty_params)
redirect_to edit_assignment_path(params[:duty][:assignment_id]), notice: 'Role was successfully updated.'
else
redirect_to_create_page_and_show_error
end
end

def delete
@duty = Duty.find(params[:id])
@duty.destroy
redirect_to edit_assignment_path(params[:assignment_id]),
notice: 'Role was successfully deleted.'
end

private

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

def redirect_to_create_page_and_show_error
error_messages = []
@duty.errors.each { |_, error| error_messages.append(error) }
error_message = error_messages.join('. ')
flash[:error] = error_message
redirect_to action: :new, id: params[:duty][:assignment_id]
end

def duty_params
params.require(:duty).permit(:assignment_id, :max_members_for_duty, :name)
end
end
</pre>

The following is the existing code for 'duty.rb':
<pre>
class Duty < ApplicationRecord
belongs_to :assignment
# validates name with format matching regex, length to be at least 3 and
# same name cannot be assigned to multiple duties in particular assignment.
validates :name,
format: { with: /\A[^`!@#\$%\^&*+_=]+\z/,
message: 'Please enter a valid role name' },
length: {
minimum: 3,
message: 'Role name is too short (minimum is 3 characters)'
},
uniqueness: {
case_sensitive: false, scope: :assignment,
message: 'The role "%{value}" is already present for this assignment'
}
validates_numericality_of :max_members_for_duty,
only_integer: true,
greater_than_or_equal_to: 1,
message: 'Value for max members for role is invalid'

# E2147 : check if the duty selected is available for selection in that particular team. Checks whether
# current duty count in the team is less than the max_members_for_duty set for that particular duty
def can_be_assigned?(team)
max_members_for_duty > team.participants.select { |team_member| team_member.duty_id == id }.count
end
end
</pre>

*'''badges_controller.rb:''' To reimplement the BadgesController in a more object-oriented and efficient way, you could split it into a Badge model and a BadgesController controller, following the Model-View-Controller (MVC) pattern. Earlier, all the CRUD methods as well as the dependent methods were written in the same controller class which is not much of the preferred way to write code logic in an MVC pattern and follow the principles. We planned to move the dependent and validation method to the Badge.rb model class where it would be more easier and coder-friendly to understand and work with the code in the future as well.

Here is the previous code of the "badges_controller.rb"

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

def action_allowed?
current_user_has_ta_privileges?
end

def new
@badge = Badge.new
session[:return_to] ||= request.referer
end

def redirect_to_assignment
redirect_to session.delete(:return_to)
end

def create
@badge = Badge.new(badge_params)
image_file = params[:badge][:image_file]
if image_file
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_file.original_filename), 'wb') do |file|
file.write(image_file.read)
end
@badge.image_name = image_file.original_filename
else
@badge.image_name = ''
end

respond_to do |format|
if @badge.save
format.html { redirect_to session.delete(:return_to), notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end
</pre>

Here is how we planned to implement the "Badge.rb" model class:

This model will handle the validations and image upload for the Badge object. The upload_image method can be called from the create action in the BadgesController to save the image to the file system.

<pre>
class Badge < ApplicationRecord

def self.upload_image(image_file)
return '' unless image_file

image_name = image_file.original_filename
File.open(Rails.root.join('app', 'assets', 'images', 'badges', image_name), 'wb') do |file|
file.write(image_file.read)
end
image_name
end
end

</pre>

Similarly, we planned to re-implement the BadgesController.rb as follows:

This BadgesController now follows the RESTful conventions, which makes it easier to understand and maintain. It also leverages the Badge model to handle the validations and image upload.

<pre>
class BadgesController < ApplicationController
include AuthorizationHelper

before_action :set_return_to, only: [:new]
before_action :set_badge, only: [:show, :edit, :update, :destroy]

def action_allowed?
current_user_has_ta_privileges?
end

# GET /badges
def index
@badges = Badge.all
end

# GET /badges/new
def new
@badge = Badge.new
end

# POST /badges
def create
@badge = Badge.new(badge_params)
@badge.image_name = Badge.upload_image(params[:badge][:image_file])

respond_to do |format|
if @badge.save
format.html { redirect_to redirect_to_url, notice: 'Badge was successfully created' }
else
format.html { render :new }
format.json { render json: @badge.errors, status: :unprocessable_entity }
end
end
end

# PATCH/PUT /badges/1
def update
if @badge.update(badge_params)
redirect_to @badge, notice: 'Badge was successfully updated.'
else
render :edit
end
end

private

def set_badge
@badge = Badge.find(params[:id])
end

def set_return_to
session[:return_to] ||= request.referer
end

def redirect_to_url
session.delete(:return_to) || badges_url
end

def badge_params
params.require(:badge).permit(:name, :description, :image_name)
end
end

</pre>

==Testing Methodology==

For testing the DutiesController and BadgesController, as well as the Duty and Badge model classes, we plan to employ Postman to test each route of the DutiesController and BadgesController. We plan to test if the expected response is obtained by making valid requests using the correct parameters for each endpoint.

In addition, we will check if each method behaves as anticipated by making requests with an incorrect number of parameters, invalid parameter types, and values, and checked if the endpoint throws a status 422 Invalid Request as the response. Testing via Postman will help ensure that each API endpoint handled both valid and invalid requests and behave as intended.

Moreover, we will be using RSpec test cases. This will allow us to write tests that are independent of any external dependencies and can be easily run to validate the functionality of our code. With RSpec, we can write unit tests that focus on individual pieces of functionality and integration tests that test the interactions between different components. By using RSpec, we can have greater confidence in the correctness of our code and quickly identify any issues that may arise as changes are made. We look forward to utilizing RSpec to ensure that our DutiesController, BadgesController, Duty, and Badge model classes are thoroughly tested and free of errors.

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. 
The contributors: 
Sanket Tangade(sstangad@ncsu.edu) 
Kunal Patil(kpatil5@ncsu.edu) 
Yash Sonar(ysonar@ncsu.edu)

Mentor: 
Kartiki Bhandakkar(kbhanda3@ncsu.edu)

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T01:13:32Z

Sstangad: /* Testing Methodology */

E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T01:07:53Z

Sstangad: Sstangad moved page E2347. Reimplement duties controller.rb and badges controller.rb to CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb: Include more details in title

#REDIRECT [[CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb]]

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T01:07:53Z

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T00:55:22Z

Sstangad: /* Contributors */

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T00:53:56Z

Sstangad: /* Contributors */

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T00:51:10Z

Sstangad: /* Implementation */

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-08T00:49:30Z

Sstangad: /* Implementation */

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-07T22:13:09Z

Sstangad: /* Goals of this Project */

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-07T22:06:16Z

Sstangad:

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-07T22:04:13Z

Sstangad: Goals of this Project

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-07T21:40:28Z

Sstangad: Added Problem Statement

CSC/ECE 517 Spring 2023 -E2347. Reimplement duties controller.rb and badges controller.rb

2023-04-07T21:25:53Z

Sstangad: Create E2347. Reimplement duties_controller.rb and badges_controller.rb

==Problem Statement==

==Goals of this Project==
The goals of this Project are:

#Separating the responsibilities of the QuestionnairesController and QuestionsController
#Fix bugs in the existing functionality
#Implementing CRUD operations for each controller
#Discarding unused or unclear functionality
#Writing tests for the two controllers

By achieving these goals, both the controllers can have their basic CRUD functionalities as well as it will also ensure that the code readability and functionality of the code for the two controllers is increased. It will also help in resolving the existing bugs which will increase correctness of the code.

==Implementation==

==Testing Methodology==

== Relevant Links ==

==Contributors==
This feature was created as part of Dr. Edward Gehringer's "CSC/ECE 517: Object-Oriented Design and Development" class, Spring 2023. The contributors were:

CSC/ECE 517 Spring 2023 - E2319. Reimplement questionnaire.rb

2023-03-23T03:50:57Z

Sstangad: Added get_weighted_score

== Problem Description ==

The model for questionnaire needs to be reimplemented to account for new features of recent versions of Ruby and Rails. The reimplementation of this model should consider SOLID principles and implement design patterns where relevant. The reimplementation should also consider object-oriented fundamentals like readability, eliminating redundancy, polymorphism, etc. The features available in the Ruby/Rails framework can be leveraged to accomplish these goals.

== Methods Reimplemented ==

'''Model Validations & the “validate_questionnaire” method'''

[[File:Validations reimplementation.png|1300px]]

In reimplementing the validation functionality of the questionnaire model, the “validate_questionnaire” method was removed entirely as it added unnecessary complexity to display errors based on if statement conditions. To replace the functionality of the “validate_questionnaire” method, active record validations using helpers were added instead. Using Active Record validations allow for better leverage of Rails’ built-in framework rather than duplicating the work the Rails is already capable of by writing conditions and queries to determine when errors should display. This also keeps the implementation simpler and easier to manage when updates in the future are needed.

There were four instances for when errors should arise to the end user from the “validate_questionnaire” method: (1) when the maximum question score entered was less than 1, (2) when the minimum question score entered was less than 0, (3) when the minimum question score entered was greater than the maximum question score, and (4) when a questionnaire is created with the name of an existing questionnaire created by the same instructor.

The first three error instances were reimplemented using the Active Record validation helper “comparison.” The first error instance, when the maximum question score entered was less than 1, was accomplished by adding a comparison to ensure that the maximum question score is greater than 0, otherwise the message “The maximum question score must be a positive integer greater than 0” will display, which is a more descriptive message than the original. The second error instance was implemented similarly to the first except for the validation was created for the minimum question score and ensured that the value is greater than or equal to 0. The third error instance was reimplemented by adding a comparison between the minimum question score and the maximum question score toe ensure that the maximum is always greater than the minimum.

Lastly, the fourth error instance of the “validate_questionnaire” method, when a questionnaire is created with the name of an existing questionnaire created by the same instructor, was reimplemented by adding the Active Record validation helper “uniqueness” to the existing name validation. In addition, the "uniqueness" helper had a scope added to ensure that uniqueness is only applied for the combination of name and instructor_id. The added uniqueness scope allows for the name to be the same on two questionnaires if created by two different instructors.

'''“get_weighted_score” and “compute_weighted_score” methods'''

These methods are used to fetch and calculate the weighted scores of all the questionnaires.
While reimplementing these methods, in the "get_weighted_score" method, instead of explicitly writing the nil check condition for the "used_in_round" attribute, the safe navigation operator "&" is used. This ensures that the code doesn't break if the object is nil as well as it gets rid of the check condition for the "nil" value as it is automatically handled by the "&" operator. Also, the "if-else" condition is replaced with the ternary operator for brevity and readability. The questionnaire_symbol is now being built using the string concatenation instead of calling "to_s" on the symbol and then concatenating the result with round.to_s. This is a more concise and readable way of building the symbol.

For the "compute_weighted_score" method, while reimplementing, instead of using the array indexing way to fetch data from the variables, the "dig" method is used to retrieve the :avg score from the scores hash. The "dig" method will return nil if any of the intermediate keys are nil, so it's safe to use here as the nil condition check is done by the dig method itself instead of explicitly writing it. The use of the ternary operator is again implemented in this method as well for brevity and readability. Overall, these changes should make the code more concise, efficient, and easier to read.

'''“true_false_questions?” method'''

[[File:Has_true_false_questions_reimplementation.png|1200px]]

When reimplementing this method, the name of the method was changed to “has_true_false_questions” to be more descriptive of what a true vs false return of this method means.

This method is checking to see if there are any true/false questions associated with a questionnaire. If there are, it returns true. If there are not, the method returns false.

The original implementation of this method used the “each” method of the Array object to loop through the associated question records and return true once it came across upon a question with the type “Checkbox.” In the updated implementation of this class, instead of using “each,” the “any?” method of the Array object is used. The “any?” method automatically returns true if the criterion is met and does not need it explicitly stated within the loop like in the original implementation, allowing for the removal of unnecessary syntax.

The logic this method is intended for is more suited for the “any?” method than the “each” method. This is because the original implementation using “each” was re-writing what “any?” already does. Using “any?” also allows for better readability as it is much clearer after the reimplementation that the method will return true if any question record meets the criteria (type equals ‘Checkbox’).

'''“delete” method'''

When evaluating the "delete" method for reimplementation, it was realized that this functionality is already being done by the questionnaires controller [https://github.com/expertiza/expertiza/blob/main/app/controllers/questionnaires_controller.rb#L143]. For this reason, this method was removed in the reimplementation of this model to follow the DRY principle.

'''“max_possible_score” method'''

[[File:Max_possible_score_reimplementation.png|1200px]]

The “max_possible_method” method adds the values of the “weight” attribute of each question record related to the questionnaire and then multiplies that sum by the “max_question_score” of the questionnaire.

The original implementation of this method included a complex and difficult to read query which was completing all of the calculations within it.

To make this more readable and easier to update in the future several updates were made. Firstly, the reimplementation separated the summation and the multiplication operations, so that it is easier to follow how the final value is calculated and allows ease of modifications in the future. Additionally, rather than using a complex query to sum the related questions’ weight values, the “sum” method of the Array object is used instead to take advantage of Ruby’s duck typing capability and the Enumerable mixin. Using the “sum” method significantly improves readability.

The reimplementation also takes advantage of the Distributive Property in math by ensuring that the sum is calculated before applying any multiplication, rather than multiplying each weight and then summing the multiplied values. The reimplementation ensures that the calculation ‘cost effective’ in terms of CPU cycles.

'''“self.copy_questionnaire_details” method'''

[[File:Copy questionnaire details.png|900px]]
[[File:Copy questionnaire details 2.png|900px]]

The “self.copy_questionnaire_details” method creates a cloned copy of the provided questionnaire for a given instructor, including the associated models such as Questions, and Question Advices for each Question.

The original implementation is very cluttered and difficult to read and interpret, as it creates new cloned objects for Questions and QuestionAdvice within the main method itself.

To improve this in the re-implementation, we have firstly used more descriptive and consistent nomenclature for the original and cloned objects for Questionnaire, Question and QuestionAdvice. Next, we have separated the methods for creation of clones for Questionnaire, Question and QuestionAdvice, thus making it more readable. We have also clearly marked the steps involved in the reimplementation to make it easier for the reader to understand the order of cloning operations involved within the method.

== Test Plan ==

The goal is to test every possible scenario. Since this is the reimplementation of a model, there are only system tests. The tests will leverage the RSpec framework and FactoryBot to stub associated records.

In order to properly stub, skeleton models of associations will be created (assignment, assignment_questionnaire, instructor, question, and questionnaire_node). Also, in order to stub successfully, tables for the associations will be created before all tests, and dropped after all tests.

'''Model Validations & the “validate_questionnaire” method'''

Tests are to be written to ensure proper validations were in place. Some of these will use the “shoulda matchers” gem to ensure implementation of the validations as the reimplementation will be done in TDD. Additionally, behavior should be tested by ensuring the validation errors arise when expected and by ensuring valid inputs are accepted.

For the name attribute, validation tests for behavior should ensure that a questionnaire without a name ''cannot'' be saved, a questionnaire with the same name as another questionnaire ''cannot'' be saved if the instructor is the same on both questionnaires, and a questionnaire with the same name as another questionnaire ''can'' be saved if the instructors are different on each questionnaire.

For testing the validations on the min_question_score and max_question_score attributes, tests should ensure that a non-numeric value entered in either the min_question_score or max_question_score fields ''cannot'' be saved, that the min_question_score ''cannot'' be saved unless it is 0 or greater, that the max_question_score ''cannot'' be saved unless it is 1 or greater, and that the questionnaire ''cannot'' be saved if the min_question_score is greater than the max_question_score. A test should also be written to confirm that the questionnaire ''can'' save successfully when valid inputs are entered for these attributes.

'''“get_weighted_score” and “compute_weighted_score” methods'''

'''“true_false_questions?” method'''

Three outcomes should tested for this method:

(1) confirming the method returns true if there is a true/false question related to the questionnaire,

(2) confirming the method returns false if there are questions related to the questionnaire but none are true/false, and

(3) confirming the method returns false if there are no questions related to the questionnaire at all.

'''“delete” method'''

Two outcomes should be tested for this method:

(1) Ensure that when a questionnaire without assignments enters this method, the questionnaire itself is destroyed along with its associated question records and questionnaire node record.

(2) Ensure that when a questionnaire with a related assignment enters this method, a Runtime Error is raised.

'''“max_possible_score” method'''

Three scenarios should be tested for this method to ensure calculation is correct:

(1) Ensure that the max_possible_score returned is what is expected when there are two related questions of different weights.

(2) Ensure that the max_possible_score changes to a different expected value when a third question is added to the questionnaire.

(3) Ensure that the max_possible_score changes to a different expected value when the same three questions from the second scenario are associated but the max_question_score value is changed on the questionnaire.

'''“self.copy_questionnaire_details” method'''
Test is written to ensure the expected behavior for fetching the related questions provided the questionnaire to be cloned and for fetching advices for each question.

== Test Coverage ==

After implementing tests, test coverage is nearly 100%:

[[File:Test_coverage_dbaidya.png|1000px]]

Below are test coverage details from SimpleCov:

[[File:Test_coverage_details.png|1200px]]