Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:13:19Z

Mpundli: /* References */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Added ColumnButton UI component for Button with Tooltips. This component can be extended in other components and can act as a wrapper.
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.
**Unit test cases written in Jest - This code contains a set of unit tests for the `ColumnButton` component in a React application, using `@testing-library/react` and `jest`. It mocks components from the `react-bootstrap` library, such as `Button`, `Tooltip`, and `OverlayTrigger`, to simplify the tests without relying on the actual library. The tests check the behavior of the `ColumnButton` component by verifying its functionality under different conditions. First, it ensures that the `onClick` function is called when the button is clicked. The second test checks that a tooltip is rendered when the `tooltip` prop is provided, while the third test confirms that the tooltip is not rendered when the `tooltip` prop is undefined. These tests ensure the component behaves correctly with respect to user interaction and conditional rendering of the tooltip.
[[File:UT-1.png]]

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]
*[https://www.youtube.com/watch?v=pbi0EzmWJrw Demo Link]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:08:02Z

Mpundli: /* Front-End Enhancements */

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:06:43Z

Mpundli: /* Test Plan */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.
**Unit test cases written in Jest - This code contains a set of unit tests for the `ColumnButton` component in a React application, using `@testing-library/react` and `jest`. It mocks components from the `react-bootstrap` library, such as `Button`, `Tooltip`, and `OverlayTrigger`, to simplify the tests without relying on the actual library. The tests check the behavior of the `ColumnButton` component by verifying its functionality under different conditions. First, it ensures that the `onClick` function is called when the button is clicked. The second test checks that a tooltip is rendered when the `tooltip` prop is provided, while the third test confirms that the tooltip is not rendered when the `tooltip` prop is undefined. These tests ensure the component behaves correctly with respect to user interaction and conditional rendering of the tooltip.
[[File:UT-1.png]]

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:04:59Z

Mpundli: /* Test Plan */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.
**Unit test cases written in Jest
[[File:UT-1.png]]

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:04:43Z

Mpundli: /* Test Plan */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.
**Unit test cases written in Jest
[[File:UT-1.png]]

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

File:UT-1.png

2024-12-04T00:04:22Z

Mpundli:

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:01:43Z

Mpundli: /* High-Level System Overview */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-04T00:01:08Z

Mpundli:

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**User Retrieval: The code now fetches the user based on the user_id parameter (params[:user_id]) instead of ta_id, which means it is no longer using params[:ta_id] for the user lookup.
**Error Handling: If the user doesn't exist, an error message indicating the invalid user_id is returned.
[[File:Code-1.jpeg]]
[[File:Add-TA-method.jpeg]]

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

[[File:Code-1.jpeg]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

File:Add-TA-method.jpeg

2024-12-03T23:56:22Z

Mpundli:

File:Code-1.jpeg

2024-12-03T23:55:27Z

Mpundli:

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:52:50Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

File:UI-7.jpeg

2024-12-03T23:52:17Z

Mpundli:

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:52:09Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg|width=50px|height=200px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.
[[File:UI-5.jpeg]]

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
[[File:UI-7.jpeg]]
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.
[[File:UI-2.jpeg]]

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:48:07Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[File:UI-6.jpeg | width=500px | height=300px]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:43:46Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.
[[UI-6.jpeg]]

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

File:UI-6.jpeg

2024-12-03T23:41:03Z

Mpundli:

File:UI-5.jpeg

2024-12-03T23:40:10Z

Mpundli:

File:UI-4.jpeg

2024-12-03T23:39:53Z

Mpundli:

File:UI-3.jpeg

2024-12-03T23:39:34Z

Mpundli:

File:UI-2.jpeg

2024-12-03T23:38:23Z

Mpundli:

File:TA Added.jpeg

2024-12-03T23:37:44Z

Mpundli:

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:31:14Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Replace the "Manage Users" icon for intuitive user association.

**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:28:29Z

Mpundli: /* Backend Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Place the course name below the search box.
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:28:13Z

Mpundli:

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Place the course name below the search box.
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**Implement validations to check if the user is already a TA.

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-12-03T23:25:45Z

Mpundli: /* Front-End Enhancements */

__TOC__

==Introduction==

The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management process more efficient while improving the user experience for both instructors and students.This document outlines design improvements for the course management application, focusing on the management of Teaching Assistants (TAs) and interface modifications for the course pages. The document will walk through both front-end and back-end updates, including interface changes, TA search functionality, error handling, and the addition of multiple TAs to a course.

==Problem Statement==

The current TA management and course pages lack several functionalities, resulting in usability issues. Specifically:

* Course Interface: The interface requires rearrangement of elements, better iconography, and enhanced user interactions.

* TA Management: The TA assignment process needs improved filtering, error handling, and the ability to assign multiple TAs at once.

* Backend TA Handling: The backend API requires updates to accurately handle TA assignments, role changes, and validations.

==Current Implementation==

* Course Management: Includes a course list with an actions column for editing, deletion, and user management.

* TA Management: TA addition is handled through add_ta in courses_controller.rb, which currently uses incorrect parameters.

* TA Utility: The TAUtils.ts manages TA addition in the frontend, but lacks error differentiation and does not limit TA suggestions to unassigned users only.

==Issue with Current Implementation==

* Interface Usability: The course management page lacks an intuitive layout and functionality for managing TAs.

* Parameter Mismatch: Backend add_ta method incorrectly uses ta_id, causing issues with TA assignments.

* Limited TA Assignment: The backend and frontend do not currently support assigning multiple TAs at once, and all users, regardless of current assignment, are displayed.

* Error Handling: No specific error messaging is provided for TA assignment failures.

==Proposed Solution==
====Front-End Enhancements====
* Manage Courses Page:
**Place the course name below the search box.
**Replace the "Manage Users" icon for intuitive user association.
**Add hover tooltips on action buttons (Edit, Delete, Assign TA, Copy).
**Relocate the Delete button to the end for better UX flow.

* Manage TAs Page:
**Display a message, "No TAs assigned currently," in the absence of TA assignments.
**Update the button with an improved icon and tooltip.

* Add TAs Page:
**Introduce a TA search by name functionality.
**Show an error popup with separated title and error details.
**Limit the dropdown/search suggestions to only unassigned TAs.
**Display the current TA list, if any; otherwise, show a "No TAs assigned" message.

====Backend Enhancements====

*Controller Modification:
**Update add_ta in courses_controller.rb to use params[:id] instead of params[:ta_id].
**Implement validations to check if the user is already a TA.

*Course Model Update:
**Refactor add_ta in course.rb to accept a list of TAs, validate each, and return an aggregated success or error response.
**Update TaMapping model to link users and courses in bulk, and change user roles appropriately.

==High-Level System Overview==

The following diagram illustrates the high-level architecture of the system, showcasing the interaction flow between the frontend and backend components involved in adding TAs to a course.

====High-Level Request Flow:====

*User Interaction: The instructor interacts with the frontend (via a web interface).
*Frontend Requests: The frontend sends an API request to the backend with the selected TA(s) and course details.
*Backend Processing: The backend validates the TA(s), assigns roles, and creates TA mappings between the user and the course.
*Response to Frontend: Success or error responses are sent back to the frontend, where they are displayed to the user.

[[File:UML_1.png]]

====Detailed Flow Description:====

*1. User Interaction (Frontend):
**The instructor selects one or more TAs and submits the form to add them to a specific course.

* Frontend API Call:
**A POST request is sent to the backend API at /courses/:id/add_tas, including the ta_ids (IDs of the TAs to be added).

* Backend Processing:
** Controller: The backend courses_controller.rb processes the request.
***The backend checks if the provided TAs are valid (exist in the system and are not already assigned).
***Each TA’s role is updated to TEACHING_ASSISTANT in the users table.
***A new entry in the TaMapping table is created, associating the TA with the course.

* Database Update (Backend Models):
**TaMapping Table: A new mapping is added to associate the user (TA) with the course.
**User Table: The role of the user is updated to TEACHING_ASSISTANT to reflect the new responsibilities.

* Response:
**If successful, the backend returns a 200 OK status, and the frontend updates the UI to reflect the changes.
**If any errors occur (e.g., invalid TA or duplicate assignment), the backend returns a 400 Bad Request response with error details.

* UI Update:
**The frontend receives the response and updates the UI, either displaying a success message or showing the appropriate error message.

* UML Diagram:

[[File:UML_2.png]]

==Test Plan==

* Rspec Unit Tests:
**Test add_ta method for successful assignment, duplicate assignment, and invalid user errors.
**Validate add_multiple_tas to ensure successful batch assignments.

* Manual UI Testing:
**Verify course page modifications (icon and button placements).
**Confirm TA search and dropdown limitations.
**Validate successful addition and error messaging for single and multiple TA assignments.

==UML Diagrams==

* High-Level System Architecture:
**Show interaction flow between the frontend, courses_controller, and course.rb model.

* TA Addition Sequence Diagram:
**Depict the sequence for assigning multiple TAs and handling responses.

==Project Mentor==
*Devansh Shah (dshah8@ncsu.edu)

==Team Members==
*Makarand Pundlik (mpundli@ncsu.edu)
*Anurag Gorkar (adgorkar@ncsu.edu)
*Rutvik Kulkarni (rvkulkar@ncsu.edu)

==References==
*[https://github.com/MakarandPundlik/reimplementation-front-end Frontend Repo]
*[https://github.com/AnuragGorkar/reimplementation-back-end Backend Repo]
*[https://github.com/expertiza/reimplementation-back-end/pull/132 Backend PR]
*[https://github.com/expertiza/reimplementation-front-end/pull/72 Frontend PR]

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

2024-11-12T19:33:05Z

Mpundli: Created page with "__TOC__ ==Introduction== The Expertiza project is an open-source, Ruby on Rails-based platform designed to facilitate peer reviews, enabling students to learn from each other. The platform serves faculty and students for managing courses, assignments, and peer evaluations. The management screens in Expertiza provide essential information on users, courses, assignments, questionnaires, and reviews. The project’s goal is to make the course and assignment management pro..."

CSC/ECE 517 Fall 2024

2024-11-12T19:12:58Z

Mpundli:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Fall 2024 - E2491.UI for View assignments in Courses view]]
* [[CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course]]

Talk:CSC/ECE 517 Fall 2024

2024-11-12T19:12:30Z

Mpundli: Blanked the page

Talk:CSC/ECE 517 Fall 2024

2024-11-12T19:11:49Z

Mpundli: Created page with "CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course"

CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T19:15:56Z

Mpundli: /* Code Improvements */

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Response map overview==
The response_map is a crucial component in the Expertiza system, it ensures the relationship between reviewers and reviewees in an assignment. In Expertiza, when a user submits a review, it creates an instance of the Response class. Each Response is associated with a specific ResponseMap that identifies the reviewer (reviewer_id), the person being reviewed (reviewee_id), the item under evaluation (reviewed_object_id), and the type of review, such as ReviewResponseMap, MetareviewResponseMap, FeedbackResponseMap, and TeammateReviewResponseMap, among others.

===Attributes===
1. reviewed_object_id: This integer field identifies the object (assignment, project, etc.) being reviewed. It serves as a foreign key to link to the specific item under review.
2. reviewer_id: This integer field denotes the user who is acting as the reviewer. It connects to the users table, allowing the system to track who provided the feedback or evaluation.
3. reviewee_id: This integer identifies the user or entity being reviewed, establishing a relationship with the person or group receiving the feedback.
4. created_at & updated_at: These timestamp fields automatically track when the response map was created and last updated, ensuring that the system maintains accurate records of modifications.

==Current implementation==
* ResponseMap class is responsible for managing the relationships between responses and the participants involved in the review process. It establishes association between multiple models such as Response, Pariticipant and Assignment.
* Currently, the "assessments_for" method in response_map.rb is being utilized in the response.rb file to retrieve the latest assessment responses associated with a specified team or reviewer. This method fetches all responses related to the given team, filters them based on submission status (specifically for ReviewResponseMap types), and sorts them to return the most recent assessments. Additionally, it sorts the final response list by the full name of the reviewer.

<pre>
def self.assessments_for(team)
responses = []
# stime = Time.now
if team
array_sort = []
sort_to = []
maps = where(reviewee_id: team.id)
maps.each do |map|
next if map.response.empty?

all_resp = Response.where(map_id: map.map_id).last
if map.type.eql?('ReviewResponseMap')
# If its ReviewResponseMap then only consider those response which are submitted.
array_sort << all_resp if all_resp.is_submitted
else
array_sort << all_resp
end
# sort all versions in descending order and get the latest one.
sort_to = array_sort.sort # { |m1, m2| (m1.updated_at and m2.updated_at) ? m2.updated_at <=> m1.updated_at : (m1.version_num ? -1 : 1) }
responses << sort_to[0] unless sort_to[0].nil?
array_sort.clear
sort_to.clear
end
responses = responses.sort { |a, b| a.map.reviewer.fullname <=> b.map.reviewer.fullname }
end
responses
end
</pre>

==Drawbacks==
* The implementation of "assessments_for" method violates the Single Responsibility Principle (SRP), as it handles multiple responsibilities, including fetching response maps, filtering responses, sorting them, and returning the final results. This leads to reduced readability and maintainability.
* The class lacks validations for its associations and attributes, which could lead to potential inconsistencies or errors in the data. Without proper validations, there's a risk of creating ResponseMap records that do not conform to the expected data integrity, such as having invalid or nonexistent reviewer, reviewee, or assignment associations.

==Enhancements==
* To enhance clarity and adhere to the SRP, the assessments_for method could be split into several smaller methods. For example, one method could focus on retrieving response maps, another could filter responses based on submission status, and a third could handle sorting. This modular approach would improve the method's maintainability and make the codebase easier to understand and extend in the future.
* Implementing validations for associations and attributes would ensure data integrity and reduce the likelihood of runtime errors. Overall, while the ResponseMap class provides essential functionality within the response management system, its current structure could be optimized for better readability, maintainability, and reliability.
* In addition to this restructuring, implementing scopes and delegations would further enhance the class. Scopes could be introduced to encapsulate commonly used queries, such as retrieving all response maps for a specific reviewer or reviewee, making the code cleaner and more expressive. Delegation could be employed to simplify access to frequently used attributes or methods from associated models, reducing the need for repetitive code and enhancing readability.

===Newly added methods===
* latest_responses_for_team_by_reviewer: A new method that retrieves the latest responses from a specific reviewer for a given team, allowing for targeted data access based on team and reviewer relationships.
<pre>
def latest_responses_for_team_by_reviewer(team, reviewer)
return [] if team.nil? || reviewer.nil?
fetch_latest_responses(for_team(team.id).by_reviewer(reviewer.id))
end
</pre>

* responses_by_reviewer: Added a method to fetch all responses submitted by a specific reviewer, enhancing the retrieval capabilities of the model.
<pre>
def responses_by_reviewer(reviewer)
return [] if reviewer.nil?
fetch_submitted_responses(by_reviewer(reviewer.id))
end
</pre>

* fetch_submitted_responses: Added a method that retrieves all submitted responses associated with the given maps by filtering only those marked as submitted
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* responses_for_assignment: method retrieves all submitted responses for a given assignment. It returns an empty array if the assignment is nil

<pre>
def responses_for_assignment(assignment)
return [] if assignment.nil?

fetch_submitted_responses(for_assignment(assignment.id))
end
</pre>

* fetch_and_sort_responses: A private method collects valid responses from the given maps and then sorts these responses by the reviewer's name.
<pre>
def fetch_and_sort_responses(maps)
responses = collect_valid_responses(maps)
sort_responses_by_reviewer_name(responses)
end
</pre>

* collect_valid_responses: This method gathers all valid responses from the given maps. For each map, it includes the associated response and reviewer (with the user details). It skips any map that has no responses and processes each response based on its type, returning a compacted array of the results.
<pre>
def collect_valid_responses(maps)
maps.includes(:response, reviewer: :user).map do |map|
next if map.response.empty?

process_response_by_type(map)
end.compact
end
</pre>

* process_response_by_type: This method retrieves the latest response from `map.response`. If there is no response, it returns `nil`. For maps of type `ReviewResponseMap`, it returns the latest response only if it has been submitted (i.e., `is_submitted` is `true`). For other map types, it simply returns the latest response regardless of its submission status.
<pre>
def process_response_by_type(map)
latest_response = map.response.last
return nil if latest_response.nil?

if map.type == 'ReviewResponseMap'
latest_response if latest_response.is_submitted
else
latest_response
end
end
</pre>

* sort_responses_by_reviewer_name: The `sort_responses_by_reviewer_name` method sorts the given `responses` array in alphabetical order based on each response's reviewer's full name. It converts the name to a string to ensure compatibility during sorting.
<pre>
def sort_responses_by_reviewer_name(responses)
responses.sort_by { |response| response.map.reviewer_fullname.to_s }
end
</pre>

* fetch_latest_responses: The method retrieves the latest response for each map in `maps`, includes the associated `response` records to minimize database queries, and filters out any maps without a response. It then returns only the latest responses that have been submitted (i.e., where `is_submitted` is `true`).
<pre>
def fetch_latest_responses(maps)
maps.includes(:response)
.map { |map| map.response.last }
.compact
.select(&:is_submitted)
end
</pre>

* fetch_submitted_responses: The method retrieves all responses associated with the given `maps` that have been submitted. It does this by first narrowing `maps` down to those with submitted responses, then including the associated `response` records, and finally flattening and selecting only the submitted responses from each `map`.
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* response_assignment and response_count: The `response_assignment ` method returns the assignment associated with the `reviewer` of the response map. The `response_count` method returns the total number of responses associated with the response map by counting the entries in the `response` collection.
<pre>
def response_assignment
reviewer.assignment
end

def response_count
response.count
end
</pre>

===Code Improvements===
* Using Scopes for Querying: Reimplemented code uses scopes (for_team, by_reviewer, for_assignment, with_responses, with_submitted_responses) for cleaner and more readable querying
* Private Class Methods: Reimplemented code utilizes private class methods for better encapsulation and organization
* Comprehensive Fetching Methods: newly implemented code has well-defined methods like fetch_latest_responses and fetch_submitted_responses, providing clarity on data retrieval while maintaining separation of concerns.
* Delegation: uses delegation for retrieving fullname and name
<pre>
delegate :fullname, to: :reviewer, prefix: true, allow_nil: true
delegate :name, to: :assignment, prefix: true, allow_nil: true
</pre>

===Testing===
* Unit Testing: Earlier Version: No unit tests were provided, leaving functionality unverified. Current Version: The use of RSpec framework provides a structured way to test the model's behavior. Each test is organized into meaningful groups (described using describe blocks).

* Validation Testing: Tests for all validation rules to ensure that the model behaves correctly when provided with valid and invalid data. Specific tests check for presence, uniqueness, and the handling of invalid IDs.

* Scope Testing: Tests are provided for each scope method to ensure they return the expected results based on different conditions. Each scope is verified against the ResponseMap records, ensuring the correct filtering and retrieval of records.

* Method Testing: Tests for custom class methods (.assessments_for, .latest_responses_for_team_by_reviewer, .responses_by_reviewer, .responses_for_assignment) to validate their functionality and expected outputs.Each method is checked against various scenarios, including edge cases where inputs might be nil.

* Association Testing: Tests the behavior of instance methods like #response_assignment and #response_count, ensuring they return the expected values based on the state of the ResponseMap.

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/MakarandPundlik/reimplementation-back-end GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T19:15:27Z

Mpundli:

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Response map overview==
The response_map is a crucial component in the Expertiza system, it ensures the relationship between reviewers and reviewees in an assignment. In Expertiza, when a user submits a review, it creates an instance of the Response class. Each Response is associated with a specific ResponseMap that identifies the reviewer (reviewer_id), the person being reviewed (reviewee_id), the item under evaluation (reviewed_object_id), and the type of review, such as ReviewResponseMap, MetareviewResponseMap, FeedbackResponseMap, and TeammateReviewResponseMap, among others.

===Attributes===
1. reviewed_object_id: This integer field identifies the object (assignment, project, etc.) being reviewed. It serves as a foreign key to link to the specific item under review.
2. reviewer_id: This integer field denotes the user who is acting as the reviewer. It connects to the users table, allowing the system to track who provided the feedback or evaluation.
3. reviewee_id: This integer identifies the user or entity being reviewed, establishing a relationship with the person or group receiving the feedback.
4. created_at & updated_at: These timestamp fields automatically track when the response map was created and last updated, ensuring that the system maintains accurate records of modifications.

==Current implementation==
* ResponseMap class is responsible for managing the relationships between responses and the participants involved in the review process. It establishes association between multiple models such as Response, Pariticipant and Assignment.
* Currently, the "assessments_for" method in response_map.rb is being utilized in the response.rb file to retrieve the latest assessment responses associated with a specified team or reviewer. This method fetches all responses related to the given team, filters them based on submission status (specifically for ReviewResponseMap types), and sorts them to return the most recent assessments. Additionally, it sorts the final response list by the full name of the reviewer.

<pre>
def self.assessments_for(team)
responses = []
# stime = Time.now
if team
array_sort = []
sort_to = []
maps = where(reviewee_id: team.id)
maps.each do |map|
next if map.response.empty?

all_resp = Response.where(map_id: map.map_id).last
if map.type.eql?('ReviewResponseMap')
# If its ReviewResponseMap then only consider those response which are submitted.
array_sort << all_resp if all_resp.is_submitted
else
array_sort << all_resp
end
# sort all versions in descending order and get the latest one.
sort_to = array_sort.sort # { |m1, m2| (m1.updated_at and m2.updated_at) ? m2.updated_at <=> m1.updated_at : (m1.version_num ? -1 : 1) }
responses << sort_to[0] unless sort_to[0].nil?
array_sort.clear
sort_to.clear
end
responses = responses.sort { |a, b| a.map.reviewer.fullname <=> b.map.reviewer.fullname }
end
responses
end
</pre>

==Drawbacks==
* The implementation of "assessments_for" method violates the Single Responsibility Principle (SRP), as it handles multiple responsibilities, including fetching response maps, filtering responses, sorting them, and returning the final results. This leads to reduced readability and maintainability.
* The class lacks validations for its associations and attributes, which could lead to potential inconsistencies or errors in the data. Without proper validations, there's a risk of creating ResponseMap records that do not conform to the expected data integrity, such as having invalid or nonexistent reviewer, reviewee, or assignment associations.

==Enhancements==
* To enhance clarity and adhere to the SRP, the assessments_for method could be split into several smaller methods. For example, one method could focus on retrieving response maps, another could filter responses based on submission status, and a third could handle sorting. This modular approach would improve the method's maintainability and make the codebase easier to understand and extend in the future.
* Implementing validations for associations and attributes would ensure data integrity and reduce the likelihood of runtime errors. Overall, while the ResponseMap class provides essential functionality within the response management system, its current structure could be optimized for better readability, maintainability, and reliability.
* In addition to this restructuring, implementing scopes and delegations would further enhance the class. Scopes could be introduced to encapsulate commonly used queries, such as retrieving all response maps for a specific reviewer or reviewee, making the code cleaner and more expressive. Delegation could be employed to simplify access to frequently used attributes or methods from associated models, reducing the need for repetitive code and enhancing readability.

===Newly added methods===
* latest_responses_for_team_by_reviewer: A new method that retrieves the latest responses from a specific reviewer for a given team, allowing for targeted data access based on team and reviewer relationships.
<pre>
def latest_responses_for_team_by_reviewer(team, reviewer)
return [] if team.nil? || reviewer.nil?
fetch_latest_responses(for_team(team.id).by_reviewer(reviewer.id))
end
</pre>

* responses_by_reviewer: Added a method to fetch all responses submitted by a specific reviewer, enhancing the retrieval capabilities of the model.
<pre>
def responses_by_reviewer(reviewer)
return [] if reviewer.nil?
fetch_submitted_responses(by_reviewer(reviewer.id))
end
</pre>

* fetch_submitted_responses: Added a method that retrieves all submitted responses associated with the given maps by filtering only those marked as submitted
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* responses_for_assignment: method retrieves all submitted responses for a given assignment. It returns an empty array if the assignment is nil

<pre>
def responses_for_assignment(assignment)
return [] if assignment.nil?

fetch_submitted_responses(for_assignment(assignment.id))
end
</pre>

* fetch_and_sort_responses: A private method collects valid responses from the given maps and then sorts these responses by the reviewer's name.
<pre>
def fetch_and_sort_responses(maps)
responses = collect_valid_responses(maps)
sort_responses_by_reviewer_name(responses)
end
</pre>

* collect_valid_responses: This method gathers all valid responses from the given maps. For each map, it includes the associated response and reviewer (with the user details). It skips any map that has no responses and processes each response based on its type, returning a compacted array of the results.
<pre>
def collect_valid_responses(maps)
maps.includes(:response, reviewer: :user).map do |map|
next if map.response.empty?

process_response_by_type(map)
end.compact
end
</pre>

* process_response_by_type: This method retrieves the latest response from `map.response`. If there is no response, it returns `nil`. For maps of type `ReviewResponseMap`, it returns the latest response only if it has been submitted (i.e., `is_submitted` is `true`). For other map types, it simply returns the latest response regardless of its submission status.
<pre>
def process_response_by_type(map)
latest_response = map.response.last
return nil if latest_response.nil?

if map.type == 'ReviewResponseMap'
latest_response if latest_response.is_submitted
else
latest_response
end
end
</pre>

* sort_responses_by_reviewer_name: The `sort_responses_by_reviewer_name` method sorts the given `responses` array in alphabetical order based on each response's reviewer's full name. It converts the name to a string to ensure compatibility during sorting.
<pre>
def sort_responses_by_reviewer_name(responses)
responses.sort_by { |response| response.map.reviewer_fullname.to_s }
end
</pre>

* fetch_latest_responses: The method retrieves the latest response for each map in `maps`, includes the associated `response` records to minimize database queries, and filters out any maps without a response. It then returns only the latest responses that have been submitted (i.e., where `is_submitted` is `true`).
<pre>
def fetch_latest_responses(maps)
maps.includes(:response)
.map { |map| map.response.last }
.compact
.select(&:is_submitted)
end
</pre>

* fetch_submitted_responses: The method retrieves all responses associated with the given `maps` that have been submitted. It does this by first narrowing `maps` down to those with submitted responses, then including the associated `response` records, and finally flattening and selecting only the submitted responses from each `map`.
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* response_assignment and response_count: The `response_assignment ` method returns the assignment associated with the `reviewer` of the response map. The `response_count` method returns the total number of responses associated with the response map by counting the entries in the `response` collection.
<pre>
def response_assignment
reviewer.assignment
end

def response_count
response.count
end
</pre>

===Code Improvements===
# Using Scopes for Querying: Reimplemented code uses scopes (for_team, by_reviewer, for_assignment, with_responses, with_submitted_responses) for cleaner and more readable querying
# Private Class Methods: Reimplemented code utilizes private class methods for better encapsulation and organization
# Comprehensive Fetching Methods: newly implemented code has well-defined methods like fetch_latest_responses and fetch_submitted_responses, providing clarity on data retrieval while maintaining separation of concerns.
# Delegation: uses delegation for retrieving fullname and name
<pre>
delegate :fullname, to: :reviewer, prefix: true, allow_nil: true
delegate :name, to: :assignment, prefix: true, allow_nil: true
</pre>

===Testing===
* Unit Testing: Earlier Version: No unit tests were provided, leaving functionality unverified. Current Version: The use of RSpec framework provides a structured way to test the model's behavior. Each test is organized into meaningful groups (described using describe blocks).

* Validation Testing: Tests for all validation rules to ensure that the model behaves correctly when provided with valid and invalid data. Specific tests check for presence, uniqueness, and the handling of invalid IDs.

* Scope Testing: Tests are provided for each scope method to ensure they return the expected results based on different conditions. Each scope is verified against the ResponseMap records, ensuring the correct filtering and retrieval of records.

* Method Testing: Tests for custom class methods (.assessments_for, .latest_responses_for_team_by_reviewer, .responses_by_reviewer, .responses_for_assignment) to validate their functionality and expected outputs.Each method is checked against various scenarios, including edge cases where inputs might be nil.

* Association Testing: Tests the behavior of instance methods like #response_assignment and #response_count, ensuring they return the expected values based on the state of the ResponseMap.

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/MakarandPundlik/reimplementation-back-end GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T19:14:56Z

Mpundli: /* Newly added methods */

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Response map overview==
The response_map is a crucial component in the Expertiza system, it ensures the relationship between reviewers and reviewees in an assignment. In Expertiza, when a user submits a review, it creates an instance of the Response class. Each Response is associated with a specific ResponseMap that identifies the reviewer (reviewer_id), the person being reviewed (reviewee_id), the item under evaluation (reviewed_object_id), and the type of review, such as ReviewResponseMap, MetareviewResponseMap, FeedbackResponseMap, and TeammateReviewResponseMap, among others.

===Attributes===
1. reviewed_object_id: This integer field identifies the object (assignment, project, etc.) being reviewed. It serves as a foreign key to link to the specific item under review.
2. reviewer_id: This integer field denotes the user who is acting as the reviewer. It connects to the users table, allowing the system to track who provided the feedback or evaluation.
3. reviewee_id: This integer identifies the user or entity being reviewed, establishing a relationship with the person or group receiving the feedback.
4. created_at & updated_at: These timestamp fields automatically track when the response map was created and last updated, ensuring that the system maintains accurate records of modifications.

==Current implementation==
* ResponseMap class is responsible for managing the relationships between responses and the participants involved in the review process. It establishes association between multiple models such as Response, Pariticipant and Assignment.
* Currently, the "assessments_for" method in response_map.rb is being utilized in the response.rb file to retrieve the latest assessment responses associated with a specified team or reviewer. This method fetches all responses related to the given team, filters them based on submission status (specifically for ReviewResponseMap types), and sorts them to return the most recent assessments. Additionally, it sorts the final response list by the full name of the reviewer.

<pre>
def self.assessments_for(team)
responses = []
# stime = Time.now
if team
array_sort = []
sort_to = []
maps = where(reviewee_id: team.id)
maps.each do |map|
next if map.response.empty?

all_resp = Response.where(map_id: map.map_id).last
if map.type.eql?('ReviewResponseMap')
# If its ReviewResponseMap then only consider those response which are submitted.
array_sort << all_resp if all_resp.is_submitted
else
array_sort << all_resp
end
# sort all versions in descending order and get the latest one.
sort_to = array_sort.sort # { |m1, m2| (m1.updated_at and m2.updated_at) ? m2.updated_at <=> m1.updated_at : (m1.version_num ? -1 : 1) }
responses << sort_to[0] unless sort_to[0].nil?
array_sort.clear
sort_to.clear
end
responses = responses.sort { |a, b| a.map.reviewer.fullname <=> b.map.reviewer.fullname }
end
responses
end
</pre>

==Drawbacks==
* The implementation of "assessments_for" method violates the Single Responsibility Principle (SRP), as it handles multiple responsibilities, including fetching response maps, filtering responses, sorting them, and returning the final results. This leads to reduced readability and maintainability.
* The class lacks validations for its associations and attributes, which could lead to potential inconsistencies or errors in the data. Without proper validations, there's a risk of creating ResponseMap records that do not conform to the expected data integrity, such as having invalid or nonexistent reviewer, reviewee, or assignment associations.

==Enhancements==
* To enhance clarity and adhere to the SRP, the assessments_for method could be split into several smaller methods. For example, one method could focus on retrieving response maps, another could filter responses based on submission status, and a third could handle sorting. This modular approach would improve the method's maintainability and make the codebase easier to understand and extend in the future.
* Implementing validations for associations and attributes would ensure data integrity and reduce the likelihood of runtime errors. Overall, while the ResponseMap class provides essential functionality within the response management system, its current structure could be optimized for better readability, maintainability, and reliability.
* In addition to this restructuring, implementing scopes and delegations would further enhance the class. Scopes could be introduced to encapsulate commonly used queries, such as retrieving all response maps for a specific reviewer or reviewee, making the code cleaner and more expressive. Delegation could be employed to simplify access to frequently used attributes or methods from associated models, reducing the need for repetitive code and enhancing readability.

===Newly added methods===
* latest_responses_for_team_by_reviewer: A new method that retrieves the latest responses from a specific reviewer for a given team, allowing for targeted data access based on team and reviewer relationships.
<pre>
def latest_responses_for_team_by_reviewer(team, reviewer)
return [] if team.nil? || reviewer.nil?
fetch_latest_responses(for_team(team.id).by_reviewer(reviewer.id))
end
</pre>

* responses_by_reviewer: Added a method to fetch all responses submitted by a specific reviewer, enhancing the retrieval capabilities of the model.
<pre>
def responses_by_reviewer(reviewer)
return [] if reviewer.nil?
fetch_submitted_responses(by_reviewer(reviewer.id))
end
</pre>

* fetch_submitted_responses: Added a method that retrieves all submitted responses associated with the given maps by filtering only those marked as submitted
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* responses_for_assignment: method retrieves all submitted responses for a given assignment. It returns an empty array if the assignment is nil

<pre>
def responses_for_assignment(assignment)
return [] if assignment.nil?

fetch_submitted_responses(for_assignment(assignment.id))
end
</pre>

* fetch_and_sort_responses: A private method collects valid responses from the given maps and then sorts these responses by the reviewer's name.
<pre>
def fetch_and_sort_responses(maps)
responses = collect_valid_responses(maps)
sort_responses_by_reviewer_name(responses)
end
</pre>

* collect_valid_responses: This method gathers all valid responses from the given maps. For each map, it includes the associated response and reviewer (with the user details). It skips any map that has no responses and processes each response based on its type, returning a compacted array of the results.
<pre>
def collect_valid_responses(maps)
maps.includes(:response, reviewer: :user).map do |map|
next if map.response.empty?

process_response_by_type(map)
end.compact
end
</pre>

* process_response_by_type: This method retrieves the latest response from `map.response`. If there is no response, it returns `nil`. For maps of type `ReviewResponseMap`, it returns the latest response only if it has been submitted (i.e., `is_submitted` is `true`). For other map types, it simply returns the latest response regardless of its submission status.
<pre>
def process_response_by_type(map)
latest_response = map.response.last
return nil if latest_response.nil?

if map.type == 'ReviewResponseMap'
latest_response if latest_response.is_submitted
else
latest_response
end
end
</pre>

* sort_responses_by_reviewer_name: The `sort_responses_by_reviewer_name` method sorts the given `responses` array in alphabetical order based on each response's reviewer's full name. It converts the name to a string to ensure compatibility during sorting.
<pre>
def sort_responses_by_reviewer_name(responses)
responses.sort_by { |response| response.map.reviewer_fullname.to_s }
end
</pre>

* fetch_latest_responses: The method retrieves the latest response for each map in `maps`, includes the associated `response` records to minimize database queries, and filters out any maps without a response. It then returns only the latest responses that have been submitted (i.e., where `is_submitted` is `true`).
<pre>
def fetch_latest_responses(maps)
maps.includes(:response)
.map { |map| map.response.last }
.compact
.select(&:is_submitted)
end
</pre>

* fetch_submitted_responses: The method retrieves all responses associated with the given `maps` that have been submitted. It does this by first narrowing `maps` down to those with submitted responses, then including the associated `response` records, and finally flattening and selecting only the submitted responses from each `map`.
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* response_assignment and response_count: The `response_assignment ` method returns the assignment associated with the `reviewer` of the response map. The `response_count` method returns the total number of responses associated with the response map by counting the entries in the `response` collection.
<pre>
def response_assignment
reviewer.assignment
end

def response_count
response.count
end
</pre>

===Code Improvements===
# Using Scopes for Querying: Reimplemented code uses scopes (for_team, by_reviewer, for_assignment, with_responses, with_submitted_responses) for cleaner and more readable querying
# Private Class Methods: Reimplemented code utilizes private class methods for better encapsulation and organization
# Comprehensive Fetching Methods: newly implemented code has well-defined methods like fetch_latest_responses and fetch_submitted_responses, providing clarity on data retrieval while maintaining separation of concerns.
# Delegation: uses delegation for retrieving fullname and name
<pre>
delegate :fullname, to: :reviewer, prefix: true, allow_nil: true
delegate :name, to: :assignment, prefix: true, allow_nil: true
</pre>

===Testing===
* Unit Testing: Earlier Version: No unit tests were provided, leaving functionality unverified. Current Version: The use of RSpec framework provides a structured way to test the model's behavior. Each test is organized into meaningful groups (described using describe blocks).

* Validation Testing: Tests for all validation rules to ensure that the model behaves correctly when provided with valid and invalid data. Specific tests check for presence, uniqueness, and the handling of invalid IDs.

* Scope Testing: Tests are provided for each scope method to ensure they return the expected results based on different conditions. Each scope is verified against the ResponseMap records, ensuring the correct filtering and retrieval of records.

* Method Testing: Tests for custom class methods (.assessments_for, .latest_responses_for_team_by_reviewer, .responses_by_reviewer, .responses_for_assignment) to validate their functionality and expected outputs.Each method is checked against various scenarios, including edge cases where inputs might be nil.

* Association Testing: Tests the behavior of instance methods like #response_assignment and #response_count, ensuring they return the expected values based on the state of the ResponseMap.

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/MakarandPundlik/reimplementation-back-end GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T19:13:43Z

Mpundli: The document outlines the Expertiza project, an open-source Ruby on Rails application that facilitates assignment creation, peer reviews, and team collaborations among students. It highlights the **ResponseMap** class, which manages reviewer-reviewee relationships within the system, detailing its current implementation, drawbacks, and proposed enhancements for improved readability and maintainability. Key improvements include modularizing the `assessments_for` method, implementing validation for

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Response map overview==
The response_map is a crucial component in the Expertiza system, it ensures the relationship between reviewers and reviewees in an assignment. In Expertiza, when a user submits a review, it creates an instance of the Response class. Each Response is associated with a specific ResponseMap that identifies the reviewer (reviewer_id), the person being reviewed (reviewee_id), the item under evaluation (reviewed_object_id), and the type of review, such as ReviewResponseMap, MetareviewResponseMap, FeedbackResponseMap, and TeammateReviewResponseMap, among others.

===Attributes===
1. reviewed_object_id: This integer field identifies the object (assignment, project, etc.) being reviewed. It serves as a foreign key to link to the specific item under review.
2. reviewer_id: This integer field denotes the user who is acting as the reviewer. It connects to the users table, allowing the system to track who provided the feedback or evaluation.
3. reviewee_id: This integer identifies the user or entity being reviewed, establishing a relationship with the person or group receiving the feedback.
4. created_at & updated_at: These timestamp fields automatically track when the response map was created and last updated, ensuring that the system maintains accurate records of modifications.

==Current implementation==
* ResponseMap class is responsible for managing the relationships between responses and the participants involved in the review process. It establishes association between multiple models such as Response, Pariticipant and Assignment.
* Currently, the "assessments_for" method in response_map.rb is being utilized in the response.rb file to retrieve the latest assessment responses associated with a specified team or reviewer. This method fetches all responses related to the given team, filters them based on submission status (specifically for ReviewResponseMap types), and sorts them to return the most recent assessments. Additionally, it sorts the final response list by the full name of the reviewer.

<pre>
def self.assessments_for(team)
responses = []
# stime = Time.now
if team
array_sort = []
sort_to = []
maps = where(reviewee_id: team.id)
maps.each do |map|
next if map.response.empty?

all_resp = Response.where(map_id: map.map_id).last
if map.type.eql?('ReviewResponseMap')
# If its ReviewResponseMap then only consider those response which are submitted.
array_sort << all_resp if all_resp.is_submitted
else
array_sort << all_resp
end
# sort all versions in descending order and get the latest one.
sort_to = array_sort.sort # { |m1, m2| (m1.updated_at and m2.updated_at) ? m2.updated_at <=> m1.updated_at : (m1.version_num ? -1 : 1) }
responses << sort_to[0] unless sort_to[0].nil?
array_sort.clear
sort_to.clear
end
responses = responses.sort { |a, b| a.map.reviewer.fullname <=> b.map.reviewer.fullname }
end
responses
end
</pre>

==Drawbacks==
* The implementation of "assessments_for" method violates the Single Responsibility Principle (SRP), as it handles multiple responsibilities, including fetching response maps, filtering responses, sorting them, and returning the final results. This leads to reduced readability and maintainability.
* The class lacks validations for its associations and attributes, which could lead to potential inconsistencies or errors in the data. Without proper validations, there's a risk of creating ResponseMap records that do not conform to the expected data integrity, such as having invalid or nonexistent reviewer, reviewee, or assignment associations.

==Enhancements==
* To enhance clarity and adhere to the SRP, the assessments_for method could be split into several smaller methods. For example, one method could focus on retrieving response maps, another could filter responses based on submission status, and a third could handle sorting. This modular approach would improve the method's maintainability and make the codebase easier to understand and extend in the future.
* Implementing validations for associations and attributes would ensure data integrity and reduce the likelihood of runtime errors. Overall, while the ResponseMap class provides essential functionality within the response management system, its current structure could be optimized for better readability, maintainability, and reliability.
* In addition to this restructuring, implementing scopes and delegations would further enhance the class. Scopes could be introduced to encapsulate commonly used queries, such as retrieving all response maps for a specific reviewer or reviewee, making the code cleaner and more expressive. Delegation could be employed to simplify access to frequently used attributes or methods from associated models, reducing the need for repetitive code and enhancing readability.

===Newly added methods===
* latest_responses_for_team_by_reviewer: A new method that retrieves the latest responses from a specific reviewer for a given team, allowing for targeted data access based on team and reviewer relationships.
<pre>
def latest_responses_for_team_by_reviewer(team, reviewer)
return [] if team.nil? || reviewer.nil?
fetch_latest_responses(for_team(team.id).by_reviewer(reviewer.id))
end
</pre>

* responses_by_reviewer: Added a method to fetch all responses submitted by a specific reviewer, enhancing the retrieval capabilities of the model.
<pre>
def responses_by_reviewer(reviewer)
return [] if reviewer.nil?
fetch_submitted_responses(by_reviewer(reviewer.id))
end
</pre>

* fetch_submitted_responses: Added a method that retrieves all submitted responses associated with the given maps by filtering only those marked as submitted
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* responses_for_assignment: method retrieves all submitted responses for a given assignment. It returns an empty array if the assignment is nil

<pre>
def responses_for_assignment(assignment)
return [] if assignment.nil?

fetch_submitted_responses(for_assignment(assignment.id))
end
</pre>

* fetch_and_sort_responses: A private method collects valid responses from the given maps and then sorts these responses by the reviewer's name.
<pre>
def fetch_and_sort_responses(maps)
responses = collect_valid_responses(maps)
sort_responses_by_reviewer_name(responses)
end
</pre>

* collect_valid_responses: This method gathers all valid responses from the given maps. For each map, it includes the associated response and reviewer (with the user details). It skips any map that has no responses and processes each response based on its type, returning a compacted array of the results.
<pre>
def collect_valid_responses(maps)
maps.includes(:response, reviewer: :user).map do |map|
next if map.response.empty?

process_response_by_type(map)
end.compact
end
</pre>

* process_response_by_type: This method retrieves the latest response from `map.response`. If there is no response, it returns `nil`. For maps of type `ReviewResponseMap`, it returns the latest response only if it has been submitted (i.e., `is_submitted` is `true`). For other map types, it simply returns the latest response regardless of its submission status.
<pre>
def process_response_by_type(map)
latest_response = map.response.last
return nil if latest_response.nil?

if map.type == 'ReviewResponseMap'
latest_response if latest_response.is_submitted
else
latest_response
end
end
</pre>

* sort_responses_by_reviewer_name: The `sort_responses_by_reviewer_name` method sorts the given `responses` array in alphabetical order based on each response's reviewer's full name. It converts the name to a string to ensure compatibility during sorting.
<pre>
def sort_responses_by_reviewer_name(responses)
responses.sort_by { |response| response.map.reviewer_fullname.to_s }
end
</pre>

* fetch_latest_responses: The method retrieves the latest response for each map in `maps`, includes the associated `response` records to minimize database queries, and filters out any maps without a response. It then returns only the latest responses that have been submitted (i.e., where `is_submitted` is `true`).
<pre>
def fetch_latest_responses(maps)
maps.includes(:response)
.map { |map| map.response.last }
.compact
.select(&:is_submitted)
end
</pre>

* fetch_submitted_responses: The method retrieves all responses associated with the given `maps` that have been submitted. It does this by first narrowing `maps` down to those with submitted responses, then including the associated `response` records, and finally flattening and selecting only the submitted responses from each `map`.
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* response_assignment and response_count: The `response_assignment ` method returns the assignment associated with the `reviewer` of the response map. The `response_count` method returns the total number of responses associated with the response map by counting the entries in the `response` collection.
<pre>
def response_assignment
reviewer.assignment
end

def response_count
response.count
end
</pre>

===Code Improvements===
# Using Scopes for Querying: Reimplemented code uses scopes (for_team, by_reviewer, for_assignment, with_responses, with_submitted_responses) for cleaner and more readable querying
# Private Class Methods: Reimplemented code utilizes private class methods for better encapsulation and organization
# Comprehensive Fetching Methods: newly implemented code has well-defined methods like fetch_latest_responses and fetch_submitted_responses, providing clarity on data retrieval while maintaining separation of concerns.
# Delegation: uses delegation for retrieving fullname and name
<pre>
delegate :fullname, to: :reviewer, prefix: true, allow_nil: true
delegate :name, to: :assignment, prefix: true, allow_nil: true
</pre>

===Testing===
* Unit Testing: Earlier Version: No unit tests were provided, leaving functionality unverified. Current Version: The use of RSpec framework provides a structured way to test the model's behavior. Each test is organized into meaningful groups (described using describe blocks).

* Validation Testing: Tests for all validation rules to ensure that the model behaves correctly when provided with valid and invalid data. Specific tests check for presence, uniqueness, and the handling of invalid IDs.

* Scope Testing: Tests are provided for each scope method to ensure they return the expected results based on different conditions. Each scope is verified against the ResponseMap records, ensuring the correct filtering and retrieval of records.

* Method Testing: Tests for custom class methods (.assessments_for, .latest_responses_for_team_by_reviewer, .responses_by_reviewer, .responses_for_assignment) to validate their functionality and expected outputs.Each method is checked against various scenarios, including edge cases where inputs might be nil.

* Association Testing: Tests the behavior of instance methods like #response_assignment and #response_count, ensuring they return the expected values based on the state of the ResponseMap.

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/MakarandPundlik/reimplementation-back-end GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T18:58:07Z

Mpundli:

__TOC__

==About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Response map overview==
The response_map is a crucial component in the Expertiza system, it ensures the relationship between reviewers and reviewees in an assignment. In Expertiza, when a user submits a review, it creates an instance of the Response class. Each Response is associated with a specific ResponseMap that identifies the reviewer (reviewer_id), the person being reviewed (reviewee_id), the item under evaluation (reviewed_object_id), and the type of review, such as ReviewResponseMap, MetareviewResponseMap, FeedbackResponseMap, and TeammateReviewResponseMap, among others.

===Attributes===
1. reviewed_object_id: This integer field identifies the object (assignment, project, etc.) being reviewed. It serves as a foreign key to link to the specific item under review.
2. reviewer_id: This integer field denotes the user who is acting as the reviewer. It connects to the users table, allowing the system to track who provided the feedback or evaluation.
3. reviewee_id: This integer identifies the user or entity being reviewed, establishing a relationship with the person or group receiving the feedback.
4. created_at & updated_at: These timestamp fields automatically track when the response map was created and last updated, ensuring that the system maintains accurate records of modifications.

==Current implementation==
* ResponseMap class is responsible for managing the relationships between responses and the participants involved in the review process. It establishes association between multiple models such as Response, Pariticipant and Assignment.
* Currently, the "assessments_for" method in response_map.rb is being utilized in the response.rb file to retrieve the latest assessment responses associated with a specified team or reviewer. This method fetches all responses related to the given team, filters them based on submission status (specifically for ReviewResponseMap types), and sorts them to return the most recent assessments. Additionally, it sorts the final response list by the full name of the reviewer.

<pre>
def self.assessments_for(team)
responses = []
# stime = Time.now
if team
array_sort = []
sort_to = []
maps = where(reviewee_id: team.id)
maps.each do |map|
next if map.response.empty?

all_resp = Response.where(map_id: map.map_id).last
if map.type.eql?('ReviewResponseMap')
# If its ReviewResponseMap then only consider those response which are submitted.
array_sort << all_resp if all_resp.is_submitted
else
array_sort << all_resp
end
# sort all versions in descending order and get the latest one.
sort_to = array_sort.sort # { |m1, m2| (m1.updated_at and m2.updated_at) ? m2.updated_at <=> m1.updated_at : (m1.version_num ? -1 : 1) }
responses << sort_to[0] unless sort_to[0].nil?
array_sort.clear
sort_to.clear
end
responses = responses.sort { |a, b| a.map.reviewer.fullname <=> b.map.reviewer.fullname }
end
responses
end
</pre>

==Drawbacks==
* The implementation of "assessments_for" method violates the Single Responsibility Principle (SRP), as it handles multiple responsibilities, including fetching response maps, filtering responses, sorting them, and returning the final results. This leads to reduced readability and maintainability.
* The class lacks validations for its associations and attributes, which could lead to potential inconsistencies or errors in the data. Without proper validations, there's a risk of creating ResponseMap records that do not conform to the expected data integrity, such as having invalid or nonexistent reviewer, reviewee, or assignment associations.

==Enhancements==
* To enhance clarity and adhere to the SRP, the assessments_for method could be split into several smaller methods. For example, one method could focus on retrieving response maps, another could filter responses based on submission status, and a third could handle sorting. This modular approach would improve the method's maintainability and make the codebase easier to understand and extend in the future.
* Implementing validations for associations and attributes would ensure data integrity and reduce the likelihood of runtime errors. Overall, while the ResponseMap class provides essential functionality within the response management system, its current structure could be optimized for better readability, maintainability, and reliability.
* In addition to this restructuring, implementing scopes and delegations would further enhance the class. Scopes could be introduced to encapsulate commonly used queries, such as retrieving all response maps for a specific reviewer or reviewee, making the code cleaner and more expressive. Delegation could be employed to simplify access to frequently used attributes or methods from associated models, reducing the need for repetitive code and enhancing readability.

===Newly added methods===
* latest_responses_for_team_by_reviewer: A new method that retrieves the latest responses from a specific reviewer for a given team, allowing for targeted data access based on team and reviewer relationships.
<pre>
def latest_responses_for_team_by_reviewer(team, reviewer)
return [] if team.nil? || reviewer.nil?
fetch_latest_responses(for_team(team.id).by_reviewer(reviewer.id))
end
</pre>

* responses_by_reviewer: Added a method to fetch all responses submitted by a specific reviewer, enhancing the retrieval capabilities of the model.
<pre>
def responses_by_reviewer(reviewer)
return [] if reviewer.nil?
fetch_submitted_responses(by_reviewer(reviewer.id))
end
</pre>

* fetch_submitted_responses: Added a method that retrieves all submitted responses associated with the given maps by filtering only those marked as submitted
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* responses_for_assignment: method retrieves all submitted responses for a given assignment. It returns an empty array if the assignment is nil

<pre>
def responses_for_assignment(assignment)
return [] if assignment.nil?

fetch_submitted_responses(for_assignment(assignment.id))
end
</pre>

* fetch_and_sort_responses: A private method collects valid responses from the given maps and then sorts these responses by the reviewer's name.
<pre>
def fetch_and_sort_responses(maps)
responses = collect_valid_responses(maps)
sort_responses_by_reviewer_name(responses)
end
</pre>

* collect_valid_responses: This method gathers all valid responses from the given maps. For each map, it includes the associated response and reviewer (with the user details). It skips any map that has no responses and processes each response based on its type, returning a compacted array of the results.
<pre>
def collect_valid_responses(maps)
maps.includes(:response, reviewer: :user).map do |map|
next if map.response.empty?

process_response_by_type(map)
end.compact
end
</pre>

* process_response_by_type: This method retrieves the latest response from `map.response`. If there is no response, it returns `nil`. For maps of type `ReviewResponseMap`, it returns the latest response only if it has been submitted (i.e., `is_submitted` is `true`). For other map types, it simply returns the latest response regardless of its submission status.
<pre>
def process_response_by_type(map)
latest_response = map.response.last
return nil if latest_response.nil?

if map.type == 'ReviewResponseMap'
latest_response if latest_response.is_submitted
else
latest_response
end
end
</pre>

* sort_responses_by_reviewer_name: The `sort_responses_by_reviewer_name` method sorts the given `responses` array in alphabetical order based on each response's reviewer's full name. It converts the name to a string to ensure compatibility during sorting.
<pre>
def sort_responses_by_reviewer_name(responses)
responses.sort_by { |response| response.map.reviewer_fullname.to_s }
end
</pre>

* fetch_latest_responses: The method retrieves the latest response for each map in `maps`, includes the associated `response` records to minimize database queries, and filters out any maps without a response. It then returns only the latest responses that have been submitted (i.e., where `is_submitted` is `true`).
<pre>
def fetch_latest_responses(maps)
maps.includes(:response)
.map { |map| map.response.last }
.compact
.select(&:is_submitted)
end
</pre>

* fetch_submitted_responses: The method retrieves all responses associated with the given `maps` that have been submitted. It does this by first narrowing `maps` down to those with submitted responses, then including the associated `response` records, and finally flattening and selecting only the submitted responses from each `map`.
<pre>
def fetch_submitted_responses(maps)
maps.with_submitted_responses
.includes(:response)
.flat_map { |map| map.response.select(&:is_submitted) }
end
</pre>

* response_assignment and response_count: The `response_assignment ` method returns the assignment associated with the `reviewer` of the response map. The `response_count` method returns the total number of responses associated with the response map by counting the entries in the `response` collection.
<pre>
def response_assignment
reviewer.assignment
end

def response_count
response.count
end
</pre>

===References===
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/MakarandPundlik/reimplementation-back-end GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Fall 2024 - E2481 Reimplement response map.rb

2024-10-29T18:55:53Z

Mpundli: