Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-22T12:56:55Z

Cdandre5: /* UI and API Integration Tests */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Instructir

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participants
2.5 signed_up_teams
2.6 teams_users
2.9 questions
2.10 users
2.11 teams
2.12 sign_up_topics
2.13 response_maps
2.14 responses
2.15 answers
2.16 score_views
2.17 tag_prompts
2.18 tag_prompts_deployments

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention. This was the main focus of this project.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:''' This component, loaded from App.tsx, initially used dummyAuthorFeedback data. Our goal was to replace this with an API call to retrieve real-time author feedback data from the backend. The updated implementation was reviewed to ensure proper API integration and dynamic rendering of review tables.

'''RoundSelector.tsx:''' Initially using dummy heatmap data, this component was updated to fetch live heatmap data via an API call. The review ensured that the component responds appropriately to data updates and correctly renders the heatmap.

'''Statistics.tsx:''' This component previously relied on static data for team-mates and author feedback. We mapped these to backend APIs. The review focused on validating the accuracy of the displayed statistics and their alignment with backend data.

'''ShowReview.tsx:''' This component was updated to dynamically display review content using data fetched from the backend instead of static placeholders. We reviewed this update to ensure it correctly loads the appropriate review details and handles edge cases like missing or malformed data.

Finally, we integrated all components with actual API calls, completing the transition from static content to dynamic, backend-driven data flow across the React frontend.

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram from the implementation plan remained the same, illustrating the consistent data flow between the React frontend components and the grades_controller.rb backend during grading data retrieval.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

[[File:Grades_Database.png|center|600px]]

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate the backend functionality to ensure frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

[[File:rspec_grades.png|center|600px]]

==API Endpoint Tests==

We used Postman to test our API endpoints during development and deployment. It allowed us to easily send HTTP requests and validate the structure and content of the responses. By simulating real client requests, we were able to verify authentication flows, check for correct status codes, and confirm that our endpoints returned the expected data, ensuring the backend was functioning as intended.

=== view_grading_report ===
[[File:API1.png|center|600px]]

=== view_my_scores ===
[[File:API2.png|center|600px]]

=== view_team ===
[[File:API3.png|center|600px]]

== UI and API Integration Tests==

To ensure the correctness and stability of our updated React components and their interaction with the backend, we conducted comprehensive UI and API integration tests. These tests were aimed at verifying both data flow and user experience across the full stack.

1. API Connectivity Testing --- We validated each API endpoint integrated into the frontend components by confirming:

*Successful HTTP GET requests and accurate response structures
*Proper handling of edge cases, such as missing or malformed data
*Consistent response times and error management (e.g., fallback behavior for failed requests)

2. Component-Level Integration --- Each React component (ReviewTable.tsx, RoundSelector.tsx, Statistics.tsx, and ShowReview.tsx) was tested in isolation to ensure:

*Correct rendering of dynamic content based on backend responses
*Smooth updates to the UI without page reloads
*Appropriate fallback UI for loading states or API errors

3. End-to-End Testing Scenarios --- We simulated real user interactions—such as selecting rounds, viewing reviews, and exploring statistics—to verify that:

*API calls are correctly triggered on user events
*The DOM updates accurately reflect the underlying data
*There are no regressions or stale data displayed

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-22T12:56:06Z

Cdandre5: /* UI and API Integration Tests */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Instructir

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participants
2.5 signed_up_teams
2.6 teams_users
2.9 questions
2.10 users
2.11 teams
2.12 sign_up_topics
2.13 response_maps
2.14 responses
2.15 answers
2.16 score_views
2.17 tag_prompts
2.18 tag_prompts_deployments

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention. This was the main focus of this project.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:''' This component, loaded from App.tsx, initially used dummyAuthorFeedback data. Our goal was to replace this with an API call to retrieve real-time author feedback data from the backend. The updated implementation was reviewed to ensure proper API integration and dynamic rendering of review tables.

'''RoundSelector.tsx:''' Initially using dummy heatmap data, this component was updated to fetch live heatmap data via an API call. The review ensured that the component responds appropriately to data updates and correctly renders the heatmap.

'''Statistics.tsx:''' This component previously relied on static data for team-mates and author feedback. We mapped these to backend APIs. The review focused on validating the accuracy of the displayed statistics and their alignment with backend data.

'''ShowReview.tsx:''' This component was updated to dynamically display review content using data fetched from the backend instead of static placeholders. We reviewed this update to ensure it correctly loads the appropriate review details and handles edge cases like missing or malformed data.

Finally, we integrated all components with actual API calls, completing the transition from static content to dynamic, backend-driven data flow across the React frontend.

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram from the implementation plan remained the same, illustrating the consistent data flow between the React frontend components and the grades_controller.rb backend during grading data retrieval.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

[[File:Grades_Database.png|center|600px]]

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate the backend functionality to ensure frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

[[File:rspec_grades.png|center|600px]]

==API Endpoint Tests==

We used Postman to test our API endpoints during development and deployment. It allowed us to easily send HTTP requests and validate the structure and content of the responses. By simulating real client requests, we were able to verify authentication flows, check for correct status codes, and confirm that our endpoints returned the expected data, ensuring the backend was functioning as intended.

=== view_grading_report ===
[[File:API1.png|center|600px]]

=== view_my_scores ===
[[File:API2.png|center|600px]]

=== view_team ===
[[File:API3.png|center|600px]]

== UI and API Integration Tests==

To ensure the correctness and stability of our updated React components and their interaction with the backend, we conducted comprehensive UI and API integration tests. These tests were aimed at verifying both data flow and user experience across the full stack.

1. API Connectivity Testing

We validated each API endpoint integrated into the frontend components by confirming:

*Successful HTTP GET requests and accurate response structures
*Proper handling of edge cases, such as missing or malformed data
*Consistent response times and error management (e.g., fallback behavior for failed requests)

2. Component-Level Integration

Each React component (ReviewTable.tsx, RoundSelector.tsx, Statistics.tsx, and ShowReview.tsx) was tested in isolation to ensure:

*Correct rendering of dynamic content based on backend responses
*Smooth updates to the UI without page reloads
*Appropriate fallback UI for loading states or API errors

3. End-to-End Testing Scenarios

We simulated real user interactions—such as selecting rounds, viewing reviews, and exploring statistics—to verify that:

*API calls are correctly triggered on user events
*The DOM updates accurately reflect the underlying data
*There are no regressions or stale data displayed

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-22T12:49:55Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Instructir

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participants
2.5 signed_up_teams
2.6 teams_users
2.9 questions
2.10 users
2.11 teams
2.12 sign_up_topics
2.13 response_maps
2.14 responses
2.15 answers
2.16 score_views
2.17 tag_prompts
2.18 tag_prompts_deployments

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention. This was the main focus of this project.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:''' This component, loaded from App.tsx, initially used dummyAuthorFeedback data. Our goal was to replace this with an API call to retrieve real-time author feedback data from the backend. The updated implementation was reviewed to ensure proper API integration and dynamic rendering of review tables.

'''RoundSelector.tsx:''' Initially using dummy heatmap data, this component was updated to fetch live heatmap data via an API call. The review ensured that the component responds appropriately to data updates and correctly renders the heatmap.

'''Statistics.tsx:''' This component previously relied on static data for team-mates and author feedback. We mapped these to backend APIs. The review focused on validating the accuracy of the displayed statistics and their alignment with backend data.

'''ShowReview.tsx:''' This component was updated to dynamically display review content using data fetched from the backend instead of static placeholders. We reviewed this update to ensure it correctly loads the appropriate review details and handles edge cases like missing or malformed data.

Finally, we integrated all components with actual API calls, completing the transition from static content to dynamic, backend-driven data flow across the React frontend.

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram from the implementation plan remained the same, illustrating the consistent data flow between the React frontend components and the grades_controller.rb backend during grading data retrieval.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

[[File:Grades_Database.png|center|600px]]

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate the backend functionality to ensure frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

[[File:rspec_grades.png|center|600px]]

==API Endpoint Tests==

We used Postman to test our API endpoints during development and deployment. It allowed us to easily send HTTP requests and validate the structure and content of the responses. By simulating real client requests, we were able to verify authentication flows, check for correct status codes, and confirm that our endpoints returned the expected data, ensuring the backend was functioning as intended.

=== view_grading_report ===
[[File:API1.png|center|600px]]

=== view_my_scores ===
[[File:API2.png|center|600px]]

=== view_team ===
[[File:API3.png|center|600px]]

== UI and API Integration Tests==

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-22T12:46:25Z

Cdandre5: /* UI */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Instructir

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participants
2.5 signed_up_teams
2.6 teams_users
2.9 questions
2.10 users
2.11 teams
2.12 sign_up_topics
2.13 response_maps
2.14 responses
2.15 answers
2.16 score_views
2.17 tag_prompts
2.18 tag_prompts_deployments

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention. This was the main focus of this project.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:''' This component, loaded from App.tsx, initially used dummyAuthorFeedback data. Our goal was to replace this with an API call to retrieve real-time author feedback data from the backend. The updated implementation was reviewed to ensure proper API integration and dynamic rendering of review tables.

'''RoundSelector.tsx:''' Initially using dummy heatmap data, this component was updated to fetch live heatmap data via an API call. The review ensured that the component responds appropriately to data updates and correctly renders the heatmap.

'''Statistics.tsx:''' This component previously relied on static data for team-mates and author feedback. We mapped these to backend APIs. The review focused on validating the accuracy of the displayed statistics and their alignment with backend data.

'''ShowReview.tsx:''' This component was updated to dynamically display review content using data fetched from the backend instead of static placeholders. We reviewed this update to ensure it correctly loads the appropriate review details and handles edge cases like missing or malformed data.

Finally, we integrated all components with actual API calls, completing the transition from static content to dynamic, backend-driven data flow across the React frontend.

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram from the implementation plan remained the same, illustrating the consistent data flow between the React frontend components and the grades_controller.rb backend during grading data retrieval.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

[[File:Grades_Database.png|center|600px]]

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate the backend functionality to ensure frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

[[File:rspec_grades.png|center|600px]]

==API Endpoint Tests==

We used Postman to test our API endpoints during development and deployment. It allowed us to easily send HTTP requests and validate the structure and content of the responses. By simulating real client requests, we were able to verify authentication flows, check for correct status codes, and confirm that our endpoints returned the expected data, ensuring the backend was functioning as intended.

=== view_grading_report ===
[[File:API1.png|center|600px]]

=== view_my_scores ===
[[File:API2.png|center|600px]]

=== view_team ===
[[File:API3.png|center|600px]]

== UI and API Integration Tests==

==Tables and Test Coverage==

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-22T12:39:08Z

Cdandre5: /* Data Flow Overview */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Instructir

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participants
2.5 signed_up_teams
2.6 teams_users
2.9 questions
2.10 users
2.11 teams
2.12 sign_up_topics
2.13 response_maps
2.14 responses
2.15 answers
2.16 score_views
2.17 tag_prompts
2.18 tag_prompts_deployments

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram from the implementation plan remained the same, illustrating the consistent data flow between the React frontend components and the grades_controller.rb backend during grading data retrieval.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

[[File:Grades_Database.png|center|600px]]

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate the backend functionality to ensure frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

[[File:rspec_grades.png|center|600px]]

==API Endpoint Tests==

We used Postman to test our API endpoints during development and deployment. It allowed us to easily send HTTP requests and validate the structure and content of the responses. By simulating real client requests, we were able to verify authentication flows, check for correct status codes, and confirm that our endpoints returned the expected data, ensuring the backend was functioning as intended.

=== view_grading_report ===
[[File:API1.png|center|600px]]

=== view_my_scores ===
[[File:API2.png|center|600px]]

=== view_team ===
[[File:API3.png|center|600px]]

== UI and API Integration Tests==

==Tables and Test Coverage==

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:28:45Z

Cdandre5: /* Completed Reimplementation Details */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate both backend functionality and frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

==API Endpoint (UI) Tests==

==Tables and Test Coverage==

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:28:28Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate both backend functionality and frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

==API Endpoint (UI) Tests==

==Tables and Test Coverage==

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:27:49Z

Cdandre5: /* Backend API Tests */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate both backend functionality and frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

==API Endpoint (UI) Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:19:32Z

Cdandre5: /* UI Tests */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

==Backend Tests==

After modifying several methods in grades_controller.rb to return JSON responses and integrate with the new React-based frontend, we conducted targeted RSpec tests to validate both backend functionality and frontend compatibility. These tests ensured that each controller method operated correctly in isolation and that the frontend components could successfully consume the API responses as expected.

RSpec tests were written for the following controller methods:

* action_allowed?
* view_my_scores
* view_team
* edit_participant_scores
* update_participant_grade
* update_team
* instructor_review

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:15:29Z

Cdandre5: /* Database Preparation */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

To enable consistent and repeatable testing, we populated the database with carefully designed mock data that simulates a variety of real-world grading scenarios. This approach ensured that our test environment closely mirrors actual usage patterns, allowing for more meaningful validation of the grades_controller.rb logic and its interactions with related models.

We created test scenarios that covered a range of use cases, including individual and team assignments, review rounds, and various submissions, to verify that each controller action behaves as expected under different conditions. By populating the relevant tables with representative data, we were able to rigorously test features like permission checks, grade updates, response mapping, and feedback rendering.

The specific databases that were populated can be found in the Database section.

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T20:12:01Z

Cdandre5: /* Testing Overview */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

After modifying several methods in grades_controller.rb to return JSON responses and support the new React-based frontend, we conducted comprehensive testing to ensure that both the backend logic and frontend integration functioned as intended. It was essential to validate not only that the backend endpoints behaved correctly in isolation, but also that the frontend components were able to successfully consume and render the data returned by the updated APIs.

We retested all affected methods to verify that data was retrieved accurately, permission checks were enforced, and updates were correctly persisted. In addition to running automated RSpec tests, we manually tested the backend endpoints using authenticated curl commands. These terminal-based tests allowed us to simulate real API usage, verify response structures, and confirm compatibility with the frontend. This dual-layered testing approach ensured a smooth and reliable interaction between the React UI and the Rails backend.

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T19:16:57Z

