Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review

2024-12-05T04:18:28Z

Gwteague: /* Refactor ReviewBid Model */

== Project Overview ==

This project will fix the defects and improve the functionality in Expertiza of the Reviewer Bidding feature, a process where reviewers can bid for assignments they want to review. It will make the functionality smoother, more reliable, and align with Expertiza's collaborative learning objectives.

<span id="iii.-problem-statements"></span>

== Problem Statements ==

Assigning reviews to users on Expertiza involves a complex bidding algorithm that requires optimization before production deployment. Below are key areas we plan to address as per the project requirements:
* Code Refactoring and Best Practices
** '''Utilize Authentication Utilities''': Modify the <code>action_allowed</code> function in the <code>ReviewBidsController</code> to use existing authentication utilities, enhancing code reusability and adhering to the Single Responsibility Principle (SRP) and Separation of Concerns (SoC).
** '''Eliminate Code Duplication''': Refactor <code>review_bids_others_work</code> in the <code>SignUpSheetController</code> to comply with the Don't Repeat Yourself (DRY) principle.
** '''Rename Functions for Clarity''': Change <code>run_bidding_algorithm</code> in <code>ReviewBidsController</code> to <code>assign_reviewers</code> to better reflect its purpose.
** '''Refactor Methods in '''<code>review_bid.rb</code>''':''': Convert class methods to instance methods or relocate them to helper classes for improved code organization.
* Functionality Enhancements
** '''Handle Missing Bids Gracefully''': Adjust the bidding algorithm to accommodate students who do not bid, allowing them to select from the remaining options.
** '''Support Both Individual and Team Assignments''': Ensure the code functions correctly for participant and team-based assignments when signing up for topics.
* User Interface Improvements
** '''Increase Transparency in the Bidding Process''': Display messages indicating how many students are eligible to bid, how many have submitted bids, and the deadline.
** '''Accurate Bid Status Indicators''': Ensure topic colors change correctly based on the number of outstanding bids, providing clear visual feedback to users.
* Testing and Validation
** '''Exhaustive Edge Case Testing''': Conduct thorough testing for edge cases not previously covered, adding additional test cases as needed.

<span id="iv.-design-goals"></span>

== Design Goals ==

While addressing the existing defects and enhancing the Reviewer Bidding feature, we plan to adhere to the following design guidelines:

* Code Quality and Maintainability
** '''Improve Code Structure: '''Implement refactoring strategies to enhance code readability and maintainability, ensuring adherence to best practices like the DRY principle.
** '''Standardize Authentication Logic: '''Utilize a centralized authentication utility to promote consistency and reusability across the application.
* System Stability and Flexibility
** '''Enhance Algorithm Robustness: '''Modify the bidding algorithm to handle scenarios where students do not bid, ensuring the system remains stable under all conditions.
** '''Ensure Assignment Versatility: '''Design the system to seamlessly support both individual and team assignments without additional configuration.
* User Experience Enhancements
** '''Increase Bidding Transparency: '''Develop user interface elements that clearly display bidding status, deadlines, and participation metrics.
** '''Implement Dynamic Visual Feedback: '''Use real-time visual cues, such as color changes, to inform users about the bidding status instantly.
* Testing and Validation
** '''Develop Comprehensive Test Suites: '''Create extensive automated tests covering edge cases and critical functionalities to guarantee reliable system behavior.

<span id="v.-uml-diagram"></span>

== UML Diagram ==

Below is a visual representation of the models associated with the review bids functionality, depicting the data structures and their relationships.

[[File:Uml class diagram2.png|600px]]

<span id="vi.-implementation"></span>
'''ReviewBid: '''The <code>ReviewBid</code> manages the bidding process, where participants indicate their preferences for reviewing different topics or assignments. This helps distribute review tasks fairly based on participants' interests.

'''Assignment: '''The <code>Assignment</code> model represents team or individual assignments in Expertiza. It stores all the essential information required to keep the assignment process organized, like managing participants, setting due dates, forming teams, and overseeing the review process.

'''SignUpTopic: '''The <code>SignUpTopic</code> model identifies specific topics or areas within an assignment for which participants can sign up. It manages the availability of these topics, tracks bids, coordinates team sign-ups, and assigns topics based on both bids and participant availability.

'''Participant: '''The <code>Participant</code> model is about the individual users who participate in an assignment. This includes students, instructors, teaching assistants, or other relevant roles. This model is responsible for managing key user information, monitoring interactions with the assignment, keeping track of team memberships, and recording things like badges and review grades.

== Implementation ==

<span id="vi-1.-decoupling-authorization-logic-from-reviewbidscontroller"></span>
=== Decoupling Authorization Logic from <code>ReviewBidsController</code> ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| '''<code>action_allowed</code> needs to use the authentication utilities'''

The function <code>action_allowed</code> should use the available authentication utilities to support the Single Responsibility Principle and Separation of Concerns and to support code reusability.

| '''Authentication Consistency:''' Remove authentication logic in the controller and call logic in the authentication utility class instead to ensure consistent use of the same logic across the application, foster reusability, and eliminate DRY.

|-
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}
==== Authorization Flow Before Refactoring ====
The sequence diagram depicts the authorization process within the <code>ReviewBidsController</code>. When a user invokes an action, the controller checks if the action is allowed by verifying the user's role through the <code>current_role_name()</code> method in the <code>ApplicationController</code>. Depending on the action and the user's role, the controller either authorizes the user to proceed or denies access, ultimately executing the action logic if authorized and responding to the user.

[[File:Uml sequence 1.png|600px]]

<span id="vi-1-1.-reviewbidscontroller-updates"></span>

==== <code>ReviewBidsController</code> Updates ====

We simplified the <code>action_allowed?</code> method by decoupling authorization logic from the controller to use helper methods in the <code>AuthorizationHelper</code> module. The <code>ReviewBidsController</code> should not handle authentication, which is a violation of SRP.

{| class="wikitable" style="width:100%;"
|-
! style="vertical-align:top;" | Original Code !! style="vertical-align:top;" | Refactored Code
|-
| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index'
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[list].include? action_name) ? are_needed_authorizations_present?(params[:id], "participant", "reader", "submitter", "reviewer") : true)
else
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator'].include? current_role_name
end
end
</syntaxhighlight></div>
|| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index', 'list'
current_user_has_student_privileges? && list_authorization_check
else
current_user_has_ta_privileges?
end
end
</syntaxhighlight></div>
|}

=== Optimize <code>review_bids_others_work</code> Functionality ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| '''<code>review_bids_others_work</code> is a DRY violation'''<br />
The function <code>review_bids_others_work</code> violates DRY.
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}

<span id="vi-2-1.-signupsheetcontroller-updates"></span>
==== <code>SignUpSheetController</code> Updates ====

The ReviewBidsController's index method renders the review_bids_others_work action in <code>SignUpSheetController</code>. However, the <code>SignUpSheetController</code> does not include the controller action for this view. We need to find the old implementation of the controller action, add it back, and review and update it for any DRY violations.

<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# provides variables for reviewing page located at views/review_bids/others_work.html.erb
def index
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)

@assignment = @participant.assignment
@review_mappings = ReviewResponseMap.where(reviewer_id: @participant.id)

# Finding how many reviews have been completed
@num_reviews_completed = 0
@review_mappings.each do |map|
@num_reviews_completed += 1 if !map.response.empty? && map.response.last.is_submitted
end

# render view for completing reviews after review bidding has been completed
render 'sign_up_sheet/review_bids_others_work'
end
end
</syntaxhighlight>

<span id="vi-2-2.-reviewbidsotherswork-view-updates"></span>

==== <code>review_bids_others_work.html.erb</code> View Updates ====

The code only contains a view with this name and no associated controller action. Reviewing the code in the view, we noticed some SRP violations where there is much logic in the presentation layer. Set up helper methods in the controller to handle some of that logic or see if the model can handle some of that logic.

<span id="vi-2-3.-design-patternsprinciples"></span>

=== Rename <code>run_bidding_algorithm</code> method ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| <code>run_bidding_algorithm</code> should be <code>assign_reviewers</code>
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:''' Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

The primary activity here is to refactor the method name <code>run_bidding_algorithm</code> to <code>assign_reviewers</code> and fix the hardcoded URL. However, the match topic bidding algorithm no longer works since Heroku is no longer free, per the professor. The reference link below has detailed information about the web service that we can leverage to gain that understanding.

Reference Link for Webservice Details: [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review <u>match_topics webservice link details</u>]

<span id="vi-3-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to rename the <code>run_bidding_algorithm</code> method to <code>assign_reviewers</code> to make the functionality of the method clear. We also plan to verify that the method is working appropriately by mocking up the service call since it is no longer working.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Other methods

# Call webserver for running the assigning algorithm
# Passing to webserver:
# - student_ids
# - topic_ids
# - student_preferences
# - time_stamps
# Webserver returns:
# - matched assignments as JSON body
def run_bidding_algorithm(bidding_data)
url = 'http://app-csc517.herokuapp.com/match_topics' # Hard coding for the time being
response = RestClient.post url, bidding_data.to_json, content_type: 'application/json', accept: :json
JSON.parse(response.body)
rescue StandardError => e
Rails.logger.error "Bidding algorithm failed: #{e.message}"
false
end
end
</syntaxhighlight>

==== Updated Implementation ====
We implemented an update using mocked data and a service as placeholders until a new URL is in place. We did not end up refactoring to rename this method as we found that the name describes the functionality quite well.

==== review_bids_controller ====
<syntaxhighlight lang="ruby">
def run_bidding_algorithm
review_bid = ReviewBid.new
bidding_data = review_bid.bidding_data
matched_topics = BiddingAlgorithmService.new(bidding_data).run
raise ArgumentError, 'Failed to assign reviewers. Please try again later.' unless matched_topics

matched_topics
end
</syntaxhighlight>

==== bidding_algorithm_service ====

<syntaxhighlight lang="ruby">
# frozen_string_literal: true

# The `BiddingAlgorithmService` run the bid assignment algorithm
# Sends student IDs, topic IDs, student preferences, and timestamps to the web service
# The web service returns the matched assignments in the JSON response body
class BiddingAlgorithmService
SERVICE_URL = 'http://app-csc517.herokuapp.com/match_topics'.freeze

# MOCK_DATA is based on the documentation detailing how the webservice behaves.
# Reference: https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review#Webservice
MOCK_DATA = {
36239 => [3970, 3972, 3975],
36240 => [3973, 3974, 3972],
36241 => [3969, 3971, 3972],
36242 => [3969, 3971, 3973],
36243 => [3969, 3970, 3971]
}.freeze

def initialize(bidding_data)
@bidding_data = bidding_data
end

def run
return MOCK_DATA if Rails.application.config.use_mock_bidding_algorithm

perform_request
rescue RestClient::ExceptionWithResponse, JSON::ParserError
false
end

private

def perform_request
response = RestClient.post(
SERVICE_URL,
@bidding_data.to_json,
content_type: :json,
accept: :json
)

validate_response(response)
JSON.parse(response.body)
end

def validate_response(response)
raise 'Invalid response format' unless response.headers[:content_type] && response.headers[:content_type].include?('application/json')
end
end
</syntaxhighlight>

<span id="vi-3-2.-design-patternsprinciples"></span>

=== Resolve Functionality Issues for Non Bidders ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed to ignore anyone who didn’t bid, and let them choose from what’s left over.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-4-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to do several things within this controller. We will set a default state for non-bidders that we can point to to give them options to select topics to review from the leftovers. We will consolidate <code>@sign_up_topics</code> to resolve the DRY violation. Lastly, we will remove business logic from the show method and push it to a new helper to conform to the SRP.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Additional method

# Provides variables for review bidding page
def show
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment.id, private_to: nil)
my_topic = SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id)
@sign_up_topics -= SignUpTopic.where(assignment_id: @assignment.id, id: my_topic)
@num_participants = AssignmentParticipant.where(parent_id: @assignment.id).count
@selected_topics = nil # This is used to list the topics assigned to review (i.e., select == assigned)
@bids = ReviewBid.where(participant_id: @participant, assignment_id: @assignment.id)
signed_up_topics = []

@bids.each do |bid|
sign_up_topic = SignUpTopic.find_by(id: bid.signuptopic_id)
signed_up_topics << sign_up_topic if sign_up_topic
end

signed_up_topics &= @sign_up_topics
@sign_up_topics -= signed_up_topics
@bids = signed_up_topics
@num_of_topics = @sign_up_topics.size
@assigned_review_maps = []

ReviewResponseMap.where(reviewed_object_id: @assignment.id, reviewer_id: @participant.id).each do |review_map|
@assigned_review_maps << review_map
end

# Explicitly render view since it's in the sign up sheet views
render 'sign_up_sheet/review_bids_show'
end

# Additional methods
end
</syntaxhighlight>

<span id="vi-4-2.-reviewbidshelper-updates"></span>

===== Updated Implementation =====
<syntaxhighlight lang="ruby">
# Assigns bidding topics to reviewers
def assign_bidding
assignment = validate_assignment(params[:assignment_id])

reviewers = validate_reviewers(assignment.id)
reviewer_ids = reviewers.map(&:id)

matched_topics = run_bidding_algorithm

if matched_topics.blank?
flash[:alert] = 'Topic or assignment is missing'
redirect_back fallback_location: root_path && return
end

leftover_topics = find_leftover_topics(assignment.id, matched_topics)
assign_leftover_topics(reviewer_ids, matched_topics, leftover_topics)

ReviewBid.new.assign_review_topics(matched_topics)
assignment.update!(can_choose_topic_to_review: false)

flash[:notice] = 'Reviewers were successfully assigned to topics.'
redirect_back fallback_location: root_path
rescue ArgumentError => e
Rails.logger.error "ArgumentError: #{e.message}"
redirect_back fallback_location: root_path, alert: e.message
rescue ActiveRecord::RecordInvalid => e
Rails.logger.error "ActiveRecord::RecordInvalid: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers due to database error. Please try again later.'
rescue ActiveRecord::ActiveRecordError => e
Rails.logger.error "ActiveRecord::ActiveRecordError: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers due to database error. Please try again later.'
rescue StandardError => e
Rails.logger.error "StandardError: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers. Please try again later.'
end

private

#service methods here ...

def find_leftover_topics(assignment_id, matched_topics)
all_topic_ids = SignUpTopic.where(assignment_id: assignment_id).pluck(:id)
assigned_topic_ids = matched_topics.map { |match| match[:topic_id] }

# Calculate leftover topics
all_topic_ids - assigned_topic_ids
end

def assign_leftover_topics(reviewer_ids, matched_topics, leftover_topics)
return if leftover_topics.blank?

# Find non-bidders by excluding already matched reviewers
non_bidders = reviewer_ids - matched_topics.keys

# Assign leftover topics to non-bidders in a round-robin fashion
non_bidders.each_with_index do |reviewer_id, index|
topic_id = leftover_topics[index % leftover_topics.length]
ReviewBid.create(priority: 1, signuptopic_id: topic_id, participant_id: reviewer_id)
end
end

</syntaxhighlight>
<span id="vi-4-3.-design-patternsprinciples"></span>

=== Confirm Functionality for Single-person Teams ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Make sure your code works on individual assignments, i.e., assignments where participants sign up for topics instead of teams. In this case, a team is created for each participant when they sign up. So the code should work for assignments to which either individuals or teams submit.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to make an update to focus on topic rather than team or have it where teams are updated based on topic id.We will probably utilize sign up topic or a similar object to accomplish this.

<span id="vi-5-2.-design-patternsprinciples"></span>

=== Bid Status Messaging ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| To make the functionality more intuitive, include a message to say how many students are eligible to submit bids, how many have submitted their bids, when the deadline for submitting bids is.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-1"></span>
==== <code>ReviewBidsHelper</code> Updates ====

The logic for these messages will go into the helper file. It is effectively the same reasoning as our migration of other business/functionality code from the controller to the helper to conform to the SRP. It will go hand in hand with the SignUpTopic portion of the code.

<span id="vi-6-2.-design-patternsprinciples"></span>

=== Refactor <code>ReviewBid</code> Model ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-7-1.-reviewbid-model-updates"></span>
==== <code>ReviewBid</code> Model Updates ====
Since the current class methods are tied to <code>ReviewBid</code> model instances, we will change them to instance methods. There is no need to move them to helpers.

===== Review Bid Model Flow Before Refactoring =====
This sequence diagram describes how the <code>ReviewBidsController</code> interacts with the <code>ReviewBid</code> model in assigning review topics to reviewers according to their bids. Once the <code>assign_bidding</code> action is initiated by the user, the controller gathers the IDs of reviewers and calls <code>ReviewBid.bidding_data</code> to gather bidding information. That is sent out to an external bidding algorithm, and the matched topics that come back are used by <code>ReviewBid.assign_review_topics</code> to create <code>ReviewResponseMap</code> entries, assigning topics to reviewers for the assignment.

[[File:Uml sequence 2.png|800px]]

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBid < ApplicationRecord
belongs_to :topic, class_name: 'SignUpTopic'
belongs_to :participant, class_name: 'Participant'
belongs_to :assignment, class_name: 'Assignment'

# method to get bidding data
# returns the bidding data needed for the assigning algorithm
# student_ids, topic_ids, student_preferences, topic_preferences, max reviews allowed

def self.bidding_data(assignment_id, reviewer_ids)
# create basic hash and set basic hash data
bidding_data = { 'tid' => [], 'users' => {}, 'max_accepted_proposals' => [] }
bidding_data['tid'] = SignUpTopic.where(assignment_id: assignment_id).ids
bidding_data['max_accepted_proposals'] = Assignment.where(id: assignment_id).pluck(:num_reviews_allowed).first

# loop through reviewer_ids to get reviewer specific bidding data
reviewer_ids.each do |reviewer_id|
bidding_data['users'][reviewer_id] = reviewer_bidding_data(reviewer_id, assignment_id)
end
bidding_data
end

# assigns topics to reviews as matched by the webservice algorithm
def self.assign_review_topics(assignment_id, reviewer_ids, matched_topics, _min_num_reviews = 2)
# if review response map already created, delete it
if ReviewResponseMap.where(reviewed_object_id: assignment_id)
ReviewResponseMap.where(reviewed_object_id: assignment_id).destroy_all
end
# loop through reviewer_ids to assign reviews to each reviewer
reviewer_ids.each do |reviewer_id|
topics_to_assign = matched_topics[reviewer_id.to_s]
topics_to_assign.each do |topic|
assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
end
end
end

# method to assign a single topic to a reviewer
def self.assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
team_to_review = SignedUpTeam.where(topic_id: topic).pluck(:team_id).first
team_to_review.nil? ? [] : ReviewResponseMap.create(reviewed_object_id: assignment_id, reviewer_id: reviewer_id, reviewee_id: team_to_review, type: 'ReviewResponseMap')
end

# method for getting individual reviewer_ids bidding data
# returns user's bidding data hash
def self.reviewer_bidding_data(reviewer_id, assignment_id)
reviewer_user_id = AssignmentParticipant.find(reviewer_id).user_id
self_topic = SignedUpTeam.topic_id(assignment_id, reviewer_user_id)
bidding_data = { 'tid' => [], 'otid' => self_topic, 'priority' => [], 'time' => [] }
bids = ReviewBid.where(participant_id: reviewer_id)

# loop through each bid for a topic to get specific data
bids.each do |bid|
bidding_data['tid'] << bid.signuptopic_id
bidding_data['priority'] << bid.priority
bidding_data['time'] << bid.updated_at
end
bidding_data
end
end
</syntaxhighlight>

===== Updated Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBid < ApplicationRecord
belongs_to :topic, class_name: 'SignUpTopic'
belongs_to :participant, class_name: 'Participant'

# method to get bidding data
# returns the bidding data needed for the assigning algorithm
# student_ids, topic_ids, student_preferences, topic_preferences, max reviews allowed

# Instance method to get bidding data for this review bid
def bidding_data
{
'tid' => topic_ids,
'otid' => self_topic,
'priority' => priorities,
'time' => updated_times
}
end

# bid object to limit db touches for similar data acquisitions
def bids
@bids ||= ReviewBid.where(participant_id: participant_id)
end

def topic_ids
bids.pluck(:signuptopic_id)
end

def priorities
bids.pluck(:priority)
end

def updated_times
bids.pluck(:updated_at)
end

def self_topic
return nil unless topic && topic.assignment_id

SignedUpTeam.topic_id(topic.assignment_id, participant.user_id)
end

# Assign topics to reviews
def assign_review_topics(matched_topics)
validate_topics_and_assignment!(matched_topics)

ReviewResponseMap.where(reviewed_object_id: topic.assignment_id).destroy_all

matched_topics.each do |reviewer_id, topics|
Array(topics).each { |topic_id| assign_topic_to_reviewer(reviewer_id, topic_id) }
end
end

# Assign a single topic to a reviewer
def assign_topic_to_reviewer(reviewer_id, topic_id)
team_to_review = SignedUpTeam.where(topic_id: topic_id).pluck(:team_id).first
return if team_to_review.nil?

ReviewResponseMap.create(
reviewed_object_id: topic.assignment_id,
reviewer_id: reviewer_id,
reviewee_id: team_to_review,
type: 'ReviewResponseMap'
)
# error handling
rescue StandardError => e
Rails.logger.error("Failed to assign topic #{topic_id} to reviewer #{reviewer_id}: #{e.message}")
end

private

def validate_topics_and_assignment!(matched_topics)
raise ArgumentError, 'Topic or assignment is missing' if topic.nil? || topic.assignment_id.nil?
raise ArgumentError, 'Matched topics must be a Hash' unless matched_topics.is_a?(Hash)
end
end

</syntaxhighlight>

==== <code>ReviewBidsController</code> Updates ====

Once we change them to instance methods, we’ll need to modify their use in the code to instantiate the object first.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-3.-schema.db-updates"></span>

==== <code>Schema.db</code> Updates ====

We also need to remove the foreign key reference to <code>Assignment</code> in the <code>ReviewBid</code> model since the <code>Participant</code> model already has access to <code>Assignment</code>, and that is the <code>Assignment</code> we should be referencing. This will also involve modifying the database to remove the foreign key reference to the <code>Assignment</code>.

Steps required:

# Review the records in the <code>ReviewBid</code> table in the database to see if there are any records and if those records have values for <code>assignment_id</code>
# Create a migration file using the command: <code>rails generate migration RemoveAssignmentFromReviewBids</code>
# In the generated file, indicate the change that needs to be made using the change method and migration columns <code>remove_foreign_key</code> and <code>remove_column</code>. Migration should be straightforward since there is no cascading behavior (i.e., <code>dependent:destroy</code>) to worry about.
# Once comfortable with the updates to the generated file, run the migration using the <code>rails db:migrate</code> command.
# Run a query in the DB to ensure no orphaned records are in the <code>ReviewBid</code> table after the updates.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-4.-design-patternsprinciples"></span>

=== Implement Edge Case Testing ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing - link
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-2"></span>
==== <code>ReviewBidsHelper</code> Updates ====

<span class="mark">TODO</span>:We just got initial test results back. We still need to figure out why tests are failing and what may be slipping through the cracks.[[File:Test expertiza.png|411x459px]]

<span id="vi-8-2.-design-patternsprinciples"></span>

=== Design Patterns and Principles ===
Below are the design patterns and principles we plan to use to address the problem statements outlined in the project requirements:

* Single Responsibility Principle (SRP)
** Controller Responsibility
*** To address the issue of authentication logic residing in <code>ReviewBidsController</code>, we will refactor the code to ensure the controller solely handles request and response flows.
*** Authentication logic will be moved to dedicated methods in <code>AuthorizationHelper</code>, making the codebase easier to maintain and test.
** View Simplification
*** Currently, the <code>review_bids_others_work</code> view contains excessive business logic, violating SRP.
*** We will move this logic into helper methods or models, ensuring each component has a single responsibility and improving code readability.

* Separation of Concerns (SoC)
** By relocating authorization logic out of the controller, we separate authentication from request handling.
** Adhering to SoC enhances readability and maintainability by allowing each part of the application to focus on its specific role.
* Don't Repeat Yourself (DRY)
** We will inspect the existing implementation for code duplication, particularly in the controller actions.
** Any repetitive code will be refactored or removed to reduce redundancy and improve clarity.

* Model-View-Controller (MVC) Adherence
** Moving business logic from the view aligns with MVC best practices.
** By ensuring the view only presents data without processing it, we maintain clear boundaries between the model, view, and controller layers.

* Dependency Inversion Principle (DIP)
** We plan to update class methods to instance methods, allowing the controller to depend on abstractions rather than concrete implementations.
** This change leverages Ruby's duck typing, providing flexibility and making the code easier to maintain and test.

* Factory Pattern
** We will implement a factory pattern for the common processing of <code>ReviewBid</code> and <code>SignUpBid</code>, encapsulating object creation and promoting code reuse.

* Law of Demeter (Principle of Least Knowledge)
** We'll delegate interactions appropriately to prevent tightly coupled code, especially when dealing with topics and teams.
** Clear and intentional naming during refactoring will enhance code clarity and maintainability.

* Adapter Pattern
** To add messaging to bid states for users, we'll use the adapter pattern to allow different components to work together without modifying their existing code.

== Files Modified/Added ==

<span id="vii-1.-controllers"></span>
=== Controllers ===

review_bids_controller.rb

signup_sheet_controller.rb

<span id="vii-2.-models"></span>

=== Models ===

review_bid.rb

<span id="vii-3.-helpers"></span>

=== Helpers ===

authorization_helper.rb

Review_bids_helper.rb

<span id="viii.-test-plan"></span>

== Test Plan ==

The Excel spreadsheet below details our test plan for testing the code we changed or created to ensure code coverage. The process involved reviewing the code and determining all the possible scenarios that needed to be covered based on what the method was doing, then creating test cases accordingly.

[https://docs.google.com/spreadsheets/d/1iHzOdSwlTtxOtf5VsNdwOaCP8NzYMmiJ/edit?usp=drive_link Open Test Matrix Spreadsheet]

== Test Coverage ==

<screenshot of SimpleCov coverage analysis>

<span id="x.-team"></span>

== Team ==

<span id="x-1.-mentor"></span>
=== Mentor ===

* Ed Gehringer

<span id="x-2.-members"></span>
=== Members ===

* Gavin Teague
* Janice Uwujaren

<span id="xi.-links"></span>

== Links ==

Previous Wiki: [https://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review <u>Link</u>]

<span id="xii.-references"></span>

== References ==

[https://docs.google.com/document/d/1LHVacylQmB15I6VcYUA5nuC7GRRU9szHzZhjlPcE-PA/edit?tab=t.0#heading=h.u0oycoj6e0ev <u>Project Instructions</u>]

<span id="appendix-a-uml-class-diagram-plantuml-code-for-review-bids"></span>

CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review

2024-12-05T04:08:41Z

Gwteague: /* Resolve Functionality Issues for Non Bidders */

== Project Overview ==

This project will fix the defects and improve the functionality in Expertiza of the Reviewer Bidding feature, a process where reviewers can bid for assignments they want to review. It will make the functionality smoother, more reliable, and align with Expertiza's collaborative learning objectives.

<span id="iii.-problem-statements"></span>

== Problem Statements ==

Assigning reviews to users on Expertiza involves a complex bidding algorithm that requires optimization before production deployment. Below are key areas we plan to address as per the project requirements:
* Code Refactoring and Best Practices
** '''Utilize Authentication Utilities''': Modify the <code>action_allowed</code> function in the <code>ReviewBidsController</code> to use existing authentication utilities, enhancing code reusability and adhering to the Single Responsibility Principle (SRP) and Separation of Concerns (SoC).
** '''Eliminate Code Duplication''': Refactor <code>review_bids_others_work</code> in the <code>SignUpSheetController</code> to comply with the Don't Repeat Yourself (DRY) principle.
** '''Rename Functions for Clarity''': Change <code>run_bidding_algorithm</code> in <code>ReviewBidsController</code> to <code>assign_reviewers</code> to better reflect its purpose.
** '''Refactor Methods in '''<code>review_bid.rb</code>''':''': Convert class methods to instance methods or relocate them to helper classes for improved code organization.
* Functionality Enhancements
** '''Handle Missing Bids Gracefully''': Adjust the bidding algorithm to accommodate students who do not bid, allowing them to select from the remaining options.
** '''Support Both Individual and Team Assignments''': Ensure the code functions correctly for participant and team-based assignments when signing up for topics.
* User Interface Improvements
** '''Increase Transparency in the Bidding Process''': Display messages indicating how many students are eligible to bid, how many have submitted bids, and the deadline.
** '''Accurate Bid Status Indicators''': Ensure topic colors change correctly based on the number of outstanding bids, providing clear visual feedback to users.
* Testing and Validation
** '''Exhaustive Edge Case Testing''': Conduct thorough testing for edge cases not previously covered, adding additional test cases as needed.

<span id="iv.-design-goals"></span>

== Design Goals ==

While addressing the existing defects and enhancing the Reviewer Bidding feature, we plan to adhere to the following design guidelines:

* Code Quality and Maintainability
** '''Improve Code Structure: '''Implement refactoring strategies to enhance code readability and maintainability, ensuring adherence to best practices like the DRY principle.
** '''Standardize Authentication Logic: '''Utilize a centralized authentication utility to promote consistency and reusability across the application.
* System Stability and Flexibility
** '''Enhance Algorithm Robustness: '''Modify the bidding algorithm to handle scenarios where students do not bid, ensuring the system remains stable under all conditions.
** '''Ensure Assignment Versatility: '''Design the system to seamlessly support both individual and team assignments without additional configuration.
* User Experience Enhancements
** '''Increase Bidding Transparency: '''Develop user interface elements that clearly display bidding status, deadlines, and participation metrics.
** '''Implement Dynamic Visual Feedback: '''Use real-time visual cues, such as color changes, to inform users about the bidding status instantly.
* Testing and Validation
** '''Develop Comprehensive Test Suites: '''Create extensive automated tests covering edge cases and critical functionalities to guarantee reliable system behavior.

<span id="v.-uml-diagram"></span>

== UML Diagram ==

Below is a visual representation of the models associated with the review bids functionality, depicting the data structures and their relationships.

[[File:Uml class diagram2.png|600px]]

<span id="vi.-implementation"></span>
'''ReviewBid: '''The <code>ReviewBid</code> manages the bidding process, where participants indicate their preferences for reviewing different topics or assignments. This helps distribute review tasks fairly based on participants' interests.

'''Assignment: '''The <code>Assignment</code> model represents team or individual assignments in Expertiza. It stores all the essential information required to keep the assignment process organized, like managing participants, setting due dates, forming teams, and overseeing the review process.

'''SignUpTopic: '''The <code>SignUpTopic</code> model identifies specific topics or areas within an assignment for which participants can sign up. It manages the availability of these topics, tracks bids, coordinates team sign-ups, and assigns topics based on both bids and participant availability.

'''Participant: '''The <code>Participant</code> model is about the individual users who participate in an assignment. This includes students, instructors, teaching assistants, or other relevant roles. This model is responsible for managing key user information, monitoring interactions with the assignment, keeping track of team memberships, and recording things like badges and review grades.

== Implementation ==

<span id="vi-1.-decoupling-authorization-logic-from-reviewbidscontroller"></span>
=== Decoupling Authorization Logic from <code>ReviewBidsController</code> ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| '''<code>action_allowed</code> needs to use the authentication utilities'''

The function <code>action_allowed</code> should use the available authentication utilities to support the Single Responsibility Principle and Separation of Concerns and to support code reusability.

| '''Authentication Consistency:''' Remove authentication logic in the controller and call logic in the authentication utility class instead to ensure consistent use of the same logic across the application, foster reusability, and eliminate DRY.

|-
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}
==== Authorization Flow Before Refactoring ====
The sequence diagram depicts the authorization process within the <code>ReviewBidsController</code>. When a user invokes an action, the controller checks if the action is allowed by verifying the user's role through the <code>current_role_name()</code> method in the <code>ApplicationController</code>. Depending on the action and the user's role, the controller either authorizes the user to proceed or denies access, ultimately executing the action logic if authorized and responding to the user.

[[File:Uml sequence 1.png|600px]]

<span id="vi-1-1.-reviewbidscontroller-updates"></span>

==== <code>ReviewBidsController</code> Updates ====

We simplified the <code>action_allowed?</code> method by decoupling authorization logic from the controller to use helper methods in the <code>AuthorizationHelper</code> module. The <code>ReviewBidsController</code> should not handle authentication, which is a violation of SRP.

{| class="wikitable" style="width:100%;"
|-
! style="vertical-align:top;" | Original Code !! style="vertical-align:top;" | Refactored Code
|-
| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index'
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[list].include? action_name) ? are_needed_authorizations_present?(params[:id], "participant", "reader", "submitter", "reviewer") : true)
else
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator'].include? current_role_name
end
end
</syntaxhighlight></div>
|| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index', 'list'
current_user_has_student_privileges? && list_authorization_check
else
current_user_has_ta_privileges?
end
end
</syntaxhighlight></div>
|}

=== Optimize <code>review_bids_others_work</code> Functionality ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| '''<code>review_bids_others_work</code> is a DRY violation'''<br />
The function <code>review_bids_others_work</code> violates DRY.
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}

<span id="vi-2-1.-signupsheetcontroller-updates"></span>
==== <code>SignUpSheetController</code> Updates ====

The ReviewBidsController's index method renders the review_bids_others_work action in <code>SignUpSheetController</code>. However, the <code>SignUpSheetController</code> does not include the controller action for this view. We need to find the old implementation of the controller action, add it back, and review and update it for any DRY violations.

<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# provides variables for reviewing page located at views/review_bids/others_work.html.erb
def index
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)

@assignment = @participant.assignment
@review_mappings = ReviewResponseMap.where(reviewer_id: @participant.id)

# Finding how many reviews have been completed
@num_reviews_completed = 0
@review_mappings.each do |map|
@num_reviews_completed += 1 if !map.response.empty? && map.response.last.is_submitted
end

# render view for completing reviews after review bidding has been completed
render 'sign_up_sheet/review_bids_others_work'
end
end
</syntaxhighlight>

<span id="vi-2-2.-reviewbidsotherswork-view-updates"></span>

==== <code>review_bids_others_work.html.erb</code> View Updates ====

The code only contains a view with this name and no associated controller action. Reviewing the code in the view, we noticed some SRP violations where there is much logic in the presentation layer. Set up helper methods in the controller to handle some of that logic or see if the model can handle some of that logic.

<span id="vi-2-3.-design-patternsprinciples"></span>

=== Rename <code>run_bidding_algorithm</code> method ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| <code>run_bidding_algorithm</code> should be <code>assign_reviewers</code>
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:''' Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

The primary activity here is to refactor the method name <code>run_bidding_algorithm</code> to <code>assign_reviewers</code> and fix the hardcoded URL. However, the match topic bidding algorithm no longer works since Heroku is no longer free, per the professor. The reference link below has detailed information about the web service that we can leverage to gain that understanding.

Reference Link for Webservice Details: [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review <u>match_topics webservice link details</u>]

<span id="vi-3-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to rename the <code>run_bidding_algorithm</code> method to <code>assign_reviewers</code> to make the functionality of the method clear. We also plan to verify that the method is working appropriately by mocking up the service call since it is no longer working.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Other methods

# Call webserver for running the assigning algorithm
# Passing to webserver:
# - student_ids
# - topic_ids
# - student_preferences
# - time_stamps
# Webserver returns:
# - matched assignments as JSON body
def run_bidding_algorithm(bidding_data)
url = 'http://app-csc517.herokuapp.com/match_topics' # Hard coding for the time being
response = RestClient.post url, bidding_data.to_json, content_type: 'application/json', accept: :json
JSON.parse(response.body)
rescue StandardError => e
Rails.logger.error "Bidding algorithm failed: #{e.message}"
false
end
end
</syntaxhighlight>

==== Updated Implementation ====
We implemented an update using mocked data and a service as placeholders until a new URL is in place. We did not end up refactoring to rename this method as we found that the name describes the functionality quite well.

==== review_bids_controller ====
<syntaxhighlight lang="ruby">
def run_bidding_algorithm
review_bid = ReviewBid.new
bidding_data = review_bid.bidding_data
matched_topics = BiddingAlgorithmService.new(bidding_data).run
raise ArgumentError, 'Failed to assign reviewers. Please try again later.' unless matched_topics

matched_topics
end
</syntaxhighlight>

==== bidding_algorithm_service ====

<syntaxhighlight lang="ruby">
# frozen_string_literal: true

# The `BiddingAlgorithmService` run the bid assignment algorithm
# Sends student IDs, topic IDs, student preferences, and timestamps to the web service
# The web service returns the matched assignments in the JSON response body
class BiddingAlgorithmService
SERVICE_URL = 'http://app-csc517.herokuapp.com/match_topics'.freeze

# MOCK_DATA is based on the documentation detailing how the webservice behaves.
# Reference: https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review#Webservice
MOCK_DATA = {
36239 => [3970, 3972, 3975],
36240 => [3973, 3974, 3972],
36241 => [3969, 3971, 3972],
36242 => [3969, 3971, 3973],
36243 => [3969, 3970, 3971]
}.freeze

def initialize(bidding_data)
@bidding_data = bidding_data
end

def run
return MOCK_DATA if Rails.application.config.use_mock_bidding_algorithm

perform_request
rescue RestClient::ExceptionWithResponse, JSON::ParserError
false
end

private

def perform_request
response = RestClient.post(
SERVICE_URL,
@bidding_data.to_json,
content_type: :json,
accept: :json
)

validate_response(response)
JSON.parse(response.body)
end

def validate_response(response)
raise 'Invalid response format' unless response.headers[:content_type] && response.headers[:content_type].include?('application/json')
end
end
</syntaxhighlight>

<span id="vi-3-2.-design-patternsprinciples"></span>

=== Resolve Functionality Issues for Non Bidders ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed to ignore anyone who didn’t bid, and let them choose from what’s left over.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-4-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to do several things within this controller. We will set a default state for non-bidders that we can point to to give them options to select topics to review from the leftovers. We will consolidate <code>@sign_up_topics</code> to resolve the DRY violation. Lastly, we will remove business logic from the show method and push it to a new helper to conform to the SRP.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Additional method

# Provides variables for review bidding page
def show
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment.id, private_to: nil)
my_topic = SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id)
@sign_up_topics -= SignUpTopic.where(assignment_id: @assignment.id, id: my_topic)
@num_participants = AssignmentParticipant.where(parent_id: @assignment.id).count
@selected_topics = nil # This is used to list the topics assigned to review (i.e., select == assigned)
@bids = ReviewBid.where(participant_id: @participant, assignment_id: @assignment.id)
signed_up_topics = []

@bids.each do |bid|
sign_up_topic = SignUpTopic.find_by(id: bid.signuptopic_id)
signed_up_topics << sign_up_topic if sign_up_topic
end

signed_up_topics &= @sign_up_topics
@sign_up_topics -= signed_up_topics
@bids = signed_up_topics
@num_of_topics = @sign_up_topics.size
@assigned_review_maps = []

ReviewResponseMap.where(reviewed_object_id: @assignment.id, reviewer_id: @participant.id).each do |review_map|
@assigned_review_maps << review_map
end

# Explicitly render view since it's in the sign up sheet views
render 'sign_up_sheet/review_bids_show'
end

# Additional methods
end
</syntaxhighlight>

<span id="vi-4-2.-reviewbidshelper-updates"></span>

===== Updated Implementation =====
<syntaxhighlight lang="ruby">
# Assigns bidding topics to reviewers
def assign_bidding
assignment = validate_assignment(params[:assignment_id])

reviewers = validate_reviewers(assignment.id)
reviewer_ids = reviewers.map(&:id)

matched_topics = run_bidding_algorithm

if matched_topics.blank?
flash[:alert] = 'Topic or assignment is missing'
redirect_back fallback_location: root_path && return
end

leftover_topics = find_leftover_topics(assignment.id, matched_topics)
assign_leftover_topics(reviewer_ids, matched_topics, leftover_topics)

ReviewBid.new.assign_review_topics(matched_topics)
assignment.update!(can_choose_topic_to_review: false)

flash[:notice] = 'Reviewers were successfully assigned to topics.'
redirect_back fallback_location: root_path
rescue ArgumentError => e
Rails.logger.error "ArgumentError: #{e.message}"
redirect_back fallback_location: root_path, alert: e.message
rescue ActiveRecord::RecordInvalid => e
Rails.logger.error "ActiveRecord::RecordInvalid: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers due to database error. Please try again later.'
rescue ActiveRecord::ActiveRecordError => e
Rails.logger.error "ActiveRecord::ActiveRecordError: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers due to database error. Please try again later.'
rescue StandardError => e
Rails.logger.error "StandardError: #{e.message}"
redirect_back fallback_location: root_path, alert: 'Failed to assign reviewers. Please try again later.'
end

private

#service methods here ...

def find_leftover_topics(assignment_id, matched_topics)
all_topic_ids = SignUpTopic.where(assignment_id: assignment_id).pluck(:id)
assigned_topic_ids = matched_topics.map { |match| match[:topic_id] }

# Calculate leftover topics
all_topic_ids - assigned_topic_ids
end

def assign_leftover_topics(reviewer_ids, matched_topics, leftover_topics)
return if leftover_topics.blank?

# Find non-bidders by excluding already matched reviewers
non_bidders = reviewer_ids - matched_topics.keys

# Assign leftover topics to non-bidders in a round-robin fashion
non_bidders.each_with_index do |reviewer_id, index|
topic_id = leftover_topics[index % leftover_topics.length]
ReviewBid.create(priority: 1, signuptopic_id: topic_id, participant_id: reviewer_id)
end
end

</syntaxhighlight>
<span id="vi-4-3.-design-patternsprinciples"></span>

=== Confirm Functionality for Single-person Teams ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Make sure your code works on individual assignments, i.e., assignments where participants sign up for topics instead of teams. In this case, a team is created for each participant when they sign up. So the code should work for assignments to which either individuals or teams submit.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to make an update to focus on topic rather than team or have it where teams are updated based on topic id.We will probably utilize sign up topic or a similar object to accomplish this.

<span id="vi-5-2.-design-patternsprinciples"></span>

=== Bid Status Messaging ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| To make the functionality more intuitive, include a message to say how many students are eligible to submit bids, how many have submitted their bids, when the deadline for submitting bids is.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-1"></span>
==== <code>ReviewBidsHelper</code> Updates ====

The logic for these messages will go into the helper file. It is effectively the same reasoning as our migration of other business/functionality code from the controller to the helper to conform to the SRP. It will go hand in hand with the SignUpTopic portion of the code.

<span id="vi-6-2.-design-patternsprinciples"></span>

=== Refactor <code>ReviewBid</code> Model ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-7-1.-reviewbid-model-updates"></span>
==== <code>ReviewBid</code> Model Updates ====
Since the current class methods are tied to <code>ReviewBid</code> model instances, we will change them to instance methods. There is no need to move them to helpers.

===== Review Bid Model Flow Before Refactoring =====
This sequence diagram describes how the <code>ReviewBidsController</code> interacts with the <code>ReviewBid</code> model in assigning review topics to reviewers according to their bids. Once the <code>assign_bidding</code> action is initiated by the user, the controller gathers the IDs of reviewers and calls <code>ReviewBid.bidding_data</code> to gather bidding information. That is sent out to an external bidding algorithm, and the matched topics that come back are used by <code>ReviewBid.assign_review_topics</code> to create <code>ReviewResponseMap</code> entries, assigning topics to reviewers for the assignment.

[[File:Uml sequence 2.png|800px]]

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBid < ApplicationRecord
belongs_to :topic, class_name: 'SignUpTopic'
belongs_to :participant, class_name: 'Participant'
belongs_to :assignment, class_name: 'Assignment'

# method to get bidding data
# returns the bidding data needed for the assigning algorithm
# student_ids, topic_ids, student_preferences, topic_preferences, max reviews allowed

def self.bidding_data(assignment_id, reviewer_ids)
# create basic hash and set basic hash data
bidding_data = { 'tid' => [], 'users' => {}, 'max_accepted_proposals' => [] }
bidding_data['tid'] = SignUpTopic.where(assignment_id: assignment_id).ids
bidding_data['max_accepted_proposals'] = Assignment.where(id: assignment_id).pluck(:num_reviews_allowed).first

# loop through reviewer_ids to get reviewer specific bidding data
reviewer_ids.each do |reviewer_id|
bidding_data['users'][reviewer_id] = reviewer_bidding_data(reviewer_id, assignment_id)
end
bidding_data
end

# assigns topics to reviews as matched by the webservice algorithm
def self.assign_review_topics(assignment_id, reviewer_ids, matched_topics, _min_num_reviews = 2)
# if review response map already created, delete it
if ReviewResponseMap.where(reviewed_object_id: assignment_id)
ReviewResponseMap.where(reviewed_object_id: assignment_id).destroy_all
end
# loop through reviewer_ids to assign reviews to each reviewer
reviewer_ids.each do |reviewer_id|
topics_to_assign = matched_topics[reviewer_id.to_s]
topics_to_assign.each do |topic|
assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
end
end
end

# method to assign a single topic to a reviewer
def self.assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
team_to_review = SignedUpTeam.where(topic_id: topic).pluck(:team_id).first
team_to_review.nil? ? [] : ReviewResponseMap.create(reviewed_object_id: assignment_id, reviewer_id: reviewer_id, reviewee_id: team_to_review, type: 'ReviewResponseMap')
end

# method for getting individual reviewer_ids bidding data
# returns user's bidding data hash
def self.reviewer_bidding_data(reviewer_id, assignment_id)
reviewer_user_id = AssignmentParticipant.find(reviewer_id).user_id
self_topic = SignedUpTeam.topic_id(assignment_id, reviewer_user_id)
bidding_data = { 'tid' => [], 'otid' => self_topic, 'priority' => [], 'time' => [] }
bids = ReviewBid.where(participant_id: reviewer_id)

# loop through each bid for a topic to get specific data
bids.each do |bid|
bidding_data['tid'] << bid.signuptopic_id
bidding_data['priority'] << bid.priority
bidding_data['time'] << bid.updated_at
end
bidding_data
end
end
</syntaxhighlight>

==== <code>ReviewBidsController</code> Updates ====

Once we change them to instance methods, we’ll need to modify their use in the code to instantiate the object first.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-3.-schema.db-updates"></span>

==== <code>Schema.db</code> Updates ====

We also need to remove the foreign key reference to <code>Assignment</code> in the <code>ReviewBid</code> model since the <code>Participant</code> model already has access to <code>Assignment</code>, and that is the <code>Assignment</code> we should be referencing. This will also involve modifying the database to remove the foreign key reference to the <code>Assignment</code>.

Steps required:

# Review the records in the <code>ReviewBid</code> table in the database to see if there are any records and if those records have values for <code>assignment_id</code>
# Create a migration file using the command: <code>rails generate migration RemoveAssignmentFromReviewBids</code>
# In the generated file, indicate the change that needs to be made using the change method and migration columns <code>remove_foreign_key</code> and <code>remove_column</code>. Migration should be straightforward since there is no cascading behavior (i.e., <code>dependent:destroy</code>) to worry about.
# Once comfortable with the updates to the generated file, run the migration using the <code>rails db:migrate</code> command.
# Run a query in the DB to ensure no orphaned records are in the <code>ReviewBid</code> table after the updates.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-4.-design-patternsprinciples"></span>

=== Implement Edge Case Testing ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing - link
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-2"></span>
==== <code>ReviewBidsHelper</code> Updates ====

<span class="mark">TODO</span>:We just got initial test results back. We still need to figure out why tests are failing and what may be slipping through the cracks.[[File:Test expertiza.png|411x459px]]

<span id="vi-8-2.-design-patternsprinciples"></span>

=== Design Patterns and Principles ===
Below are the design patterns and principles we plan to use to address the problem statements outlined in the project requirements:

* Single Responsibility Principle (SRP)
** Controller Responsibility
*** To address the issue of authentication logic residing in <code>ReviewBidsController</code>, we will refactor the code to ensure the controller solely handles request and response flows.
*** Authentication logic will be moved to dedicated methods in <code>AuthorizationHelper</code>, making the codebase easier to maintain and test.
** View Simplification
*** Currently, the <code>review_bids_others_work</code> view contains excessive business logic, violating SRP.
*** We will move this logic into helper methods or models, ensuring each component has a single responsibility and improving code readability.

* Separation of Concerns (SoC)
** By relocating authorization logic out of the controller, we separate authentication from request handling.
** Adhering to SoC enhances readability and maintainability by allowing each part of the application to focus on its specific role.
* Don't Repeat Yourself (DRY)
** We will inspect the existing implementation for code duplication, particularly in the controller actions.
** Any repetitive code will be refactored or removed to reduce redundancy and improve clarity.

* Model-View-Controller (MVC) Adherence
** Moving business logic from the view aligns with MVC best practices.
** By ensuring the view only presents data without processing it, we maintain clear boundaries between the model, view, and controller layers.

* Dependency Inversion Principle (DIP)
** We plan to update class methods to instance methods, allowing the controller to depend on abstractions rather than concrete implementations.
** This change leverages Ruby's duck typing, providing flexibility and making the code easier to maintain and test.

* Factory Pattern
** We will implement a factory pattern for the common processing of <code>ReviewBid</code> and <code>SignUpBid</code>, encapsulating object creation and promoting code reuse.

* Law of Demeter (Principle of Least Knowledge)
** We'll delegate interactions appropriately to prevent tightly coupled code, especially when dealing with topics and teams.
** Clear and intentional naming during refactoring will enhance code clarity and maintainability.

* Adapter Pattern
** To add messaging to bid states for users, we'll use the adapter pattern to allow different components to work together without modifying their existing code.

== Files Modified/Added ==

<span id="vii-1.-controllers"></span>
=== Controllers ===

review_bids_controller.rb

signup_sheet_controller.rb

<span id="vii-2.-models"></span>

=== Models ===

review_bid.rb

<span id="vii-3.-helpers"></span>

=== Helpers ===

authorization_helper.rb

Review_bids_helper.rb

<span id="viii.-test-plan"></span>

== Test Plan ==

The Excel spreadsheet below details our test plan for testing the code we changed or created to ensure code coverage. The process involved reviewing the code and determining all the possible scenarios that needed to be covered based on what the method was doing, then creating test cases accordingly.

[https://docs.google.com/spreadsheets/d/1iHzOdSwlTtxOtf5VsNdwOaCP8NzYMmiJ/edit?usp=drive_link Open Test Matrix Spreadsheet]

== Test Coverage ==

<screenshot of SimpleCov coverage analysis>

<span id="x.-team"></span>

== Team ==

<span id="x-1.-mentor"></span>
=== Mentor ===

* Ed Gehringer

<span id="x-2.-members"></span>
=== Members ===

* Gavin Teague
* Janice Uwujaren

<span id="xi.-links"></span>

== Links ==

Previous Wiki: [https://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review <u>Link</u>]

<span id="xii.-references"></span>

== References ==

[https://docs.google.com/document/d/1LHVacylQmB15I6VcYUA5nuC7GRRU9szHzZhjlPcE-PA/edit?tab=t.0#heading=h.u0oycoj6e0ev <u>Project Instructions</u>]

<span id="appendix-a-uml-class-diagram-plantuml-code-for-review-bids"></span>

CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review

2024-12-05T04:03:55Z

Gwteague: /* Updated Code */

== Project Overview ==

This project will fix the defects and improve the functionality in Expertiza of the Reviewer Bidding feature, a process where reviewers can bid for assignments they want to review. It will make the functionality smoother, more reliable, and align with Expertiza's collaborative learning objectives.

<span id="iii.-problem-statements"></span>

== Problem Statements ==

Assigning reviews to users on Expertiza involves a complex bidding algorithm that requires optimization before production deployment. Below are key areas we plan to address as per the project requirements:
* Code Refactoring and Best Practices
** '''Utilize Authentication Utilities''': Modify the <code>action_allowed</code> function in the <code>ReviewBidsController</code> to use existing authentication utilities, enhancing code reusability and adhering to the Single Responsibility Principle (SRP) and Separation of Concerns (SoC).
** '''Eliminate Code Duplication''': Refactor <code>review_bids_others_work</code> in the <code>SignUpSheetController</code> to comply with the Don't Repeat Yourself (DRY) principle.
** '''Rename Functions for Clarity''': Change <code>run_bidding_algorithm</code> in <code>ReviewBidsController</code> to <code>assign_reviewers</code> to better reflect its purpose.
** '''Refactor Methods in '''<code>review_bid.rb</code>''':''': Convert class methods to instance methods or relocate them to helper classes for improved code organization.
* Functionality Enhancements
** '''Handle Missing Bids Gracefully''': Adjust the bidding algorithm to accommodate students who do not bid, allowing them to select from the remaining options.
** '''Support Both Individual and Team Assignments''': Ensure the code functions correctly for participant and team-based assignments when signing up for topics.
* User Interface Improvements
** '''Increase Transparency in the Bidding Process''': Display messages indicating how many students are eligible to bid, how many have submitted bids, and the deadline.
** '''Accurate Bid Status Indicators''': Ensure topic colors change correctly based on the number of outstanding bids, providing clear visual feedback to users.
* Testing and Validation
** '''Exhaustive Edge Case Testing''': Conduct thorough testing for edge cases not previously covered, adding additional test cases as needed.

<span id="iv.-design-goals"></span>

== Design Goals ==

While addressing the existing defects and enhancing the Reviewer Bidding feature, we plan to adhere to the following design guidelines:

* Code Quality and Maintainability
** '''Improve Code Structure: '''Implement refactoring strategies to enhance code readability and maintainability, ensuring adherence to best practices like the DRY principle.
** '''Standardize Authentication Logic: '''Utilize a centralized authentication utility to promote consistency and reusability across the application.
* System Stability and Flexibility
** '''Enhance Algorithm Robustness: '''Modify the bidding algorithm to handle scenarios where students do not bid, ensuring the system remains stable under all conditions.
** '''Ensure Assignment Versatility: '''Design the system to seamlessly support both individual and team assignments without additional configuration.
* User Experience Enhancements
** '''Increase Bidding Transparency: '''Develop user interface elements that clearly display bidding status, deadlines, and participation metrics.
** '''Implement Dynamic Visual Feedback: '''Use real-time visual cues, such as color changes, to inform users about the bidding status instantly.
* Testing and Validation
** '''Develop Comprehensive Test Suites: '''Create extensive automated tests covering edge cases and critical functionalities to guarantee reliable system behavior.

<span id="v.-uml-diagram"></span>

== UML Diagram ==

Below is a visual representation of the models associated with the review bids functionality, depicting the data structures and their relationships.

[[File:Uml class diagram2.png|600px]]

<span id="vi.-implementation"></span>
'''ReviewBid: '''The <code>ReviewBid</code> manages the bidding process, where participants indicate their preferences for reviewing different topics or assignments. This helps distribute review tasks fairly based on participants' interests.

'''Assignment: '''The <code>Assignment</code> model represents team or individual assignments in Expertiza. It stores all the essential information required to keep the assignment process organized, like managing participants, setting due dates, forming teams, and overseeing the review process.

'''SignUpTopic: '''The <code>SignUpTopic</code> model identifies specific topics or areas within an assignment for which participants can sign up. It manages the availability of these topics, tracks bids, coordinates team sign-ups, and assigns topics based on both bids and participant availability.

'''Participant: '''The <code>Participant</code> model is about the individual users who participate in an assignment. This includes students, instructors, teaching assistants, or other relevant roles. This model is responsible for managing key user information, monitoring interactions with the assignment, keeping track of team memberships, and recording things like badges and review grades.

== Implementation ==

<span id="vi-1.-decoupling-authorization-logic-from-reviewbidscontroller"></span>
=== Decoupling Authorization Logic from <code>ReviewBidsController</code> ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| '''<code>action_allowed</code> needs to use the authentication utilities'''

The function <code>action_allowed</code> should use the available authentication utilities to support the Single Responsibility Principle and Separation of Concerns and to support code reusability.

| '''Authentication Consistency:''' Remove authentication logic in the controller and call logic in the authentication utility class instead to ensure consistent use of the same logic across the application, foster reusability, and eliminate DRY.

|-
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}
==== Authorization Flow Before Refactoring ====
The sequence diagram depicts the authorization process within the <code>ReviewBidsController</code>. When a user invokes an action, the controller checks if the action is allowed by verifying the user's role through the <code>current_role_name()</code> method in the <code>ApplicationController</code>. Depending on the action and the user's role, the controller either authorizes the user to proceed or denies access, ultimately executing the action logic if authorized and responding to the user.

[[File:Uml sequence 1.png|600px]]

<span id="vi-1-1.-reviewbidscontroller-updates"></span>

==== <code>ReviewBidsController</code> Updates ====

We simplified the <code>action_allowed?</code> method by decoupling authorization logic from the controller to use helper methods in the <code>AuthorizationHelper</code> module. The <code>ReviewBidsController</code> should not handle authentication, which is a violation of SRP.

{| class="wikitable" style="width:100%;"
|-
! style="vertical-align:top;" | Original Code !! style="vertical-align:top;" | Refactored Code
|-
| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index'
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[list].include? action_name) ? are_needed_authorizations_present?(params[:id], "participant", "reader", "submitter", "reviewer") : true)
else
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator'].include? current_role_name
end
end
</syntaxhighlight></div>
|| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index', 'list'
current_user_has_student_privileges? && list_authorization_check
else
current_user_has_ta_privileges?
end
end
</syntaxhighlight></div>
|}

=== Optimize <code>review_bids_others_work</code> Functionality ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| '''<code>review_bids_others_work</code> is a DRY violation'''<br />
The function <code>review_bids_others_work</code> violates DRY.
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}

<span id="vi-2-1.-signupsheetcontroller-updates"></span>
==== <code>SignUpSheetController</code> Updates ====

The ReviewBidsController's index method renders the review_bids_others_work action in <code>SignUpSheetController</code>. However, the <code>SignUpSheetController</code> does not include the controller action for this view. We need to find the old implementation of the controller action, add it back, and review and update it for any DRY violations.

<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# provides variables for reviewing page located at views/review_bids/others_work.html.erb
def index
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)

@assignment = @participant.assignment
@review_mappings = ReviewResponseMap.where(reviewer_id: @participant.id)

# Finding how many reviews have been completed
@num_reviews_completed = 0
@review_mappings.each do |map|
@num_reviews_completed += 1 if !map.response.empty? && map.response.last.is_submitted
end

# render view for completing reviews after review bidding has been completed
render 'sign_up_sheet/review_bids_others_work'
end
end
</syntaxhighlight>

<span id="vi-2-2.-reviewbidsotherswork-view-updates"></span>

==== <code>review_bids_others_work.html.erb</code> View Updates ====

The code only contains a view with this name and no associated controller action. Reviewing the code in the view, we noticed some SRP violations where there is much logic in the presentation layer. Set up helper methods in the controller to handle some of that logic or see if the model can handle some of that logic.

<span id="vi-2-3.-design-patternsprinciples"></span>