Cdandre5: /* Specific Objectives */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Reimplement Frontend and Backend Components''': Reimplement both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T19:14:52Z

Cdandre5: /* Links */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T19:14:41Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T19:12:23Z

Cdandre5: /* Database */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

In order to correctly populate each database, we referenced the Expertiza Database Documentation to understand the schema, and then mapped out the relevant tables needed by grades_controller.rb. Then we populated them with mock data to support development and testing of the new API-driven frontend.

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T19:08:12Z

Cdandre5: /* Database */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

A key component of this project involved populating the necessary database tables that the grades_controller.rb relies on to serve real-time data to the frontend. This step was essential for replacing the previously hardcoded or pre-populated dummy data with dynamic, API-driven content. Below is a list of the database tables that were seeded with mock data specifically for development and testing purposes in this project:

* roles
* institutions
* users
* assignments
* teams
* teams_users
* sign_up_topics
* signed_up_teams
* participants
* questionnaires
* questions
* assignment_questionaires
* response_maps
* responses
* score_views
* tag-prompts
* tag_prompt_deployments

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:54:34Z

Cdandre5: /* Completed Reimplementation Details */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

This section outlines the changes that were actually implemented as part of the reimplementation effort. It provides a detailed breakdown of how the frontend was decoupled from the legacy Ruby-embedded views, and how dynamic data flow was established using API endpoints. Specific components were modified to replace hardcoded or mock data with real-time API calls to the backend, ensuring that the application now reflects live grading data. Additionally, backend controller actions were updated to return clean, structured JSON responses, and the data retrieval logic was centralized to improve maintainability and testability.

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:42:05Z

Cdandre5: /* Data Flow Overview */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

==Data Flow Overview==

The diagram below illustrates the data flow between React frontend components and the grades_controller.rb backend during a typical grading data retrieval process.

* The user (such as an instructor or student) interacts with the React-based grades interface—components like ReviewTable, RoundSelector, or Statistics.

* In response to this interaction, the component initiates an API request to a specific endpoint in grades_controller.rb.

* The controller action then queries the relevant backend models (such as Assignment, Team, and ReviewResponseMap) and constructs a structured JSON response.

* This JSON data is returned to the frontend, where it is parsed by the corresponding React component.

* Finally, the React components dynamically update the UI—populating tables, generating heatmaps, or displaying statistics—based on the data received.

This architecture promotes a clear separation of concerns between frontend and backend layers, enabling more scalable development, easier debugging, and improved maintainability and testability across the application.

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:37:09Z

Cdandre5: /* UI */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We have successfully reimplemented the previously pre-populated data with appropriate HTTP GET calls to the backend. This ensures that our application now reflects real-time data directly from the server, improving data accuracy and consistency across the UI. This update also enhances scalability and maintainability, as the frontend no longer depends on static content and can adapt to backend changes without manual intervention.

All dummy data throughout these components has been successfully removed and replaced with real-time API integrations. This transition allows for a fully dynamic, data-driven React frontend that remains synchronized with backend updates and user interactions.

Files and components that were updated:

'''ReviewTable.tsx:'''

'''RoundSelector.tsx:'''

'''Statistics.tsx:'''

==Database==

==Data Flow Overview==

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:28:48Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

==Database==

==Data Flow Overview==

=Testing=

==Testing Overview==

==Database Preparation==

==UI Tests==

==Backend API Tests==

==Tables and Test Coverage==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:26:57Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

==Database==

==Data Flow Overview==

==Testing==

Overview:

===UI Tests===

===Backend API Tests===

2.5 Test Plan
2.6 Tools and Frameworks
2.7 1. UI Integration Tests
2.7.1 ReviewTable Component
2.7.2 RoundSelector Component
2.7.3 Statistics Component
2.7.4 General UI Considerations
2.8 2. Backend API Tests
2.8.1 grades_controller.rb
2.8.2 Security & Permissions
2.9 3. Database Preparation
2.9.1 Tables and Test Coverage
2.9.2 Scenarios
2.10 4. Regression & CI Testing
2.11 Test Plan Summary

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:24:49Z

Cdandre5: /* Testing */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

==Database==

==Data Flow Overview==

==Testing==

2.5 Test Plan
2.6 Tools and Frameworks
2.7 1. UI Integration Tests
2.7.1 ReviewTable Component
2.7.2 RoundSelector Component
2.7.3 Statistics Component
2.7.4 General UI Considerations
2.8 2. Backend API Tests
2.8.1 grades_controller.rb
2.8.2 Security & Permissions
2.9 3. Database Preparation
2.9.1 Tables and Test Coverage
2.9.2 Scenarios
2.10 4. Regression & CI Testing
2.11 Test Plan Summary

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:02:20Z

Cdandre5: /* API */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

These updates were important for the backend and ensured seamless communication with the React frontend. By removing instance variables and returning structured JSON responses, we eliminated dependencies on server-side rendering and enabled the frontend to dynamically manage and render data. This not only enhances performance and flexibility but also improves maintainability and scalability as the application evolves. Moreover, it allows the backend and frontend to evolve independently, supporting better separation of concerns and aligning with current best practices in full-stack web development.

==UI==

==Database==

==Data Flow Overview==

==Testing==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:00:56Z

Cdandre5: /* API */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

==UI==

==Database==

==Data Flow Overview==

==Testing==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T18:00:34Z

Cdandre5: /* API */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)
# return if redirect_when_disallowed(participant)
questions = fetch_questionnaires_and_questions(assignment)
pscore = fetch_participant_scores(participant, questions)
topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)
# all_penalties = update_penalties(assignment)
# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

==UI==

==Database==

==Data Flow Overview==

==Testing==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:59:57Z

Cdandre5: /* API */

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

The purpose of this project is to integrate the frontend of the grades view page with the reimplemented '''''grades_controller.rb (E2510)''''' backend in Expertiza, ensuring a seamless connection between both layers. This integration involves refining the interaction between the UI and backend while adhering to best design principles such as modularity, maintainability, and scalability. The grades_controller.rb is responsible for managing grading functionality, allowing instructors to view and modify assignment grades while enabling students to access their evaluations. By following SOLID and DRY principles, this reimplementation enhances code clarity, reduces redundancy, and improves overall system efficiency.

==Background==
The <code>grades_controller.rb</code> is responsible for managing and delivering grading data to users in the Expertiza system. It enables instructors to view, calculate, and release grades to students, while also allowing students to view feedback and scores for assignments. The controller plays an important role in coordinating backend logic for reviews and grade visibility.

==Previous Implementation==

The previous implementation successfully created a functional frontend UI page in Expertiza, addressing design inconsistencies and improving usability. It introduced a visually cohesive interface with an intuitive layout, enhanced responsiveness, and improved information display, allowing users to navigate grading data more efficiently. However, the interface was populated using dummy data, limiting its practical use. This reimplemented UI will utilize real data from the database (that has been populated in this round), ensuring that grading information is dynamically retrieved and displayed accurately through JSON objects. Additionally, this phase will connect the redesigned frontend with some new components in the grades_controller.rb. Specifically, the GET functions in the grades_controller were reimplemented to return JSON objects (instead of instance variables) that could be accessed via an API call. Thus, this new implementation ensures seamless communication between the UI and backend while adhering to best design practices for maintainability and scalability.

==Project Statement==

This project focuses on integrating the frontend of the grades view page with the reimplemented '''grades_controller.rb (E2510)''' backend in Expertiza. This integration requires modifications to both the frontend and backend to establish a seamless connection, ensuring that grading data is dynamically retrieved and displayed accurately. By adhering to best design principles such as modularity, maintainability, and scalability, the implementation will enhance system efficiency and long-term usability. Key improvements include replacing dummy data with real database values, refining data flow between the UI and backend, and optimizing API interactions for better performance. These enhancements will create a more intuitive and reliable grading system, providing a seamless experience for instructors and students while maintaining a well-structured and adaptable codebase for future development.

==Specific Objectives==

# '''Establish a Robust Connection Between the Frontend and Backend''': Ensure smooth data retrieval and updates between the grades view page and the backend by integrating dynamic data through API calls, replacing the current hardcoded dummy data.
# '''Define and Implement Clear API Endpoints''': Create well-structured API endpoints in grades_controller.rb for retrieving and displaying grades, ensuring they return appropriate data based on user roles (students, instructors, TAs) and maintain role-based access controls.
# '''Dynamic Data Integration''': Modify the frontend to consume real-time data fetched from the backend, ensuring an intuitive and responsive UI that reflects the actual grading information.
# '''Refactor Frontend and Backend Components''': Refactor both the frontend and backend as necessary to align with SOLID and DRY principles, ensuring modularity, maintainability, and scalability. This includes eliminating redundant logic and optimizing code for better readability.
# '''Implement Proper Permission Checks''': Ensure that only authorized users can access grade information by implementing robust privilege checks and ensuring that the data is securely accessible to students, instructors, and TAs based on their roles.
# '''Optimize Database Queries and API Responses''': Enhance the efficiency of database queries and API responses to reduce unnecessary load and ensure that data is retrieved and displayed promptly.
# '''Testing and Validation''': Implement comprehensive unit and integration tests to verify the correctness of data flow, UI interactions, and role-based access controls, ensuring that the system functions correctly and securely.

=Reimplementation Plan=

==UI==

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populated data with the appropriate HTTP GET and HTTP POST calls. This shift is necessary to ensure that our application reflects real-time data from the backend rather than relying on static or hardcoded values, which can quickly become outdated or inconsistent. It also enables better scalability and maintainability, as changes to the data only need to be made in the backend, without requiring manual updates in the frontend code.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

'''Author Feedback''':
{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Heatmap Data''':
{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}
'''Team-mate Data''':
{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

==API==

The current implementation caters to the backend for a Ruby-embedded front-end, where data is rendered server-side and passed directly into the view. We need to update the APIs to return data in a format that can be consumed by the React UI, typically JSON. This shift is essential to decouple the front-end from the server-side rendering logic, allowing for a more interactive and dynamic user experience. By transitioning to a React-based interface, we gain better control over UI state and responsiveness, while also aligning with modern web development practices. The files that need to be updated for the integration would be as follows:

'''grades_controller.rb:'''

Update the following functions to remove instance variables and instead return plain JSON objects using render json: in the response. This change is necessary to align with a frontend architecture that uses React or another JavaScript framework, which expects structured data from the backend in JSON format rather than relying on server-rendered templates. By shifting to JSON responses, we enable cleaner API endpoints, facilitate easier testing and debugging, and support a more maintainable, decoupled frontend-backend integration.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

</syntaxhighlight>

==Database==

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students
1.2. Teams
1.3. TA
1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments
2.2 assignment_questionnaire
2.3 questionnaires
2.4 participant
2.5 signed_up_teams
2.6 teams_users
2.7 due_dates
2.8 late_policies
2.9 questions
2.10 review_scores
2.11 review_grades

== Data Flow Overview ==
The diagram below illustrates how data flows between the frontend React components and the grades_controller.rb backend during a typical grading data fetch operation.

* The user (e.g., instructor or student) interacts with the React-based grades view (e.g., ReviewTable, RoundSelector, or Statistics).
* The component triggers an API request to a specific action in grades_controller.rb (e.g., GET /grades/:id/summary).
*The controller action queries the relevant models (e.g., Assignment, Team, ReviewResponseMap) and compiles a JSON response.
* The response is sent back to the frontend and parsed.
*The React components update the UI (tables, heatmaps, statistics) based on the received data.

This architecture ensures a clean separation between frontend and backend logic, improving maintainability and testability.
[[File:Dataflow.png|center|600px]]

==Test Plan==
The test plan for Phase 2 focuses on verifying the successful integration of the newly reimplemented <code>grades_controller.rb</code> with the React-based UI components. We aim to ensure data is:

* Correctly fetched from the backend
* Appropriately displayed in the frontend
* Functionally sound under both normal and edge-case scenarios

== Tools and Frameworks ==
We plan to use the following tools and frameworks for testing:

* '''Frontend''': Jest and React Testing Library for unit and integration tests
* '''Backend''': RSpec for controller and model tests
* '''Integration Testing''': Capybara and Selenium for simulating real user behavior
* '''Test Coverage''': SimpleCov

== 1. UI Integration Tests ==

These tests ensure the frontend correctly interacts with backend APIs and renders the data appropriately.

=== ReviewTable Component ===

* Validate that the component makes a successful API call to fetch author feedback
* Ensure feedback is rendered in the correct table structure
* Test loading state before data is fetched
* Handle empty or malformed feedback responses gracefully

=== RoundSelector Component ===

* Verify API call to fetch heatmap data is triggered on component load
* Check that heatmap data is correctly visualized for different review rounds
* Test behavior with no data, incomplete data, or delayed response

=== Statistics Component ===

* Confirm it correctly fetches teammate evaluations and author feedback
* Ensure charts or tables reflect the received backend data accurately
* Test switching between different teams or assignments and verify correct display

=== General UI Considerations ===

* Test frontend responsiveness to backend failures (500, 404, timeout)
* Ensure authorization errors are handled and appropriate messages displayed

== 2. Backend API Tests ==

While unit tests exist, integration-level tests will be added or updated to ensure UI compatibility.

=== <code>grades_controller.rb</code> ===

* Validate all <code>GET</code> endpoints return properly structured JSON objects
* Simulate various user roles (student, TA, instructor) and ensure access control
* Include test cases for:
** No grades present
** Partial data (e.g. missing feedback or evaluations)
** Large number of records

=== Security & Permissions ===

* Ensure students can only fetch their grades and feedback
* Ensure TAs and instructors can access full assignment data
* Test token/session-based access restrictions (if applicable)

== 3. Database Preparation ==

To enable consistent and repeatable testing, seed data will simulate real-world usage and we will ensure that:
* Tests will use isolated fixtures or factories to ensure data consistency
* All database states will be reset before each test suite run

=== Tables and Test Coverage ===

* <code>assignments</code>, <code>assignment_participant</code>, <code>participants</code>
* <code>questionnaires</code>, <code>questions</code>, <code>assignment_questionnaire</code>
* <code>teams</code>, <code>signed_up_teams</code>, <code>teams_users</code>
* <code>due_dates</code>, <code>assignment_due_dates</code>, <code>late_policies</code>

=== Scenarios ===

* Single student assigned
* Team assignments with/without feedback
* Late submissions triggering late policies
* Multiple review rounds per assignment

== 4. Regression & CI Testing ==

To ensure updates do not break existing functionality:

* Re-run all existing unit tests
* Include snapshot tests for frontend components
* Use CI pipelines to automatically trigger tests on pull requests

== Test Plan Summary ==

This test plan outlines the approach for integrating <code>grades_controller.rb</code> with the frontend. By combining backend tests, UI integration checks, and realistic database scenarios, we aim to deliver a seamless user experience. The plan emphasizes early detection of issues and supports long-term maintainability through regression testing. As development progresses, the plan will be updated to cover new insights and edge cases.

=Completed Reimplementation Details=

==API==

The previous implementation was designed for a Ruby-embedded front-end, where data was rendered server-side and injected directly into the view. We have since updated the APIs to return data in a format suitable for consumption by the React UI, typically as JSON objects. This change successfully decouples the front-end from the server-side rendering logic, enabling a more interactive and responsive user experience. By transitioning to a React-based interface, we now have improved control over UI state and better alignment with modern web development practices.

'''grades_controller.rb:'''

In this controller, we have updated the GET functions to remove the use of instance variables and instead return plain JSON objects using render json: in the response. This update was essential to align with the frontend architecture, which now relies on a React-based interface that expects structured data from the backend in JSON format rather than server-rendered templates. By returning JSON responses, we’ve established cleaner and more consistent API endpoints, improved the testability and debuggability of our backend logic, and created a more maintainable and decoupled integration between the frontend and backend systems. The following functions were updated as part of this integration:

<syntaxhighlight lang="ruby">

def view_grading_report
assignment_id = params[:id].to_i
data = get_data_for_heat_map(assignment_id)

render json: data, status: :ok
end

def view_my_scores
participant = AssignmentParticipant.find(params[:id].to_i)
assignment = participant.assignment
team_id = TeamsUser.team_id(participant.assignment_id, participant.user_id)

# return if redirect_when_disallowed(participant)

questions = fetch_questionnaires_and_questions(assignment)

pscore = fetch_participant_scores(participant, questions)

topic_id = SignedUpTeam.find_topic_id_for_user(participant.assignment.id, participant.user_id)
stage = participant.assignment.current_stage(topic_id)

# all_penalties = update_penalties(assignment)

# Feedback Summary needs to be checked once
# summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(questions, assignment, team_id, 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa', session)

render json: {
participant: participant,
assignment: assignment,
team_id: team_id,
topic_id: topic_id,
stage: stage,
questions: questions,
pscore: pscore,
summary: sum.summary,
avg_scores_by_round: sum.avg_scores_by_round,
avg_scores_by_criterion: sum.avg_scores_by_criterion
}
end

def view_team
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
team = participant.team
team_id = team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: assignment.id).map(&:questionnaire)
questions = retrieve_questions(questionnaires, assignment.id)
pscore = Response.participant_scores(participant, questions)
vmlist = process_questionare_for_team(assignment, team_id,questionnaires, team, participant)

render json: {
participant: participant,
assignment: assignment,
team: team,
team_id: team_id,
questions: questions,
pscore: pscore,
vmlist: vmlist
}
end

</syntaxhighlight>

==UI==

==Database==

==Data Flow Overview==

==Testing==

==Adhering to Priciples==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:52:34Z

Cdandre5: /* Completed Reimplementation Details */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:51:41Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:50:20Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:48:41Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:46:46Z

Cdandre5: /* Completed Reimplementation Details */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:44:39Z

Cdandre5: /* Completed Reimplementation Details */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:43:43Z

Cdandre5: /* Implementation Plan */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:43:22Z

Cdandre5:

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:36:20Z

Cdandre5: /* Implementation Plan */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:35:44Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:35:28Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:35:20Z

Cdandre5: /* API */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:33:37Z

Cdandre5: /* UI */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-20T17:26:34Z

Cdandre5: /* Previous Implementation */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T13:09:28Z

Cdandre5: /* Specific Objectives */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T13:07:47Z

Cdandre5: /* Specific Objectives */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T13:05:06Z

Cdandre5: /* Project Statement */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T13:03:01Z

Cdandre5: /* Previous Implementation */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:57:51Z

Cdandre5: /* Introduction */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:57:33Z

Cdandre5: /* Introduction */

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:55:45Z