=== Rename <code>run_bidding_algorithm</code> method ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| <code>run_bidding_algorithm</code> should be <code>assign_reviewers</code>
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:''' Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

The primary activity here is to refactor the method name <code>run_bidding_algorithm</code> to <code>assign_reviewers</code> and fix the hardcoded URL. However, the match topic bidding algorithm no longer works since Heroku is no longer free, per the professor. The reference link below has detailed information about the web service that we can leverage to gain that understanding.

Reference Link for Webservice Details: [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review <u>match_topics webservice link details</u>]

<span id="vi-3-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to rename the <code>run_bidding_algorithm</code> method to <code>assign_reviewers</code> to make the functionality of the method clear. We also plan to verify that the method is working appropriately by mocking up the service call since it is no longer working.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Other methods

# Call webserver for running the assigning algorithm
# Passing to webserver:
# - student_ids
# - topic_ids
# - student_preferences
# - time_stamps
# Webserver returns:
# - matched assignments as JSON body
def run_bidding_algorithm(bidding_data)
url = 'http://app-csc517.herokuapp.com/match_topics' # Hard coding for the time being
response = RestClient.post url, bidding_data.to_json, content_type: 'application/json', accept: :json
JSON.parse(response.body)
rescue StandardError => e
Rails.logger.error "Bidding algorithm failed: #{e.message}"
false
end
end
</syntaxhighlight>

==== Updated Implementation ====
We implemented an update using mocked data and a service as placeholders until a new URL is in place. We did not end up refactoring to rename this method as we found that the name describes the functionality quite well.

==== review_bids_controller ====
<syntaxhighlight lang="ruby">
def run_bidding_algorithm
review_bid = ReviewBid.new
bidding_data = review_bid.bidding_data
matched_topics = BiddingAlgorithmService.new(bidding_data).run
raise ArgumentError, 'Failed to assign reviewers. Please try again later.' unless matched_topics

matched_topics
end
</syntaxhighlight>

==== bidding_algorithm_service ====

<syntaxhighlight lang="ruby">
# frozen_string_literal: true

# The `BiddingAlgorithmService` run the bid assignment algorithm
# Sends student IDs, topic IDs, student preferences, and timestamps to the web service
# The web service returns the matched assignments in the JSON response body
class BiddingAlgorithmService
SERVICE_URL = 'http://app-csc517.herokuapp.com/match_topics'.freeze

# MOCK_DATA is based on the documentation detailing how the webservice behaves.
# Reference: https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review#Webservice
MOCK_DATA = {
36239 => [3970, 3972, 3975],
36240 => [3973, 3974, 3972],
36241 => [3969, 3971, 3972],
36242 => [3969, 3971, 3973],
36243 => [3969, 3970, 3971]
}.freeze

def initialize(bidding_data)
@bidding_data = bidding_data
end

def run
return MOCK_DATA if Rails.application.config.use_mock_bidding_algorithm

perform_request
rescue RestClient::ExceptionWithResponse, JSON::ParserError
false
end

private

def perform_request
response = RestClient.post(
SERVICE_URL,
@bidding_data.to_json,
content_type: :json,
accept: :json
)

validate_response(response)
JSON.parse(response.body)
end

def validate_response(response)
raise 'Invalid response format' unless response.headers[:content_type] && response.headers[:content_type].include?('application/json')
end
end
</syntaxhighlight>

<span id="vi-3-2.-design-patternsprinciples"></span>

=== Resolve Functionality Issues for Non Bidders ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed to ignore anyone who didn’t bid, and let them choose from what’s left over.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-4-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to do several things within this controller. We will set a default state for non-bidders that we can point to to give them options to select topics to review from the leftovers. We will consolidate <code>@sign_up_topics</code> to resolve the DRY violation. Lastly, we will remove business logic from the show method and push it to a new helper to conform to the SRP.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Additional method

# Provides variables for review bidding page
def show
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment.id, private_to: nil)
my_topic = SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id)
@sign_up_topics -= SignUpTopic.where(assignment_id: @assignment.id, id: my_topic)
@num_participants = AssignmentParticipant.where(parent_id: @assignment.id).count
@selected_topics = nil # This is used to list the topics assigned to review (i.e., select == assigned)
@bids = ReviewBid.where(participant_id: @participant, assignment_id: @assignment.id)
signed_up_topics = []

@bids.each do |bid|
sign_up_topic = SignUpTopic.find_by(id: bid.signuptopic_id)
signed_up_topics << sign_up_topic if sign_up_topic
end

signed_up_topics &= @sign_up_topics
@sign_up_topics -= signed_up_topics
@bids = signed_up_topics
@num_of_topics = @sign_up_topics.size
@assigned_review_maps = []

ReviewResponseMap.where(reviewed_object_id: @assignment.id, reviewer_id: @participant.id).each do |review_map|
@assigned_review_maps << review_map
end

# Explicitly render view since it's in the sign up sheet views
render 'sign_up_sheet/review_bids_show'
end

# Additional methods
end
</syntaxhighlight>

<span id="vi-4-2.-reviewbidshelper-updates"></span>

==== <code>ReviewBidsHelper</code> Updates ====

Business logic from the <code>show</code> method in the <code>ReviewBidsController</code> will go here.

<span id="vi-4-3.-design-patternsprinciples"></span>

=== Confirm Functionality for Single-person Teams ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Make sure your code works on individual assignments, i.e., assignments where participants sign up for topics instead of teams. In this case, a team is created for each participant when they sign up. So the code should work for assignments to which either individuals or teams submit.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to make an update to focus on topic rather than team or have it where teams are updated based on topic id.We will probably utilize sign up topic or a similar object to accomplish this.

<span id="vi-5-2.-design-patternsprinciples"></span>

=== Bid Status Messaging ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| To make the functionality more intuitive, include a message to say how many students are eligible to submit bids, how many have submitted their bids, when the deadline for submitting bids is.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-1"></span>
==== <code>ReviewBidsHelper</code> Updates ====

The logic for these messages will go into the helper file. It is effectively the same reasoning as our migration of other business/functionality code from the controller to the helper to conform to the SRP. It will go hand in hand with the SignUpTopic portion of the code.

<span id="vi-6-2.-design-patternsprinciples"></span>

=== Refactor <code>ReviewBid</code> Model ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-7-1.-reviewbid-model-updates"></span>
==== <code>ReviewBid</code> Model Updates ====
Since the current class methods are tied to <code>ReviewBid</code> model instances, we will change them to instance methods. There is no need to move them to helpers.

===== Review Bid Model Flow Before Refactoring =====
This sequence diagram describes how the <code>ReviewBidsController</code> interacts with the <code>ReviewBid</code> model in assigning review topics to reviewers according to their bids. Once the <code>assign_bidding</code> action is initiated by the user, the controller gathers the IDs of reviewers and calls <code>ReviewBid.bidding_data</code> to gather bidding information. That is sent out to an external bidding algorithm, and the matched topics that come back are used by <code>ReviewBid.assign_review_topics</code> to create <code>ReviewResponseMap</code> entries, assigning topics to reviewers for the assignment.

[[File:Uml sequence 2.png|800px]]

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBid < ApplicationRecord
belongs_to :topic, class_name: 'SignUpTopic'
belongs_to :participant, class_name: 'Participant'
belongs_to :assignment, class_name: 'Assignment'

# method to get bidding data
# returns the bidding data needed for the assigning algorithm
# student_ids, topic_ids, student_preferences, topic_preferences, max reviews allowed

def self.bidding_data(assignment_id, reviewer_ids)
# create basic hash and set basic hash data
bidding_data = { 'tid' => [], 'users' => {}, 'max_accepted_proposals' => [] }
bidding_data['tid'] = SignUpTopic.where(assignment_id: assignment_id).ids
bidding_data['max_accepted_proposals'] = Assignment.where(id: assignment_id).pluck(:num_reviews_allowed).first

# loop through reviewer_ids to get reviewer specific bidding data
reviewer_ids.each do |reviewer_id|
bidding_data['users'][reviewer_id] = reviewer_bidding_data(reviewer_id, assignment_id)
end
bidding_data
end

# assigns topics to reviews as matched by the webservice algorithm
def self.assign_review_topics(assignment_id, reviewer_ids, matched_topics, _min_num_reviews = 2)
# if review response map already created, delete it
if ReviewResponseMap.where(reviewed_object_id: assignment_id)
ReviewResponseMap.where(reviewed_object_id: assignment_id).destroy_all
end
# loop through reviewer_ids to assign reviews to each reviewer
reviewer_ids.each do |reviewer_id|
topics_to_assign = matched_topics[reviewer_id.to_s]
topics_to_assign.each do |topic|
assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
end
end
end

# method to assign a single topic to a reviewer
def self.assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
team_to_review = SignedUpTeam.where(topic_id: topic).pluck(:team_id).first
team_to_review.nil? ? [] : ReviewResponseMap.create(reviewed_object_id: assignment_id, reviewer_id: reviewer_id, reviewee_id: team_to_review, type: 'ReviewResponseMap')
end

# method for getting individual reviewer_ids bidding data
# returns user's bidding data hash
def self.reviewer_bidding_data(reviewer_id, assignment_id)
reviewer_user_id = AssignmentParticipant.find(reviewer_id).user_id
self_topic = SignedUpTeam.topic_id(assignment_id, reviewer_user_id)
bidding_data = { 'tid' => [], 'otid' => self_topic, 'priority' => [], 'time' => [] }
bids = ReviewBid.where(participant_id: reviewer_id)

# loop through each bid for a topic to get specific data
bids.each do |bid|
bidding_data['tid'] << bid.signuptopic_id
bidding_data['priority'] << bid.priority
bidding_data['time'] << bid.updated_at
end
bidding_data
end
end
</syntaxhighlight>

==== <code>ReviewBidsController</code> Updates ====

Once we change them to instance methods, we’ll need to modify their use in the code to instantiate the object first.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-3.-schema.db-updates"></span>

==== <code>Schema.db</code> Updates ====

We also need to remove the foreign key reference to <code>Assignment</code> in the <code>ReviewBid</code> model since the <code>Participant</code> model already has access to <code>Assignment</code>, and that is the <code>Assignment</code> we should be referencing. This will also involve modifying the database to remove the foreign key reference to the <code>Assignment</code>.

Steps required:

# Review the records in the <code>ReviewBid</code> table in the database to see if there are any records and if those records have values for <code>assignment_id</code>
# Create a migration file using the command: <code>rails generate migration RemoveAssignmentFromReviewBids</code>
# In the generated file, indicate the change that needs to be made using the change method and migration columns <code>remove_foreign_key</code> and <code>remove_column</code>. Migration should be straightforward since there is no cascading behavior (i.e., <code>dependent:destroy</code>) to worry about.
# Once comfortable with the updates to the generated file, run the migration using the <code>rails db:migrate</code> command.
# Run a query in the DB to ensure no orphaned records are in the <code>ReviewBid</code> table after the updates.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-4.-design-patternsprinciples"></span>

=== Implement Edge Case Testing ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing - link
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-2"></span>
==== <code>ReviewBidsHelper</code> Updates ====

<span class="mark">TODO</span>:We just got initial test results back. We still need to figure out why tests are failing and what may be slipping through the cracks.[[File:Test expertiza.png|411x459px]]

<span id="vi-8-2.-design-patternsprinciples"></span>

=== Design Patterns and Principles ===
Below are the design patterns and principles we plan to use to address the problem statements outlined in the project requirements:

* Single Responsibility Principle (SRP)
** Controller Responsibility
*** To address the issue of authentication logic residing in <code>ReviewBidsController</code>, we will refactor the code to ensure the controller solely handles request and response flows.
*** Authentication logic will be moved to dedicated methods in <code>AuthorizationHelper</code>, making the codebase easier to maintain and test.
** View Simplification
*** Currently, the <code>review_bids_others_work</code> view contains excessive business logic, violating SRP.
*** We will move this logic into helper methods or models, ensuring each component has a single responsibility and improving code readability.

* Separation of Concerns (SoC)
** By relocating authorization logic out of the controller, we separate authentication from request handling.
** Adhering to SoC enhances readability and maintainability by allowing each part of the application to focus on its specific role.
* Don't Repeat Yourself (DRY)
** We will inspect the existing implementation for code duplication, particularly in the controller actions.
** Any repetitive code will be refactored or removed to reduce redundancy and improve clarity.

* Model-View-Controller (MVC) Adherence
** Moving business logic from the view aligns with MVC best practices.
** By ensuring the view only presents data without processing it, we maintain clear boundaries between the model, view, and controller layers.

* Dependency Inversion Principle (DIP)
** We plan to update class methods to instance methods, allowing the controller to depend on abstractions rather than concrete implementations.
** This change leverages Ruby's duck typing, providing flexibility and making the code easier to maintain and test.

* Factory Pattern
** We will implement a factory pattern for the common processing of <code>ReviewBid</code> and <code>SignUpBid</code>, encapsulating object creation and promoting code reuse.

* Law of Demeter (Principle of Least Knowledge)
** We'll delegate interactions appropriately to prevent tightly coupled code, especially when dealing with topics and teams.
** Clear and intentional naming during refactoring will enhance code clarity and maintainability.

* Adapter Pattern
** To add messaging to bid states for users, we'll use the adapter pattern to allow different components to work together without modifying their existing code.

== Files Modified/Added ==

<span id="vii-1.-controllers"></span>
=== Controllers ===

review_bids_controller.rb

signup_sheet_controller.rb

<span id="vii-2.-models"></span>

=== Models ===

review_bid.rb

<span id="vii-3.-helpers"></span>

=== Helpers ===

authorization_helper.rb

Review_bids_helper.rb

<span id="viii.-test-plan"></span>

== Test Plan ==

The Excel spreadsheet below details our test plan for testing the code we changed or created to ensure code coverage. The process involved reviewing the code and determining all the possible scenarios that needed to be covered based on what the method was doing, then creating test cases accordingly.

[https://docs.google.com/spreadsheets/d/1iHzOdSwlTtxOtf5VsNdwOaCP8NzYMmiJ/edit?usp=drive_link Open Test Matrix Spreadsheet]

== Test Coverage ==

<screenshot of SimpleCov coverage analysis>

<span id="x.-team"></span>

== Team ==

<span id="x-1.-mentor"></span>
=== Mentor ===

* Ed Gehringer

<span id="x-2.-members"></span>
=== Members ===

* Gavin Teague
* Janice Uwujaren

<span id="xi.-links"></span>

== Links ==

Previous Wiki: [https://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review <u>Link</u>]

<span id="xii.-references"></span>

== References ==

[https://docs.google.com/document/d/1LHVacylQmB15I6VcYUA5nuC7GRRU9szHzZhjlPcE-PA/edit?tab=t.0#heading=h.u0oycoj6e0ev <u>Project Instructions</u>]

<span id="appendix-a-uml-class-diagram-plantuml-code-for-review-bids"></span>

CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review

2024-12-05T04:03:09Z

Gwteague: /* Rename run_bidding_algorithm method */

== Project Overview ==

This project will fix the defects and improve the functionality in Expertiza of the Reviewer Bidding feature, a process where reviewers can bid for assignments they want to review. It will make the functionality smoother, more reliable, and align with Expertiza's collaborative learning objectives.

<span id="iii.-problem-statements"></span>

== Problem Statements ==

Assigning reviews to users on Expertiza involves a complex bidding algorithm that requires optimization before production deployment. Below are key areas we plan to address as per the project requirements:
* Code Refactoring and Best Practices
** '''Utilize Authentication Utilities''': Modify the <code>action_allowed</code> function in the <code>ReviewBidsController</code> to use existing authentication utilities, enhancing code reusability and adhering to the Single Responsibility Principle (SRP) and Separation of Concerns (SoC).
** '''Eliminate Code Duplication''': Refactor <code>review_bids_others_work</code> in the <code>SignUpSheetController</code> to comply with the Don't Repeat Yourself (DRY) principle.
** '''Rename Functions for Clarity''': Change <code>run_bidding_algorithm</code> in <code>ReviewBidsController</code> to <code>assign_reviewers</code> to better reflect its purpose.
** '''Refactor Methods in '''<code>review_bid.rb</code>''':''': Convert class methods to instance methods or relocate them to helper classes for improved code organization.
* Functionality Enhancements
** '''Handle Missing Bids Gracefully''': Adjust the bidding algorithm to accommodate students who do not bid, allowing them to select from the remaining options.
** '''Support Both Individual and Team Assignments''': Ensure the code functions correctly for participant and team-based assignments when signing up for topics.
* User Interface Improvements
** '''Increase Transparency in the Bidding Process''': Display messages indicating how many students are eligible to bid, how many have submitted bids, and the deadline.
** '''Accurate Bid Status Indicators''': Ensure topic colors change correctly based on the number of outstanding bids, providing clear visual feedback to users.
* Testing and Validation
** '''Exhaustive Edge Case Testing''': Conduct thorough testing for edge cases not previously covered, adding additional test cases as needed.

<span id="iv.-design-goals"></span>

== Design Goals ==

While addressing the existing defects and enhancing the Reviewer Bidding feature, we plan to adhere to the following design guidelines:

* Code Quality and Maintainability
** '''Improve Code Structure: '''Implement refactoring strategies to enhance code readability and maintainability, ensuring adherence to best practices like the DRY principle.
** '''Standardize Authentication Logic: '''Utilize a centralized authentication utility to promote consistency and reusability across the application.
* System Stability and Flexibility
** '''Enhance Algorithm Robustness: '''Modify the bidding algorithm to handle scenarios where students do not bid, ensuring the system remains stable under all conditions.
** '''Ensure Assignment Versatility: '''Design the system to seamlessly support both individual and team assignments without additional configuration.
* User Experience Enhancements
** '''Increase Bidding Transparency: '''Develop user interface elements that clearly display bidding status, deadlines, and participation metrics.
** '''Implement Dynamic Visual Feedback: '''Use real-time visual cues, such as color changes, to inform users about the bidding status instantly.
* Testing and Validation
** '''Develop Comprehensive Test Suites: '''Create extensive automated tests covering edge cases and critical functionalities to guarantee reliable system behavior.

<span id="v.-uml-diagram"></span>

== UML Diagram ==

Below is a visual representation of the models associated with the review bids functionality, depicting the data structures and their relationships.

[[File:Uml class diagram2.png|600px]]

<span id="vi.-implementation"></span>
'''ReviewBid: '''The <code>ReviewBid</code> manages the bidding process, where participants indicate their preferences for reviewing different topics or assignments. This helps distribute review tasks fairly based on participants' interests.

'''Assignment: '''The <code>Assignment</code> model represents team or individual assignments in Expertiza. It stores all the essential information required to keep the assignment process organized, like managing participants, setting due dates, forming teams, and overseeing the review process.

'''SignUpTopic: '''The <code>SignUpTopic</code> model identifies specific topics or areas within an assignment for which participants can sign up. It manages the availability of these topics, tracks bids, coordinates team sign-ups, and assigns topics based on both bids and participant availability.

'''Participant: '''The <code>Participant</code> model is about the individual users who participate in an assignment. This includes students, instructors, teaching assistants, or other relevant roles. This model is responsible for managing key user information, monitoring interactions with the assignment, keeping track of team memberships, and recording things like badges and review grades.

== Implementation ==

<span id="vi-1.-decoupling-authorization-logic-from-reviewbidscontroller"></span>
=== Decoupling Authorization Logic from <code>ReviewBidsController</code> ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| '''<code>action_allowed</code> needs to use the authentication utilities'''

The function <code>action_allowed</code> should use the available authentication utilities to support the Single Responsibility Principle and Separation of Concerns and to support code reusability.

| '''Authentication Consistency:''' Remove authentication logic in the controller and call logic in the authentication utility class instead to ensure consistent use of the same logic across the application, foster reusability, and eliminate DRY.

|-
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}
==== Authorization Flow Before Refactoring ====
The sequence diagram depicts the authorization process within the <code>ReviewBidsController</code>. When a user invokes an action, the controller checks if the action is allowed by verifying the user's role through the <code>current_role_name()</code> method in the <code>ApplicationController</code>. Depending on the action and the user's role, the controller either authorizes the user to proceed or denies access, ultimately executing the action logic if authorized and responding to the user.

[[File:Uml sequence 1.png|600px]]

<span id="vi-1-1.-reviewbidscontroller-updates"></span>

==== <code>ReviewBidsController</code> Updates ====

We simplified the <code>action_allowed?</code> method by decoupling authorization logic from the controller to use helper methods in the <code>AuthorizationHelper</code> module. The <code>ReviewBidsController</code> should not handle authentication, which is a violation of SRP.

{| class="wikitable" style="width:100%;"
|-
! style="vertical-align:top;" | Original Code !! style="vertical-align:top;" | Refactored Code
|-
| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index'
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[list].include? action_name) ? are_needed_authorizations_present?(params[:id], "participant", "reader", "submitter", "reviewer") : true)
else
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator'].include? current_role_name
end
end
</syntaxhighlight></div>
|| <div style="vertical-align:top;"><syntaxhighlight lang="ruby">
def action_allowed?
case params[:action]
when 'show', 'set_priority', 'index', 'list'
current_user_has_student_privileges? && list_authorization_check
else
current_user_has_ta_privileges?
end
end
</syntaxhighlight></div>
|}

=== Optimize <code>review_bids_others_work</code> Functionality ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| '''<code>review_bids_others_work</code> is a DRY violation'''<br />
The function <code>review_bids_others_work</code> violates DRY.
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|}

<span id="vi-2-1.-signupsheetcontroller-updates"></span>
==== <code>SignUpSheetController</code> Updates ====

The ReviewBidsController's index method renders the review_bids_others_work action in <code>SignUpSheetController</code>. However, the <code>SignUpSheetController</code> does not include the controller action for this view. We need to find the old implementation of the controller action, add it back, and review and update it for any DRY violations.

<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# provides variables for reviewing page located at views/review_bids/others_work.html.erb
def index
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)

@assignment = @participant.assignment
@review_mappings = ReviewResponseMap.where(reviewer_id: @participant.id)

# Finding how many reviews have been completed
@num_reviews_completed = 0
@review_mappings.each do |map|
@num_reviews_completed += 1 if !map.response.empty? && map.response.last.is_submitted
end

# render view for completing reviews after review bidding has been completed
render 'sign_up_sheet/review_bids_others_work'
end
end
</syntaxhighlight>

<span id="vi-2-2.-reviewbidsotherswork-view-updates"></span>

==== <code>review_bids_others_work.html.erb</code> View Updates ====

The code only contains a view with this name and no associated controller action. Reviewing the code in the view, we noticed some SRP violations where there is much logic in the presentation layer. Set up helper methods in the controller to handle some of that logic or see if the model can handle some of that logic.

<span id="vi-2-3.-design-patternsprinciples"></span>

=== Rename <code>run_bidding_algorithm</code> method ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| <code>run_bidding_algorithm</code> should be <code>assign_reviewers</code>
| '''Code Readability and Maintainability:''' Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:''' Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

The primary activity here is to refactor the method name <code>run_bidding_algorithm</code> to <code>assign_reviewers</code> and fix the hardcoded URL. However, the match topic bidding algorithm no longer works since Heroku is no longer free, per the professor. The reference link below has detailed information about the web service that we can leverage to gain that understanding.

Reference Link for Webservice Details: [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review <u>match_topics webservice link details</u>]

<span id="vi-3-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to rename the <code>run_bidding_algorithm</code> method to <code>assign_reviewers</code> to make the functionality of the method clear. We also plan to verify that the method is working appropriately by mocking up the service call since it is no longer working.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Other methods

# Call webserver for running the assigning algorithm
# Passing to webserver:
# - student_ids
# - topic_ids
# - student_preferences
# - time_stamps
# Webserver returns:
# - matched assignments as JSON body
def run_bidding_algorithm(bidding_data)
url = 'http://app-csc517.herokuapp.com/match_topics' # Hard coding for the time being
response = RestClient.post url, bidding_data.to_json, content_type: 'application/json', accept: :json
JSON.parse(response.body)
rescue StandardError => e
Rails.logger.error "Bidding algorithm failed: #{e.message}"
false
end
end
</syntaxhighlight>

==== Updated Code ====
We implemented an update using mocked data and a service as placeholders until a new URL is in place. We did not end up refactoring to rename this method as we found that the name describes the functionality quite well.

==== review_bids_controller ====
<syntaxhighlight lang="ruby">
def run_bidding_algorithm
review_bid = ReviewBid.new
bidding_data = review_bid.bidding_data
matched_topics = BiddingAlgorithmService.new(bidding_data).run
raise ArgumentError, 'Failed to assign reviewers. Please try again later.' unless matched_topics

matched_topics
end
</syntaxhighlight>

==== bidding_algorithm_service ====

<syntaxhighlight lang="ruby">
# frozen_string_literal: true

# The `BiddingAlgorithmService` run the bid assignment algorithm
# Sends student IDs, topic IDs, student preferences, and timestamps to the web service
# The web service returns the matched assignments in the JSON response body
class BiddingAlgorithmService
SERVICE_URL = 'http://app-csc517.herokuapp.com/match_topics'.freeze

# MOCK_DATA is based on the documentation detailing how the webservice behaves.
# Reference: https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2020_-_E2085._Allow_reviewers_to_bid_on_what_to_review#Webservice
MOCK_DATA = {
36239 => [3970, 3972, 3975],
36240 => [3973, 3974, 3972],
36241 => [3969, 3971, 3972],
36242 => [3969, 3971, 3973],
36243 => [3969, 3970, 3971]
}.freeze

def initialize(bidding_data)
@bidding_data = bidding_data
end

def run
return MOCK_DATA if Rails.application.config.use_mock_bidding_algorithm

perform_request
rescue RestClient::ExceptionWithResponse, JSON::ParserError
false
end

private

def perform_request
response = RestClient.post(
SERVICE_URL,
@bidding_data.to_json,
content_type: :json,
accept: :json
)

validate_response(response)
JSON.parse(response.body)
end

def validate_response(response)
raise 'Invalid response format' unless response.headers[:content_type] && response.headers[:content_type].include?('application/json')
end
end
</syntaxhighlight>

<span id="vi-3-2.-design-patternsprinciples"></span>

=== Resolve Functionality Issues for Non Bidders ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed to ignore anyone who didn’t bid, and let them choose from what’s left over.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-4-1.-reviewbidscontroller-updates"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to do several things within this controller. We will set a default state for non-bidders that we can point to to give them options to select topics to review from the leftovers. We will consolidate <code>@sign_up_topics</code> to resolve the DRY violation. Lastly, we will remove business logic from the show method and push it to a new helper to conform to the SRP.

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBidsController < ApplicationController
require 'json'
require 'uri'
require 'net/http'
require 'rest_client'

# Additional method

# Provides variables for review bidding page
def show
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment.id, private_to: nil)
my_topic = SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id)
@sign_up_topics -= SignUpTopic.where(assignment_id: @assignment.id, id: my_topic)
@num_participants = AssignmentParticipant.where(parent_id: @assignment.id).count
@selected_topics = nil # This is used to list the topics assigned to review (i.e., select == assigned)
@bids = ReviewBid.where(participant_id: @participant, assignment_id: @assignment.id)
signed_up_topics = []

@bids.each do |bid|
sign_up_topic = SignUpTopic.find_by(id: bid.signuptopic_id)
signed_up_topics << sign_up_topic if sign_up_topic
end

signed_up_topics &= @sign_up_topics
@sign_up_topics -= signed_up_topics
@bids = signed_up_topics
@num_of_topics = @sign_up_topics.size
@assigned_review_maps = []

ReviewResponseMap.where(reviewed_object_id: @assignment.id, reviewer_id: @participant.id).each do |review_map|
@assigned_review_maps << review_map
end

# Explicitly render view since it's in the sign up sheet views
render 'sign_up_sheet/review_bids_show'
end

# Additional methods
end
</syntaxhighlight>

<span id="vi-4-2.-reviewbidshelper-updates"></span>

==== <code>ReviewBidsHelper</code> Updates ====

Business logic from the <code>show</code> method in the <code>ReviewBidsController</code> will go here.

<span id="vi-4-3.-design-patternsprinciples"></span>

=== Confirm Functionality for Single-person Teams ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Make sure your code works on individual assignments, i.e., assignments where participants sign up for topics instead of teams. In this case, a team is created for each participant when they sign up. So the code should work for assignments to which either individuals or teams submit.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section"></span>
==== <code>ReviewBidsController</code> Updates ====

We plan to make an update to focus on topic rather than team or have it where teams are updated based on topic id.We will probably utilize sign up topic or a similar object to accomplish this.

<span id="vi-5-2.-design-patternsprinciples"></span>

=== Bid Status Messaging ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| To make the functionality more intuitive, include a message to say how many students are eligible to submit bids, how many have submitted their bids, when the deadline for submitting bids is.
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-1"></span>
==== <code>ReviewBidsHelper</code> Updates ====

The logic for these messages will go into the helper file. It is effectively the same reasoning as our migration of other business/functionality code from the controller to the helper to conform to the SRP. It will go hand in hand with the SignUpTopic portion of the code.

<span id="vi-6-2.-design-patternsprinciples"></span>

=== Refactor <code>ReviewBid</code> Model ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="vi-7-1.-reviewbid-model-updates"></span>
==== <code>ReviewBid</code> Model Updates ====
Since the current class methods are tied to <code>ReviewBid</code> model instances, we will change them to instance methods. There is no need to move them to helpers.

===== Review Bid Model Flow Before Refactoring =====
This sequence diagram describes how the <code>ReviewBidsController</code> interacts with the <code>ReviewBid</code> model in assigning review topics to reviewers according to their bids. Once the <code>assign_bidding</code> action is initiated by the user, the controller gathers the IDs of reviewers and calls <code>ReviewBid.bidding_data</code> to gather bidding information. That is sent out to an external bidding algorithm, and the matched topics that come back are used by <code>ReviewBid.assign_review_topics</code> to create <code>ReviewResponseMap</code> entries, assigning topics to reviewers for the assignment.