Cdandre5:

=E2530: Integration of Grades View Frontend with Grades Controller Backend=

==Introduction==

==Previous Implementation==

==Project Statement==

==Specific Objectives==

==Implementation Plan==

===UI===

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populate data with the appropriate HTTP GET and HTTP POST calls.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

Author Feedback:

{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}

Heatmap Data:

{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}

Team-mate Data:

{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

===API===

Current implementation caters to the backend for a ruby embedded front-end. We need to update the APIs to return data that can be consumed by the React UI. The files that need to be updated for the integration would be as follows:

'''Grades_controller.rb:'''

Update the following functions to remove instance variables and make it a json object for response from the API so the UI can consume it.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

def edit_participant_scores
@participant = find_participant(params[:id])
return unless @participant # Exit early if participant not found
@assignment = @participant.assignment
@questions = list_questions(@assignment)
@scores = Response.review_grades(@participant, @questions)
end

</syntaxhighlight>

===Database===

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students

1.2. Teams

1.3. TA

1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments

2.2 assignment_questionnaire

2.3 questionnaires

2.4 questions

2.5 assignment_participant

2.6 participant

2.7 signed_up_teams

2.8 teams_users

2.9 questions

2.10 due_dates

2.11 assignment_due_dates

2.12 late_policies

==Test Plan==

==Implementation Details==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Team=

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:44:11Z

Cdandre5: /* Implementation Details */

=E2530: Reimplement Grades Controller (Frontend + Backend)=

==Introduction==

==Previous Implementation==

==Project Statement==

==Specific Objectives==

==Implementation Plan==

===UI===

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populate data with the appropriate HTTP GET and HTTP POST calls.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

Author Feedback:

{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}

Heatmap Data:

{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}

Team-mate Data:

{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

===API===

Current implementation caters to the backend for a ruby embedded front-end. We need to update the APIs to return data that can be consumed by the React UI. The files that need to be updated for the integration would be as follows:

'''Grades_controller.rb:'''

Update the following functions to remove instance variables and make it a json object for response from the API so the UI can consume it.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

def edit_participant_scores
@participant = find_participant(params[:id])
return unless @participant # Exit early if participant not found
@assignment = @participant.assignment
@questions = list_questions(@assignment)
@scores = Response.review_grades(@participant, @questions)
end

</syntaxhighlight>

===Database===

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students

1.2. Teams

1.3. TA

1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments

2.2 assignment_questionnaire

2.3 questionnaires

2.4 questions

2.5 assignment_participant

2.6 participant

2.7 signed_up_teams

2.8 teams_users

2.9 questions

2.10 due_dates

2.11 assignment_due_dates

2.12 late_policies

==Test Plan==

==Implementation Details==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

===Implementation Details===

By adhering to SOLID and DRY principles, we can reimplement the grades controller in a way that ensures seamless compatibility with the UI while maintaining a clean, efficient, and scalable architecture. By keeping the controller focused solely on handling HTTP requests and delegating grading logic to dedicated service objects, we enhance separation of concerns and reduce redundancy. Implementing well-structured API endpoints that follow RESTful principles will ensure that the frontend can easily retrieve and update grading data without unnecessary complexity. Additionally, by designing the system to be extensible through abstraction and modular components, we allow future enhancements—such as new grading policies or UI updates—without modifying existing core logic. Standardizing validation and error-handling mechanisms across both layers will improve data consistency and provide a smoother user experience. This structured approach not only ensures compatibility with the UI but also creates a robust foundation for long-term maintainability and scalability.

=Team=

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:41:24Z

Cdandre5: /* Implementation Details */

=E2530: Reimplement Grades Controller (Frontend + Backend)=

==Introduction==

==Previous Implementation==

==Project Statement==

==Specific Objectives==

==Implementation Plan==

===UI===

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populate data with the appropriate HTTP GET and HTTP POST calls.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

Author Feedback:

{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}

Heatmap Data:

{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}

Team-mate Data:

{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

===API===

Current implementation caters to the backend for a ruby embedded front-end. We need to update the APIs to return data that can be consumed by the React UI. The files that need to be updated for the integration would be as follows:

'''Grades_controller.rb:'''

Update the following functions to remove instance variables and make it a json object for response from the API so the UI can consume it.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

def edit_participant_scores
@participant = find_participant(params[:id])
return unless @participant # Exit early if participant not found
@assignment = @participant.assignment
@questions = list_questions(@assignment)
@scores = Response.review_grades(@participant, @questions)
end

</syntaxhighlight>

===Database===

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students

1.2. Teams

1.3. TA

1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments

2.2 assignment_questionnaire

2.3 questionnaires

2.4 questions

2.5 assignment_participant

2.6 participant

2.7 signed_up_teams

2.8 teams_users

2.9 questions

2.10 due_dates

2.11 assignment_due_dates

2.12 late_policies

==Test Plan==

==Implementation Details==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend, ensuring a more maintainable, scalable, and efficient design. By refining the controller’s scope to its intended core functionality, we will enhance separation of concerns, making the system easier to extend and modify without introducing unnecessary complexity. As we rebuild the connection between the frontend UI and the backend, we will ensure that each component has a clearly defined responsibility, reducing dependencies and promoting modularity. This approach will allow for greater flexibility in future updates, improve overall code clarity, and align with best practices in software architecture. By structuring the system around these principles, we will create a robust foundation that supports long-term maintainability and adaptability.

===DRY Principle===

We aim to adhere to the DRY principle by eliminating redundancy and centralizing logic, ensuring a more modular and maintainable system. As we reimplement the connection between the frontend UI and the backend grades controller, we will focus on streamlining data flow and avoiding duplication in both layers. By structuring the system to rely on reusable components and well-defined method calls, we will improve consistency and reduce the risk of discrepancies across the application. This approach will enhance code clarity, simplify future modifications, and create a more efficient and scalable implementation.

=Team=

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==

CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)

2025-04-03T12:37:58Z

Cdandre5: /* Implementation Details */

=E2530: Reimplement Grades Controller (Frontend + Backend)=

==Introduction==

==Previous Implementation==

==Project Statement==

==Specific Objectives==

==Implementation Plan==

===UI===

1. The Fetch API is a built-in JavaScript interface for making HTTP requests to backend APIs, providing a modern and flexible way to handle network operations. We would replace the currently pre-populate data with the appropriate HTTP GET and HTTP POST calls.

2. Files and components that need to updated:

'''ReviewTable.tsx:''' This component is loaded from the App.tsx. It makes use of the dummyAuthorFeedback data. We would need to replace this json with the appropriate API call from the backend.

'''RoundSelector.tsx:''' This component makes use of the dummy data for a heat map. So we would need to replace it with the API call to get the heat map data from the APIs.

'''Statistics.tsx:''' This component uses the team-mates data and author feedback data which would need to be mapped to APIs from the backend.

3. Replace dummy data and substitute with actual API calls. Following are the samples of some the dummy data being used which would need to be translated to the API responses:

Author Feedback:

{
"questionNumber": "1",
"questionText": "This reviewer appeared to understand my work.",
"reviews": [
{ "name": "John", "score": 5, "comment": "The reviewer demonstrated a deep understanding of the work, providing insightful feedback." },
{ "name": "Alice", "score": 3, "comment": "While the reviewer grasped the main points, some aspects could have been clarified further." },
{ "name": "Bob", "score": 4, "comment": "The reviewer's understanding was evident, although certain nuances could have been explored more." },
{ "name": "Emma", "score": 5, "comment": "The reviewer showcased a comprehensive understanding of the work, offering valuable insights." },
{ "name": "Mike", "score": 4, "comment": "The reviewer's comprehension was evident, but a few minor details could have been addressed." }
],
"RowAvg": 0,
"maxScore": 5
}

Heatmap Data:

{
"questionNumber": "1",
"questionText": "What is the main purpose of this feature?",
"reviews": [
{ "name": "John", "score": 4, "comment": "Great work on this aspect!" },
{ "name": "Alice", "score": 3, "comment": "Could use some improvement here." },
{ "name": "Bob", "score": 4, "comment": "The presentation was well-organized and clear. However, some points could have been elaborated further to provide a deeper understanding of the topic." },
{ "name": "Emma", "score": 5, "comment": "The speaker demonstrated a profound understanding of the subject matter, making the session engaging and informative." },
{ "name": "Mike", "score": 4, "comment": "The visuals were compelling and helped in understanding complex concepts easily. However, there were a few slides with too much text, which made it hard to follow at times." },
{ "name": "Sophia", "score": 5, "comment": "The use of real-world examples made the concepts more relatable and easier to grasp. Additionally, the speaker was engaging and kept the audience hooked throughout." },
{ "name": "David", "score": 4, "comment": "The interactive exercises were beneficial in reinforcing the learning. However, there were a few technical glitches that disrupted the flow." },
{ "name": "Olivia", "score": 5, "comment": "The hands-on activities were the highlight of the session, providing practical experience that complemented the theoretical learning." },
{ "name": "William", "score": 4, "comment": "The guest speaker brought a fresh perspective to the topic, offering valuable insights that sparked further discussions among the participants." },
{ "name": "Sophia", "score": 5, "comment": "The case studies presented were enlightening, providing practical examples that showcased the application of theoretical concepts." }
],
"RowAvg": 0,
"maxScore": 5
}

Team-mate Data:

{
"questionNumber": "1",
"questionText": "How many times was this person late to meetings?",
"reviews": [
{ "name": "John", "score": 5, "comment": "He was never late for any meeting." },
{ "name": "Alice", "score": 4, "comment": "She was late once due to traffic." },
{ "name": "Bob", "score": 5, "comment": "He was punctual for all meetings." }
],
"RowAvg": 0,
"maxScore": 5
}

===API===

Current implementation caters to the backend for a ruby embedded front-end. We need to update the APIs to return data that can be consumed by the React UI. The files that need to be updated for the integration would be as follows:

'''Grades_controller.rb:'''

Update the following functions to remove instance variables and make it a json object for response from the API so the UI can consume it.

<syntaxhighlight lang="ruby">

def view_grading_report
get_data_for_heat_map(params[:id].to_i)
update_penalties
@show_reputation = false
end

def view_my_scores
@participant = AssignmentParticipant.find(params[:id].to_i)
@assignment = @participant.assignment
@team_id = TeamsUser.team_id(@participant.assignment_id, @participant.user_id)
return if redirect_when_disallowed

fetch_questionnaires_and_questions
fetch_participant_scores

@topic_id = SignedUpTeam.topic_id(@participant.assignment.id, @participant.user_id)
@stage = @participant.assignment.current_stage(@topic_id)
update_penalties

# prepare feedback summaries
fetch_feedback_summary
end

def view_team
@participant = AssignmentParticipant.find(params[:id])
@assignment = @participant.assignment
@team = @participant.team
@team_id = @team.id

questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: nil).map(&:questionnaire)
@questions = retrieve_questions(questionnaires, @assignment.id)
@pscore = Response.participant_scores(@participant, @questions)
@penalties = get_penalty(@participant.id)
@vmlist = process_questionare_for_team(@assignment, @team_id)

@current_role_name = current_role_name
end

def edit_participant_scores
@participant = find_participant(params[:id])
return unless @participant # Exit early if participant not found
@assignment = @participant.assignment
@questions = list_questions(@assignment)
@scores = Response.review_grades(@participant, @questions)
end

</syntaxhighlight>

===Database===

1. Populate the database with appropriate dummy data to cover all possible scenarios when visiting the

1.1. Students

1.2. Teams

1.3. TA

1.4. Professor

2. The following database tables would be populated with the data which can be accessed via the API layer and then displayed on the UI

2.1 assignments

2.2 assignment_questionnaire

2.3 questionnaires

2.4 questions

2.5 assignment_participant

2.6 participant

2.7 signed_up_teams

2.8 teams_users

2.9 questions

2.10 due_dates

2.11 assignment_due_dates

2.12 late_policies

==Test Plan==

==Implementation Details==

===SOLID Principles===

We will focus on adhering to SOLID design principles as we reimplement the grades controller on both the frontend and backend. By refining the controller’s scope to its intended core functionality, we aim to create a more maintainable and efficient design. This approach ensures better separation of concerns, improved extensibility, and overall code clarity while aligning with best practices in software architecture.

=Team=

==Mentor==

* Singh Shaktawat, Aniket <[mailto:ashakta@ncsu.edu ashakta@ncsu.edu]>

==Team Members==

* Andrews, Christopher <[mailto:cdandre5@ncsu.edu cdandre5@ncsu.edu]>
* Andurkar, Priya <[mailto:pandurk@ncsu.edu pandurk@ncsu.edu]>
* Shah, Jayneel <[mailto:jshah26@ncsu.edu jshah26@ncsu.edu]>

=Links=

==Link to Pull Request==

==Link to Tests==