[[File:Uml sequence 2.png|800px]]

===== Current Implementation =====
<syntaxhighlight lang="ruby">
class ReviewBid < ApplicationRecord
belongs_to :topic, class_name: 'SignUpTopic'
belongs_to :participant, class_name: 'Participant'
belongs_to :assignment, class_name: 'Assignment'

# method to get bidding data
# returns the bidding data needed for the assigning algorithm
# student_ids, topic_ids, student_preferences, topic_preferences, max reviews allowed

def self.bidding_data(assignment_id, reviewer_ids)
# create basic hash and set basic hash data
bidding_data = { 'tid' => [], 'users' => {}, 'max_accepted_proposals' => [] }
bidding_data['tid'] = SignUpTopic.where(assignment_id: assignment_id).ids
bidding_data['max_accepted_proposals'] = Assignment.where(id: assignment_id).pluck(:num_reviews_allowed).first

# loop through reviewer_ids to get reviewer specific bidding data
reviewer_ids.each do |reviewer_id|
bidding_data['users'][reviewer_id] = reviewer_bidding_data(reviewer_id, assignment_id)
end
bidding_data
end

# assigns topics to reviews as matched by the webservice algorithm
def self.assign_review_topics(assignment_id, reviewer_ids, matched_topics, _min_num_reviews = 2)
# if review response map already created, delete it
if ReviewResponseMap.where(reviewed_object_id: assignment_id)
ReviewResponseMap.where(reviewed_object_id: assignment_id).destroy_all
end
# loop through reviewer_ids to assign reviews to each reviewer
reviewer_ids.each do |reviewer_id|
topics_to_assign = matched_topics[reviewer_id.to_s]
topics_to_assign.each do |topic|
assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
end
end
end

# method to assign a single topic to a reviewer
def self.assign_topic_to_reviewer(assignment_id, reviewer_id, topic)
team_to_review = SignedUpTeam.where(topic_id: topic).pluck(:team_id).first
team_to_review.nil? ? [] : ReviewResponseMap.create(reviewed_object_id: assignment_id, reviewer_id: reviewer_id, reviewee_id: team_to_review, type: 'ReviewResponseMap')
end

# method for getting individual reviewer_ids bidding data
# returns user's bidding data hash
def self.reviewer_bidding_data(reviewer_id, assignment_id)
reviewer_user_id = AssignmentParticipant.find(reviewer_id).user_id
self_topic = SignedUpTeam.topic_id(assignment_id, reviewer_user_id)
bidding_data = { 'tid' => [], 'otid' => self_topic, 'priority' => [], 'time' => [] }
bids = ReviewBid.where(participant_id: reviewer_id)

# loop through each bid for a topic to get specific data
bids.each do |bid|
bidding_data['tid'] << bid.signuptopic_id
bidding_data['priority'] << bid.priority
bidding_data['time'] << bid.updated_at
end
bidding_data
end
end
</syntaxhighlight>

==== <code>ReviewBidsController</code> Updates ====

Once we change them to instance methods, we’ll need to modify their use in the code to instantiate the object first.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-3.-schema.db-updates"></span>

==== <code>Schema.db</code> Updates ====

We also need to remove the foreign key reference to <code>Assignment</code> in the <code>ReviewBid</code> model since the <code>Participant</code> model already has access to <code>Assignment</code>, and that is the <code>Assignment</code> we should be referencing. This will also involve modifying the database to remove the foreign key reference to the <code>Assignment</code>.

Steps required:

# Review the records in the <code>ReviewBid</code> table in the database to see if there are any records and if those records have values for <code>assignment_id</code>
# Create a migration file using the command: <code>rails generate migration RemoveAssignmentFromReviewBids</code>
# In the generated file, indicate the change that needs to be made using the change method and migration columns <code>remove_foreign_key</code> and <code>remove_column</code>. Migration should be straightforward since there is no cascading behavior (i.e., <code>dependent:destroy</code>) to worry about.
# Once comfortable with the updates to the generated file, run the migration using the <code>rails db:migrate</code> command.
# Run a query in the DB to ensure no orphaned records are in the <code>ReviewBid</code> table after the updates.

<Placeholder for implementation screenshots (before and after)>

<span id="vi-7-4.-design-patternsprinciples"></span>

=== Implement Edge Case Testing ===

{| class="wikitable"
|-
! Problem
! Design Goals
|-
| rowspan="2"| In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing - link
| '''Code Readability and Maintainability:'''

Refactor and simplify code, especially in places where the code violates the DRY principle, to reduce complexity and make the code base more straightforward to understand and maintain.

|-
| '''System Stability:'''

Debug the existing bidding algorithm and fine-tune the assignment logic. Also, the existing functionality related to the reviewer bidding feature should work and be enhanced if required so that it does not fail in circumstances such as when a student does not bid.

|}

<span id="section-2"></span>
==== <code>ReviewBidsHelper</code> Updates ====

<span class="mark">TODO</span>:We just got initial test results back. We still need to figure out why tests are failing and what may be slipping through the cracks.[[File:Test expertiza.png|411x459px]]

<span id="vi-8-2.-design-patternsprinciples"></span>

=== Design Patterns and Principles ===
Below are the design patterns and principles we plan to use to address the problem statements outlined in the project requirements:

* Single Responsibility Principle (SRP)
** Controller Responsibility
*** To address the issue of authentication logic residing in <code>ReviewBidsController</code>, we will refactor the code to ensure the controller solely handles request and response flows.
*** Authentication logic will be moved to dedicated methods in <code>AuthorizationHelper</code>, making the codebase easier to maintain and test.
** View Simplification
*** Currently, the <code>review_bids_others_work</code> view contains excessive business logic, violating SRP.
*** We will move this logic into helper methods or models, ensuring each component has a single responsibility and improving code readability.

* Separation of Concerns (SoC)
** By relocating authorization logic out of the controller, we separate authentication from request handling.
** Adhering to SoC enhances readability and maintainability by allowing each part of the application to focus on its specific role.
* Don't Repeat Yourself (DRY)
** We will inspect the existing implementation for code duplication, particularly in the controller actions.
** Any repetitive code will be refactored or removed to reduce redundancy and improve clarity.

* Model-View-Controller (MVC) Adherence
** Moving business logic from the view aligns with MVC best practices.
** By ensuring the view only presents data without processing it, we maintain clear boundaries between the model, view, and controller layers.

* Dependency Inversion Principle (DIP)
** We plan to update class methods to instance methods, allowing the controller to depend on abstractions rather than concrete implementations.
** This change leverages Ruby's duck typing, providing flexibility and making the code easier to maintain and test.

* Factory Pattern
** We will implement a factory pattern for the common processing of <code>ReviewBid</code> and <code>SignUpBid</code>, encapsulating object creation and promoting code reuse.

* Law of Demeter (Principle of Least Knowledge)
** We'll delegate interactions appropriately to prevent tightly coupled code, especially when dealing with topics and teams.
** Clear and intentional naming during refactoring will enhance code clarity and maintainability.

* Adapter Pattern
** To add messaging to bid states for users, we'll use the adapter pattern to allow different components to work together without modifying their existing code.

== Files Modified/Added ==

<span id="vii-1.-controllers"></span>
=== Controllers ===

review_bids_controller.rb

signup_sheet_controller.rb

<span id="vii-2.-models"></span>

=== Models ===

review_bid.rb

<span id="vii-3.-helpers"></span>

=== Helpers ===

authorization_helper.rb

Review_bids_helper.rb

<span id="viii.-test-plan"></span>

== Test Plan ==

The Excel spreadsheet below details our test plan for testing the code we changed or created to ensure code coverage. The process involved reviewing the code and determining all the possible scenarios that needed to be covered based on what the method was doing, then creating test cases accordingly.

[https://docs.google.com/spreadsheets/d/1iHzOdSwlTtxOtf5VsNdwOaCP8NzYMmiJ/edit?usp=drive_link Open Test Matrix Spreadsheet]

== Test Coverage ==

<screenshot of SimpleCov coverage analysis>

<span id="x.-team"></span>

== Team ==

<span id="x-1.-mentor"></span>
=== Mentor ===

* Ed Gehringer

<span id="x-2.-members"></span>
=== Members ===

* Gavin Teague
* Janice Uwujaren

<span id="xi.-links"></span>

== Links ==

Previous Wiki: [https://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review <u>Link</u>]

<span id="xii.-references"></span>

== References ==

[https://docs.google.com/document/d/1LHVacylQmB15I6VcYUA5nuC7GRRU9szHzZhjlPcE-PA/edit?tab=t.0#heading=h.u0oycoj6e0ev <u>Project Instructions</u>]

<span id="appendix-a-uml-class-diagram-plantuml-code-for-review-bids"></span>

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:51:06Z

Gwteague: /* Relevant Links */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T04:41:48Z

Gwteague: /* Code Changes in Test */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T04:40:59Z

Gwteague: updated with test changes

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Test auto assign mentor.png

2024-10-29T04:27:10Z

Gwteague:

File:Meeting date factory.png

2024-10-29T03:53:34Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T02:50:36Z

Gwteague: /* _team.html.erb */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Capacity and +.png

2024-10-29T02:49:58Z

Gwteague: Gwteague uploaded a new version of File:Capacity and +.png

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T02:45:39Z

Gwteague: /* _team.html.erb */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+ Add Meeting" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Meeting date functionality.png

2024-10-29T02:41:11Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T02:35:08Z

Gwteague: added in controller changes

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T01:58:24Z

Gwteague: added refactored code

File:Previous group - refactored.png

2024-10-29T01:56:02Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T01:52:00Z

Gwteague: /* Code Changes in Views */

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T01:43:19Z

Gwteague: added image and reformatted to keep rest of wiki looking orderly

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T01:36:55Z

Gwteague: /* Mentor Meeting Management */

File:Capacity and +.png

2024-10-29T01:24:53Z

Gwteague: Gwteague uploaded a new version of File:Capacity and +.png

File:Meeting parameters.png

2024-10-29T01:18:39Z

Gwteague:

File:Capacity and +.png

2024-10-29T01:16:09Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T00:39:25Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T00:36:38Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T00:34:14Z

Gwteague:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T00:33:14Z

Gwteague: some reformatting

= CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management =

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
- understand and reimplement previous team's code (or improve upon it)

=== Mentor Meeting Management ===
- Create a view showing teams, members, and mentors, with meeting date fields.
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
- Instructors can edit all dates for mentor meetings regardless of the team.
- Mentors can also edit dates but only for the team they are mentoring.
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
- The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
- Implement a new controller to handle CRUD operations for mentor meetings
- Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
Github Repository: https://github.com/ExtremeMachine12/expertiza
Pull Request: https://github.com/expertiza/expertiza/pull/2769
Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team Mentor ==
Nainisha Bhallamudi

== Team Members ==
Anusha Akkireddy (aakkire)
Simon Getahun (sgetahu)
Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T00:26:10Z

Gwteague: Backbone for E2460 - sligtly modified problem statement and included deliverables for scope. Now we each just need to fill in our sections.

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

Contents
1 Background
2 What is a Mentor?
3 Problem Statement
4 Tasks
4.1 Email Notifications
4.2 Mentor Meeting Management
5 Implementation
5.1 Email Notifications
5.1.1 add_member
5.1.2 New Code in add_member
5.1.3 send_team_confirmation_mail_to_user
5.1.4 Modified generic_message
5.1.5 Student HTML Partial
5.1.6 Mentor HTML Partial
5.2 Mentor Meeting Management
5.2.1 New Mentor Meeting Management View
5.2.2 Code changes in the views
5.2.3 Code changes in the controller
5.2.4 Helper code
6 Relevant Links
7 Team
7.1 Mentor
7.2 Team Members

Background
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

What is a Mentor?
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

Problem Statement
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

Tasks
Email Notifications
- understand and reimplement previous team's code (or improve upon it)

Mentor Meeting Management
- Create a view showing teams, members, and mentors, with meeting date fields.
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
- Instructors can edit all dates for mentor meetings regardless of the team.
- Mentors can also edit dates but only for the team they are mentoring.
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
- The meeting dates should not be editable for teams having capacity less than 50%.

Backend Controller Updates
- Implement a new controller to handle CRUD operations for mentor meetings
- Update models to manage mentor meetings and trigger notifications.

Implementation
Email Notifications

Mentor Meeting Management

Backend Controller Updates

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

Relevant Links
Github Repository: https://github.com/ExtremeMachine12/expertiza
Pull Request: https://github.com/expertiza/expertiza/pull/2769
Pull Request: https://github.com/expertiza/expertiza/pull/2772

Team
Mentor
Nainisha Bhallamudi
Team Members
Anusha Akkireddy (aakkire)
Simon Getahun (sgetahu)
Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024

2024-10-28T23:29:24Z

Gwteague: adding my teams wiki page to this library

* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]